Control, Enablement? Why a word matters
By the time Axelos released the foundational level of ITIL 4, in February 2019, a major change to the framework was long overdue, given that the third version dated back to 2007. Twelve years is a long time in a relatively young industry, but this twelve years had been hugely significant, not least because DevOps did not even exist as a phrase in 2007. It was another year before the publication of key pieces of work such as Agile Infrastructure, by Patrick Debois.
I genuinely feel that ITIL 4 Foundation is a really good piece of work. The ITSM community struggled for years to understand that DevOps wasn’t just new, but had actively set out to deconstruct established operational norms… including much of what had been built around ITIL itself. I wasn’t entirely optimistic.
The creators of ITIL 4 Foundation, fortunately, were open minded enough to adapt some significant learnings of the DevOps movement. While Version 3 had retained the linearity of previous versions, maintaining a firm “plan, build, run” flow in its Service Lifecycle concept, Version 4 substantially replaced this with a more iterative value-stream model which would certainly not look out-of-place in a good DevOps handbook. The shift from “Processes” to “Practices”, discussed by Axelos here, also achieved significant praise.
However, it wasn’t all smooth, and soon after publication, one particular item began to be discussed: the newly named practice of “Change Control”.
The challenge here is the word “Control”. Rob didn’t like it, and neither did I. We weren’t alone. Rob and I have both spoken at a number of DevOps conferences, and spent a lot of time in that community, and perhaps we knew more than most how much “control” would be problematic.
The shift in wording had been done in good faith for clearly explained reasons. Greg Sanker provides a good summary of the thinking behind the choice of “control”, in this June 2019 article:
“Change Management” has a subtle implication that its focus is on managing each-and-every change… Change Control, on the other hand, seeks to control the circumstance in which changes are developed consistent with the organization’s change outcome expectations. In other words, Change Control provides oversight and governance on how the organization produces changes — In the Value Stream.
However, it seems we troublemakers have been heard on this one. Rob had suggested “Facilitation”. My preference was “Strategy”. Both work, but on the 31st October, Axelos confirmed in an online article that the ITIL 4 practice would be renamed to “Change Enablement”, which feels like another good choice:
Following the release of ITIL 4 Foundation, we have heard from several people around the world that the practice was being misinterpreted or misunderstood as focused on ‘controlling changes’ or ‘controlling teams’, rather than ‘controlling the rate of changes’. The word ‘control’ is toxic to many IT teams, and I am curious how IT governance professionals feel about this development. Nonetheless, we listened to the feedback, we tested options, including reverting back to ‘change management’, and decided to change the name of this practice from ‘change control’ to ‘change enablement’.
It is brave to make a change at this point in the ITIL 4 lifecycle, just as the next round of more detailed publications starts to be published. I’m sure a lot of training materials, blogs, and slides are having to be updated in a hurry. I feel, however, that it was an essential move. In the context of ITIL’s role in a DevOps-oriented technology future, words really matter. Make no mistake: Change Management, in the context of ITSM, has a very negative reputation in the DevOps community.
One of the most fundamental aims of DevOps, of course, is to introduce the frequency of deployment of changes. A long standing issue for the DevOps community has been the perception of ITIL change practices as something which actively slowed the frequency of releases. For example, IT Revolution’s publication, “Breaking the Change Management Barrier, states that
Once an enabler of innovation, command-and-control change management is now considered a constraint.
Perhaps worse still, the DevOps community’s own findings have been that if the goal of ITSM Change Management is to reduce risk and increase quality, it is also failing in that regard. 2019’s Accelerate: State of DevOps Report continued with its annual trend of assessing the change performance of high-performing, DevOps-oriented organisations. As in previous years, they observed hugely better results on both speed and reliability measures:
As I’ve argued before, ITSM can not impose anything on the DevOps community. It can only bring things to the table which offer new value. Statistics like this are part of the reason for this, but more broadly, the lean underpinnings of DevOps will systemically exclude anything that is not clearly showing demonstrable enhancement.
However, ITSM as a concept has plenty to offer to the smooth and successful flow of changes, even in a DevOps-oriented organisation. There are many examples, but a common one for real-world enterprises is regulation. Many business in many sectors have regulatory burdens which require work to be done to assert and prove that a required level of governance is being applied. If this work has to be done by the delivery team, it can be a signifiant overhead. Centralisation of this work can be a big benefit to the DevOps practitioners (and also to the people who have to deal with the auditors), but if it centralisation is not seamless, it’s not fully effective.
Among some BMC customers, we are now starting to see DevOps teams deriving real value from their established service management practices. A bank in South Africa, for instance, has begun to implement a structure comparable to Google’s SRE concept of Error Budget, in which teams that demonstrate success and reliability on an ongoing basis are encouraged to proceed with substantially less central oversight than those who have caused issues. The process largely sits out of the way of developers, but the bank maintains the overall level of governance that it needs.
Tooling is adapting, too: cognitive technology is now being used to augment human risk analysis. I often point out that this is not just about identifying changes which are more risky than perceived, but also those which are less risky, because this is an enabler of agility. The development team may never even see the flow of information from Jira to the ITSM tool, unless something is identified worthy of their attention. This might be a problem or risk that they’d otherwise have missed. The organisation is given more confidence to allow DevOps teams to move faster, and those teams are given extra security against unintended consequences of changes in the complex enterprise. The auditor is happy. Significant value is created.
This is why wording matters here. “Control” is a toxic word in this context because, whether we like it or not, it describes an interference mode, and conjures images of stereotypical “CAB meetings” with 20 people sitting around a table offering earnest but ill-informed comments on whether a change can proceed. This might not always be fair, but go to a DevOps conference and ask around: it’s a real and widely held impression.
“Enablement” describes shifting our practices to focus on the goals of the teams driving the changes: further increasing their reliability and velocity, while getting the hell out of the way every time we can. It’s a much, much better word.
Stop sign image courtesy Joel Cramer on Flickr and used under Creative Commons license. https://www.flickr.com/photos/75001512@N00/4701345277
