While the concepts behind ITIL seemed reasonable when I first learned about it, I have become concerned about the effectiveness of ITIL change management in practice, particularly in comparison to the practice of continuous delivery.
Change management can mean many things. I am referring to it in the context of ITIL service management which Wikipedia defines as
"The goal of the change management process is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently improve the day-to-day operations of the organization."
These are great objectives to have, but I have not seen them realized in practice when ITIL change management has been adopted. The only standardization was on the process and associated paperwork: the methods of how changes were done were not improved at all through ITIL. The extra process meant less efficiency and potentially delays. A few change-related incidents have probably been prevented through the ITIL process, but these kinds of incidents still occur regularly enough for me to question the effectiveness of the process.
Is the problem with the ITIL change management process itself, or the implementation of this process? It is often claimed that ITIL is a framework of best practices. So how could I question ITIL itself? James Bach has demonstrated quite convincingly that there are no best practices, only good practices for a certain context. Given the significant change within IT, it is conceivable that the context today is considerably different from when the ITIL change management practices were first selected.
One relevant development in the industry is the concept of Continuous Delivery which was popularized by the book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble and David Farley. The back of the book makes bold claims:
This groundbreaking new book sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers, and operations, delivery teams can get changes released in a matter of hours - sometimes even minutes - no matter what the size of a project or the complexity of its code base.
Jez Humble defines Continuous Delivery as "a set of principles and practices to reduce the cost, time, and risk of delivering incremental changes to users." It is interesting that this sounds quite similar to the objectives of ITIL change management, but pursues them in a completely different fashion. Continuous Delivery focuses on automation, with one of the core concepts being the deployment pipeline which is the end-to-end process, ideally fully automated, for handling code from check-in to production release.
The rise of the DevOps movement in recent years and the use of Continuous Delivery by a number of large, well-known IT companies like Netflix, Facebook, and Amazon have validated the ideas from this book. Some companies report doing upwards of 50 production deployments each day! With very short cycle times for each deployment, it is inconceivable to imagine the ITIL change management processes I have seen working at all in such environments. Yet these companies adopting Continuous Delivery report drastic improvements in their ability to promote changes to production: cost, time, and risk are all significantly reduced.
So are there flaws with ITIL itself, or just poor ITIL implementations that I have been exposed to? I read with great interest the 2014 State of DevOps Report which states that "Using external change approval processes such as a change advisory board, as opposed to peer-based code review techniques, significantly impacts throughput while doing almost nothing to improve stability." This suggests that either poor ITIL implementations are very common, or ITIL itself is flawed.
The main concepts of ITIL change management, however, seem to make sense to me. Jez Humble argues that Continuous Delivery and ITIL can co-exist if one uses a more pragmatic implementation of ITIL. For example, fully automated deployments of applications using continuous delivery practices could be classified as standard changes which would eliminate most of the process overhead. The comments on his article suggest, however, that this is a contentious viewpoint. Many of the commenters obviously believe that there are significant impedances between ITIL and Continuous Delivery that make it difficult for them to co-exist.
In conclusion, Continuous Delivery practices have successfully produced significant improvements to the delivery of changes, while ITIL change management has not, and worse offers up potential barriers to the successful adoption of Continuous Delivery. The evidence seems clear that organizations should move towards adopting Continuous Delivery and revise their ITIL change management practices to align.
If you find this article helpful, please make a donation.