An ITIL Change Manager, of my acquaintance, was recently told that the move of her company towards an Agile DevOps model would mean that her role would shortly be no longer required. The implication being that an ITIL Change Manager had no place in the DevOps world, where everything is automated and predictable.
It took some time to reassure her that the person who had told her this was misinformed, and, while her role may have to evolve and adapt, the role of a Change Manager was more relevant than ever.
Understanding ITIL Change Management?
Change Management is one of the processes defined in the Service Operations stage of the ITSM lifecycle defined as part of the ITIL framework. As a process, Change Management is designed to control the risk and minimise the disruption to the business of strategic, tactical and operational changes to IT services.
If you were to mention Change Management to most IT professionals, they would probably start to describe a bureaucratic process built around a rigid Change Advisory Board (CAB), meeting once a week, through which all changes had to be approved, stifling innovation and business agility.
This is a very narrow view of the ITIL Change Management process, and tends to reflect a poor understanding and implementation of the framework.
Unfortunately, a lot of the issues that DevOps evangelists have with ITIL is based on their experiences with this sort of Change Management process.
The DevOps approach to change
Change is an integral part of the DevOps culture and processes. The DevOps approach to change is based around the concept of continuous delivery built around automated scripts and procedures to support a deployment pipeline, breaking down silos with enhanced communication and collaboration between development teams, operations teams, and other key stakeholders.
The deployment pipeline is the signature of the DevOps process for any business, and must be clearly documented, created deliberately, and iterated for continual improvement.
Integrating the outputs of log analysis, automated load testing, automated functional testing, and configuration monitoring, into meaningful dashboards create a feedback mechanism that can be used to objectively review the quality of all changes that take place.
Like a poorly implemented Change Management processes, poorly thought out and documented DevOps processes and procedures can result in a chaotic free-for-all approach to the delivery pipeline.
Making sure that there is a clear strategy and that this is based on a well-documented process that is continually reviewed and evolved, is essential for the successful implementation of DevOps for a business.
DevOps and Change Management
ITIL Change Management tends to be built around the management of the risk associated with large changes that have the potential to have significant business impact.
In a DevOps world, the change happens rapidly with small incremental changes being made. These small changes are not incompatible with the ITIL concept of change.
ITIL has the concept of the Standard Change, this is “A Change that is recurrent, well known, has been proceduralised to follow a pre-defined, relatively risk-free path, and is the accepted response to a specific requirement or set of circumstances, where authority is effectively given in advance of implementation.”
Most changes that relate to the DevOps world fit this definition of a Standard Change, and therefore will fit the ITIL Change Management framework
The role of the Change Manager
With a decrease in the number of changes that go through the Change process, and an increase in the number of Standard Changes, the role of the Change Manager will change.
The focus of the Change Manager will be on the governance of the change processes rather than the management of individual changes, evolving from a policeman to a supervisor.
In turn the DevOps team will need to be able to prove, to the Change Manager, that the processes that define their deployment pipeline can be certified to be categorised as being standard changes.
It is also worth bearing in mind that the number of IT systems and services that do not support the DevOps/Agile deployment model will continue to be prevalent for a while, requiring a more traditional model of Change Management.
This does not, however, mean that Change Management shouldn’t learn from the DevOps model and continue to evolve and adapt. Change Management must always be seen as being a facilitator for, rather than a barrier to, change.
If you would like to discuss how iCore can help you then contact us on +44 (0) 207 868 2405 or email us at firstname.lastname@example.org.