Why I don’t hate ITIL (aka ITIL in a DevOps world)

Why I don’t hate ITIL (aka ITIL in a DevOps world)

Date: March 18, 2020


Author: Stefan Apitz

When I read Greg Ferro’s infamous “Why I hate ITIL so much” blog back in 2015, I have to admit that I agreed with most (albeit not all) of what he said. Maybe it’s the issues that I have with authority in general, or maybe it’s my many years of working within the constraints of ITIL and ITSM in operating systems and services – but I truly believed (and still do) that well-educated, experience and consensus-based pragmatism is what actually gets things done. Frameworks such as ITIL are very useful as well-established references, but they can also be quite dangerous. If followed by the book, they tend to create overly dogmatic and siloed working environments, with massive amounts of overhead and endless deferred responsibilities. Or in short – the opposite of everything that is fast moving and innovative.

But as I matured, along with the IT world, I embraced an opinion that is more nuanced and in fact makes a case for ITIL in certain ways. I would say that ITIL – as with many things – is good in moderation and in my experience actually still has a place in newly formed startups, as well as large enterprises, as they transition to more modern IT and business practices.


ITIL – what it is and where it came from

Not many are aware of this – but ITIL as a framework was conceived to deal with the insufficient quality of IT services in the British government and published towards the end of the 80s, 30 years ago! The goal was to align IT practices with the needs of the (Government) business. This work was done over some period of time and in many revisions resulted in an extraordinarily comprehensive set of processes, definitions and methodologies.

The fact that ITIL as a framework came during a time when the top consulting firms began moving into the IT consulting segment is no coincidence. They approached developing and implementing frameworks and best practices for IT, similar to how they had traditionally run management consulting engagements for strategic and organizational planning.

In the early 2000s, when compliance became a significant requirement, the appetite for well documented and predictable processes and methodologies grew even more. Auditors appreciated adherence to known frameworks, the stricter the better, causing enterprises to err on the side of managing risk by becoming more rigid in how they operated as a result.

There are many intros and primers for ITIL, so I am not going to attempt to rehash any of them here. If you’re really interested – here’s a good resource.


Change and DevOps are upon us

Rising competitive pressure by digitally native startups and customer expectations are driving companies to rethink their products, customer engagement models, business processes and tools. Digital transformation has been a major topic for some time now and as enterprises embark on their journey to modernize and become digitally mature, new agile approaches such as DevOps are playing a key role in making this happen.

A common way to think about their state is the DevOps-typical classification of Software Delivery Performance, which defines how quickly and frequently teams can deploy changes into a production environment, at a low error rate. In order to become a high performer by these measures (i.e. deploy many times daily without causing production impact), a lot has to happen in ownership models (often referred to as a shift left), cultural and organizational paradigms and most importantly technical capabilities, such as embracing cloud, end to end automation and a redesign of applications and services.

While DevOps covers much ground here, in particular in regard to Deployment Pipeline (DP), it does not provide a lot of guidance in terms of how business processes (outside of IT and Development) should be reconsidered.

It is interesting to see that now that DevOps is prevalent in many enterprises and providing engineers with the ability to develop, deploy and manage directly without the need for formal IT Ops processes and artifacts, we are seeing many large businesses who are looking for more formalism. Understanding that these services are mission critical, concepts around Change Management, along with proper documentation and communication of release and risk assessments have become a necessity.


ITIL – to the rescue?!

Surely the title is an exaggeration – but: when measuring one’s progress along the lines of modernized criteria as discussed above, common / well-known frameworks such as ITIL can still provide a good baseline as business and IT operational processes and methodologies are revised. Especially when one considers a typical large enterprise, where a high degree of heterogeneity in service and infrastructure design is the norm. ITIL can remain as a relevant and useful methodology that continues to provide a common language and framework as technologies evolve.

At Oracle for instance we had the challenge of dealing with our own multi-generational services infrastructure, as well as a slurry of acquisitions that all had very different operational models and technology architectures. Simply moving to Oracle’s own gear and tooling alone (which was hard enough) was insufficient, as services and apps were designed to be developed, deployed and run in different ways.

Dealing with this situation required a common way of thinking about systems and operational concepts. Most people in the company itself as well as customers were accustomed to speak about our IT Ops capabilities and plans in terms of ITIL and ITSM concepts, even when we described the future of where our Cloud based infrastructure and services were heading.

Therefore, a reasonable approach, which we took, was to focus on converging all Operational capabilities into a framework that we could wrap our minds around and achieve a commonly agreed upon operational model, based on general ITIL concepts.


The more things change, the more they remain the same

Coined by French writer Jean-Baptiste Alphonse Karr and used in a slightly different way in a Motorhead song, this sarcastic statement has many truths to it. Mainly, that no matter the changes we see in our IT environments, IT Ops process concepts remain in principle the same. Automation of deployments and Software defined infrastructure allow for an increase in speed and predictability, independent of who owns them. A change made to the production environment remains a change, independent who implements it and how it is released and at what speed. Risk assessment of changes remain foundational.

And to that effect, ITIL (especially in its recently revised form) enables Enterprises and companies providing solutions for Enterprises to reason about operational concepts in a way that is familiar and well understood. As companies transform towards a vision of Autonomous Ops – responsibilities and the architecture of systems are changing. But fundamental principles remain, no matter how automated or self-driving one’s services become.