I’ve been doing a lot of thinking about ITIL and whether or not it is fit for purpose for DevOps. The logic I keep hearing goes like this - you shouldn't confuse the ITIL approach with the implementation; the ITIL approach is building blocks; these building blocks are easily applied to DevOps. I’m not convinced.
First, ITIL is fundamentally time bound. For example, ITIL v1 was primarily around applying mainframe disciplines into the emerging world of Client/Server, ITIL v2 was more about ensuring quality of output across complex operations environments and ITIL v3 was more about consolidating established operations principles and shifting the focus to “how does IT contribute to business value?”
Isn’t it a stretch to make best practices for previous waves of technology apply to DevOps whereby infrastructure and operations professionals are not silo’d but play an active part in delivering customer products and services along with application developers? Second, ITIL zealots are convinced that these ITIL “best practices” are some kind of complex baking recipe and if all steps are not followed to the letter, the end result will be a failure.
This means that for many, the approach and the implementation of ITIL is tied. This leads me to my question: Is ITIL fit for purpose for DevOps? To return to the analogy of building blocks, let’s use the ultimate of building blocks – Legos. When I think about ITIL and service management, what most enterprises have implemented, looks like this:
Many organisations who have embraced ITIL gave up their technology focused silos like network, servers, databases and exchanged them for process silos like service desk, change management, asset management and problem management. In the end, we are still silo’d and built to buffer ourselves from change. Here are some examples:
- Change management. ITIL has led us into creating Change Advisory Boards (CAB or sometimes “Change Authority”) that meet intermittently and rely either on complete attendance to even have a chance of approval or a hope that the people in attendance will have enough knowledge to adequately approve a change. Somehow we think that at this last checkpoint before putting a change into production we can “control” our way into quality delivery. But the fact of the matter is we are putting control at the very end of the process as a last ditch effort HOPING that the people in the room can discern what the ramifications are for any given change.
- Asset management. Many organisations don’t even know what assets exist and launch expensive and often futile exercises to discover all hardware and software assets indiscriminately. Then these discovered assets have to be associated to applications. All the while, assets are changing because parts of the application has moved to the cloud or been virtualised. Asset management of today reminds me of Sisyphus rolling the rock up the hill only to have it roll down again.
In the end, what we have built with ITIL are heavy processes that only add bulk and time to our ability to deliver improvements. We are not geared for speed or agility and instead we have built up our practices to defend against the dreaded disruption of service.
This is a completely different mindset when we move into DevOps where the fundamental idea is to embrace change as the new norm even when it causes a failure. Therefore, what we should be trying to build is more like an FI racer. We need something where parts can be optimised continuously because the end product is built for speed and quality:
Let’s revisit our examples but this time in a DevOps context:Is ITIL Fit For Purpose For DevOps?
- Change management. Change is good. Changes should be automatically accepted unless they are high risk (high probability of high customer impact). Control for changes happens at the very beginning through the end of the life cycle to truly gain confidence in the ability to deliver quality products and services with a speedy and consistent process by:
- Consistent configuration management of environments in development, testing and production
- Thorough and automatic testing in development and testing environments
- Automatic quality gates removing any manual errors
- Automated, lean release process
Even changes to the configuration are run through this life cycle giving confidence that no negative effects on the application will occur. And if an incident does occur, the infrastructure and operations pros band together with the application developers to quickly recover and learn how to do things better next time.
- Asset management. Because configuration management is consistent, it is already known what assets are provisioned. The only worry is if the configuration deviates from what has been configured. Now asset management becomes tracking any “drift”. The good news here is that it’s likely the release automation tool already has drift tracking as a feature so no one is worried about asset management until an alert which explains what change on what system has been made. Pretty cool, huh?
In the end, maybe it’s all about control. I have seen pragmatically applied ITIL transform technology management organisations that lack control and who are often running from incident to incident trying to figure out how to get better.
These organisations become high functioning and controlled with help of a common language, a business outcome focus, and generic guidelines for common processes. The trick is then to transform again from controlled organisation to one that embraces agility and speed by moving control (and trust) to different owners and/or different automated processes some of which are outside the technology management organisation – a transformation that ITIL doesn’t cover.
I’ve expressed my doubts. Now it’s time for you to weigh in. What do you think? Is ITIL fit for purpose for DevOps? Look for the poll next to the blog post and let me know what you think.
Posted by Amy DeMartine