Balancing time-to-market pressures with regulatory needs and business continuity demands is a challenge for highly regulated large enterprises. Automating processes and mastering proven practices of release management makes developing and releasing software predictable, reliable, and repeatable.
All around us, software development is the engine of innovation. Software innovation disrupts existing business models by enabling products and services that are more intelligent and targeted. To ensure that they are the disruptors and not the disrupted, enterprises invest significant capital in managing the software development lifecycle (SDLC).
However, a gap in the SDLC is throttling back the velocity of new application innovation and causing the failure of critical business systems. This gap sits between development and operations—a traditional “no-man’s land” of responsibility, tooling, and focus. Bridging this gap has to be a top priority for the modern enterprise.
For the highly regulated large enterprise (HRLE) in sectors such as financial services, insurance, health care, aerospace, defense, and government, dealing with this gap is critical. A failed software release can destroy brands, reputations, regulatory standing, and other assets that can take years to rebuild.
Change Management: Necessary but Not Sufficient
Many HRLEs have adopted the ITIL process framework and implemented IT service management applications that include change management modules in order to support their operational processes. Though we often hear the terms change management and release management used interchangeably, they represent two distinct and important disciplines in the SDLC. Change management is about determining what changes are going to be accepted, implemented, and deployed. Release management is about deciding which changes should go together, tracking them through the lifecycle, providing visibility to those changes, and ultimately ensuring that they move safely into production.
Release management is concerned with the movement and implementation of the change request through the application development lifecycle. Generally, it begins when the release gets a name, e.g., 4th-Quarter Release. That’s when content—first the change requests and then the requirements, code, test scripts, test results, sign-offs, etc.—gets assigned to the release and moves from development, to test, to systems integration testing, to user acceptance testing, to preproduction/staging, and then on to production. The practice of release management ensures that the enterprise follows the release process through the entire SDLC and that the right artifacts move from stage to stage completely, safely, and speedily.
Without strong release management, HRLEs often find the management and communication of changes to be bewilderingly complex, especially given the huge volume of changes moving into production every week. By grouping a collection of smaller changes together in a set, release management vastly simplifies the complexity.
DevOps: Beware the Purists
Some organizations are experimenting with DevOps, but it is not the promised panacea for HRLEs.
Pure DevOps preaches the blending of roles and sharing of responsibility between development and operations teams, in some cases creating DevOps units trained across their respective disciplines.