How to Modify ITIL to Accommodate DevOps

If an IT management idea could ever be said to be “exciting”, then perhaps DevOps is a strong candidate. But ITIL rules the roost. So how to Modify ITIL to accommodate DevOps and other elements of ‘Agile’ development?

The basic idea of DevOps is to replace the traditional separation of “Development” and “IT” or “Operations”, with a single function. This restructure has laudable goals; no more developers having to commission and wait for test and production servers to be built, because the commissioning and building happen in the same place as the development. No more Operations techs in apoplexy because the developers have unilaterally published code with pretty much no thought for capacity, nor demand, storage, backup, nor security issues. With DevOps, we’re all in this together, chaps. But how does that square with ITIL, if at all?


The DevOps movement is all about apps development productivity, aiming to respond to the age-old business challenge of minimised time-to-market (time-to-users) and thus, maximised Return On Investment (ROI). Coming from the same constellation as ‘Agile’ computing, DevOps encourages us to realise that in fact, given that it’s all ultimately about production, IT is not so different from lots of other industries. In many cases those industries long ago solved production problems, with which we in IT still struggle from time to time, and we can learn from their proven methods.

Agile computing in general and DevOps in particular encourage us to rethink the routes that IT developments follow to turn them into production IT in everyday use. Taking their leads from manufacturing, they attempt to speed those routes up by ensuring that all components of the IT production line are working at ideal capacity without being swamped by excessive demand.


Toyota is often cited as the inspiration for this, in particular their work in developing ‘Just In Time’ manufacturing, by using techniques such as Kanban for monitoring workflow. Through Agile and DevOps, Kanban has made it into IT, supplemented by work prioritisation techniques such as Scrum (essentially, get everybody together to decide what to do next) and Sprint (a time-limited burst of planned work to produce short-term outputs as part of a larger project).

The experience in manufacturing is described beautifully in Eli Goldratt’s business novel ‘The Goal’. It describes certain rules, such as never to overload single points of failure (SPoF); how a queue at one junction in the process can cripple the efficiency of all the other junctions; insisting that knowing your capacities is everything. I wrote about applying Goldratt to IT services in my business handbook ‘Managing the IT Services Process’ several years ago. Back then, ITIL was less developed than it is now, but with the arrival of DevOps, perhaps it is time to refresh ITIL once again, to accommodate these newly popular ideas.

The following is how, if I were in charge of ITIL’s design, I’d develop it to incorporate, or even work alongside DevOps.

Six ITIL Modifications to Accommodate DevOps

1. Incorporate A New ‘DevOps’ Process

ITIL’s go-to solution for running an IT Services activity is to assign a ‘Process’ to it and define an owner. A new DevOps ‘process’ theoretically could be achieved by merging some existing processes and then going through a rewrite to allow for the new requirements like throughput measurement, queue management, SPoF monitoring, Scrum and Sprint.

A word of caution though – ITIL rewrites are risky. It’s only happened three times in nearly two decades. Rewrites are also unnerving because of the expense – new books have to be purchased, training may have to be refreshed, procedures re-examined, trainers reassessed. But there is so much non-ITIL thinking in DevOps, that a brand new process might be the only way of accommodating it properly. And even that might not be quick (see change 6 below).

2. Emphasise Production over Process

ITIL is all about Processes, 20-odd of them and four functions besides. Then there are all the roles and responsibilities, apparently of various numbers depending on whose version you read, but around twice as many again. Then there are 450-odd specialised terms and around 100 official abbreviations. ITIL’s approach is to describe and focus on its bureaucracy with comparatively little to say about method.

DevOps is very different. There, the emphasis is on moving the work unit from idea to production, even if that means changing the work unit to make it do-able. It is not about the towering mechanisms, but decidedly about how to get the workload through them. It’s a completely different mindset. To allow for this, I believe ITIL would have to make a shift of principle away from structure and more toward method. Some of that method is given in these other suggested changes.

3. Focus on Throughput rather than Output

DevOps is ‘Agile computing’ in practice. In its expression, the progress of a work unit is of paramount importance. As it progresses, that work unit shall not be impeded by a bottleneck. This means that knowing where those bottlenecks are, their volume capacities, capabilities, and handling speed are vital. It’s all about throughput.

ITIL’s main statistical focus however is on Service Levels – what pops out at the end of a process or series. It has no specific recommendations about how to measure how the work unit got to that end point, so it leaves itself allowing for internal backlogs to be created without official notification. This would take a shift within ITIL to measuring the internal effectiveness of its processes. Knowing what you’ve produced is all very well – but knowing how you produced it is the only way to consistency.

4. Identify and Quantify Workload Streams

One of the biggest risks to DevOps productivity is the availability of the right skill-sets, in sufficient quantity that they are not overloaded. Operations technicians have a varied workload consisting not just of project work, but also routine maintenance and the occasional reactive interruption. To be sure that there is enough resource available for any one type of work, the impact of all the other types must necessarily also be known. Being process- rather than workload-driven, ITIL is currently inherently unready to identify, quantify and use such intelligence.

5. Simplify IT Department Structure

There are at least 40 ‘roles’ in ITIL and some would argue many more than that. Imagine the indecipherable cacophony if they all were to speak at once. How much of the information they spouted would be irrelevant noise and how much mission-critical warnings? And if the number of these roles is open to debate as it appears, how can we know whether all the potential bottlenecks are being managed? Simplification would appear to be desirable.

6. Remove ITIL’s Inherent Silos

First Line, Second Line, Third Line. Applications Architect. Build and Test Environment Staff. Etc, etc, etc. ITIL is big on departments, reporting to different bosses, each having separate core missions, each having their own ‘queues’ in the ITSM software system. ITIL’s structure is inherently silo-oriented, with each silo primarily responsible for its own mission, rather than for the rapid reaction to a request coming from another silo. Every one of them is a potential bottleneck. You couldn’t get more un-DevOps if you tried.

Take a look at the queues in your ITSM system. If you’re typical, backlogs everywhere, with each department scheduling its own workload its own way. A DevOps production line doesn’t have bottlenecks all over it – it has one backlog, right at the top, and a clear strategy for burning it.

This is the Big One, because this is the ITIL culture, and cultures are the hardest thing to change. It’s not all ITIL’s fault, because dividing IT up on the basis of technologies has been the IT way for as long as I’ve known it (35 years). But ITIL feeds it by making its long lists of separate responsibilities. That culture fosters the precise opposite of the throughput orientation and cross-culture collaboration that DevOps is trying to achieve. It is the main thing that cancels out the credibility of any current ITIL claim to be DevOps-ready. I fear this one will take the longest to resolve.

Holy Grail

The topic is way bigger than I’ve been able to cover here, and I could have written a book rather than just an article. Besides, It could be that DevOps is a passing fad, a flash in the pan, and we might do more harm than good by making changes on this scale for something that may eventually wane in popularity. But I doubt it myself, because there is in Agile Computing the glimmer of our long-sought Holy Grail – namely the closer alignment of IT with the business interests. It offers faster developments, a business more able to apply its technology to market opportunity, a more justifiable IT budget. Agile, and its practical expression of DevOps serve the interests of a wide range of stakeholders.

That makes it in ITIL’s interests to adapt. Here’s hoping it realises what it’s getting into, and has the courage to divest itself of some of its now outdated principles to find a new, more contemporary and relevant design.

BTW, ‘ITIL’ is an Axelos trademark. But you knew that already.