Skip to content

How to Modify ITIL to Accommodate DevOps

April 4, 2014

If an IT management idea could ever be said to be “exciting”, then perhaps DevOps is a strong candidate. Its basic idea 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. 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.


 About the Author, Noel Bruton:

Noel Bruton’s Services related to this article…





From → How To, Process, Strategy

  1. Hi Noel, interesting article, glad to see you involved.

    Disclosure – as you know I’m not a proponent of ITIL centered service management, its but a valid and important contribution to one thats focused on the customer.

    Well I’m going to take a somewhat different tack here, although I agree with your points 2, 3 and 4.

    Its my long standing belief DevOps is a symptom of poor or absent ‘product management’.

    If you include that overlay, where someone is actually responsible for the candence of improvement, in a product’s capability, in priorities, then this is so much easier to shake out.

    As for adjusting ITIL, I think its a two-way street here. As you rightly opened, DevOps is largely a movement within some more vibrant quarters of application development, often associated with startups, and organizations where business change is happening at that proverbial ‘speed of light’.

    Not all changes/improvements fit an agile approach, some just take time and discpline, but all help illustrate the huge difference between the languages, culture and goals of the business/enterprise, development, operations and supplier communities.

    Rather than modifying ITIL per se I’d suggest adding both the product manager role back into ITIL (you know – the one they deleted in the Edition 2011 update!), and policies (operational rules – dos and donts) that explain where to flex the traditional ITIL lifecycle to address the need where changes are driven at the spped of business, and processed based upon the 30-60-90 day rule.

  2. Marc James permalink

    Hi Noel,

    Interesting reading for me as IT leadership where I work is currently trying to introduce a kind of hybrid of Agile/DevOps/LEAN/Kanban/Systems Thinking methods. We’re a typical infrastructure shop, with 1st-3rd line and silos just as you describe so I can see the potential benefits where the work is proactive – you mention projects and routine maintenance for example.

    However you go on to say..

    “…and the occasional reactive interruption”

    In my experience, incidents (failure demand) and requests (value demand) are anything but occasional. Reactive work accounts for a significant proportion of activity in most production environments and I have yet to be convinced that DevOps or Agile is geared up to respond to it.

    This is particularly evident when we introduce Kanban’s WIP limit principle. I can see it happening in my workplace already…

    “Sorry, Joe User, we can’t fix your computer or deploy your new phone this week because we’re up to our WIP limit building UAT servers and tweaking some code. Perhaps next week you’ll be able to do your work again”

    Incident management based on ITIL practices is tried and tested. If it doesn’t work, the reasons are usually organisational not procedural.

    Thanks for the article.


  3. Reblogged this on Rob Thatcher and commented:
    This is an interesting article although I’m not quite convinced modifying ITIL is the correct place to start the debate, I think I prefer the concept of adding useful parts of ITIL to other methodologies, to suit the business requirements.

    Of particular interest is the consideration of how, or if to implement ITIL in organisations where it is not in place, seems this could be the opportunity to cherry-pick some ITIL framework ideas and mould them into supporting and complementing Agile to organise and improve the reactive capabilities of IT Ops.

    However you slice it, smoothing the flow through IT is the endgame.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: