To understand Change and Release management & how they play together to generate value for the organization, we first need to understand what they are.
As those of you who have any passing familiarity with ITSM, would know that Change Management or Enablement as it is now called in ITIL v4, is a set of standardized methods and best practices which are used for efficient and prompt handling of any IT changes. This ensures we minimize the impact of change related incidents upon service quality and consequently improve the day-to-day operations of the organization. ITIL practices also emphasize developing business justification as well. A typical organizational context necessarily has the following three types of changes viz. Emergency change, Standard Changes and pre-approved changes.
Moving on to Release Management, it a set of best practices whose primary objective is to plan, schedule and control the deployment of IT services and updates into the live environments. Enterprises evolve and as they do, their needs change, so the IT environment needs to change too. Release management provides a means for making changes effectively, efficiently and without disruption. It does this by ensuring only sufficiently tested services and components can be released into the live environment that the business uses.
There are three levels of releases viz. Major, Minor and Emergency, and releases are grouped into 3 types a) Delta (contains only the elements that have changed), b) Full (includes all the elements), c) Package (Grouping of all release into one).
Release management seeks to create a more proactive and predictable change management process in which a series of changes are grouped together, which are referred to as “releases”, which is essential for managing the volume of interdependent changes within an Enterprise.
The ultimate goal is to ensure that this results in the successful release and deployment of these changes into the production IT environment while causing as minimal disruption as is humanely possible.
Successful release management depends on discipline in process, the use of formal procedures, and checks. We need to highlight releases in our ITSM tools, which ensures that that everyone is aware of any major deployments. This will make sure there are no conflicts or scheduling clashes.
The above descriptions establish that both have a similar goal and purpose to ensure businesses continue to evolve and change without disruption. While both of these practices work closely together, change and release management are two separate ITIL practices. However, change management without release management is virtually impossible in an enterprise simply due to volume of changes involved. Release management makes the change management practice more proactive and predictable. As described above it groups a series of changes into a collective called a release.
Change works with release management, where release management is concerned with “Implementation”, unlike change management which focusses on “Risk” and “Business Justification”. In practice change and release management function as a single lifecycle to execute a change into production environment. However, there are several elements that can be missed when they are looked on as a whole.
In the simplest terms Change is about understanding and approving the “What” while release is the management of the “How” and the “When”. The way organizations operate leads me to believe that the lack is within the change process. Most CAB meetings spend their time evaluating the validity of the testing process and approving the “Change Schedule”, but these are really the functions of release.
The Change management process is the process that evaluates whether or not you should make the change to begin with, it’s all about business benefits, risk and cost – which should than translate into a value judgement on whether the change should be executed in the first place or not. Looking at the change from a business value perspective before the enterprise invests resources in its further development is what is missing from most change and release management processes.
Typically, Hardware and software development are quite different, in terms of the concrete developmental activities. Thus, it might seem that both Change & Release management needs to follow different paths for the introduction of new hardware or software. However, most of the obvious differences between hardware and software deployments have to do with the nature and sequencing of deliverables, rather than unique attributes of the work that needs to be performed. Though from a purely cost perspective software is more malleable than hardware and hence cost of change is much higher for hardware than for software.
Another aspect gaining traction these days is the Change and Release management for cloud, however at a fundamental level it is again intended to ensure that proper versions of hardware and software, configuration files, licenses, and associated supporting processes are in place and correctly and reliably rolled into production. The goals of release management continue to include effective management of all phases from planning a release to developing procedures that will be used in the rollout, along with managing customer expectations during the rollout.
Hence, the separation of change and release processes enables the organizations to understand the distinction between the “What” versus “How” & “When”. tussom, the ITSM suite by eStomi has incorporated all the required functionality to ensure both change and release management processes run in tandem and provide best Business ROI.