Do You Really Need Enterprise Release Management in a DevOps World?

In the enterprise, application delivery has always been challenging. Enabling teams across all lines of business to converge for production is no mean feat – particularly when those teams are so disparate they might as well be separate companies. But what is the unified goal that binds these teams together? Increasingly, it appears to be the directive to "go faster" and ultimately to deliver software more quickly.

A proven methodology to achieving greater speed at scale is DevOps. If you can make Dev and Ops work better while breaking up delivery into smaller chunks, then you’re good to go. An integral part of the road to improvement is technology-driven; organizations need to adopt agile technologies in order to increase operational efficiency. However, strong communication and collaboration are also key necessities to make the concept a reality.

If you are looking at this from a perspective of driving change, a DevOps approach could be interpreted to mean that the traditional role of enterprise release management (ERM) is no longer needed. After all, the bulk of operational oversight can be invalidated by the process of automation. With this in mind, what does release management look like in a DevOps world? Is it possible to make multi-delivery pipelines truly autonomous, eliminating the need for ERM at all?

Defining the Concept

Enterprise Release Management is a set of practices designed to direct the software delivery cycle across multiple projects. It is the orchestration of activities across multiple initiatives and unifying them for the ultimate goal of software release. Areas such as creating, scheduling and coordinating these delivery pipelines all fall under the ERM umbrella.

Part of this is delivery release management, and enterprise release managers often fulfill this duty too. This area of release management focuses on the delivery of the entire product including hardware, software, applications and/or infrastructure configurations. In addition to that, technical release managers focus on the building of application assets, such as the code, application configurations, and database structures; in essence, the management of development to ensure alignment with architecture and best practices.

Business alignment and risk mitigation are also key areas of long-range, multi-delivery planning. Ensuring test teams are ready, infrastructure components are equipped, and operations are integrated – in terms of not only the team, but also the overall preparedness – are key. If a release is looking to make big functionality changes, it is understandably important that the company knows exactly what’s coming, and the ERM manager is the only reliable coordination point for that communication.

Defining a Place for ERM in an Automated Ecosystem

A fully-automated approach can provide the tools to handle a lot of the work that goes into these processes, but some areas such as governance and compliance still pose challenges. The goal for most enterprises is not 1000 releases a day, but instead coordinating well enough to maximize what goes through the pipe when it goes to production in order to save or at least maximize the investment spent on regulatory tax. And while automation can help ensure that teams and resources are available, it is the enterprise release manager that oversees the operation as well as discovering and implementing areas of improvement.

Organization-wide visibility into changes is what is lacking in organizations that have not fully embraced DevOps. In essence, anyone can automate — it’s knowing what to automate that needs ERM. It’s the process of combining tools to facilitate the automation of DevOps, in addition to the human element of the enterprise release manager, that fully enables the team to have clear insights into each of the delivery pipelines. These insights can then be evaluated and used to implement positive changes into each team’s toolchain with the goal of going faster – a desire which has seemingly no end.

Taking all of this into consideration, if the ultimate goal of DevOps and continuous deployment is true automation, it becomes clear that there is still a place for ERM in DevOps teams. Addressing release management must be a priority when streamlining operations at any large enterprise, and for companies already utilizing this process, it will remain so.