Integrating DevOps into the ITIL Orthodoxy

I use the word “orthodoxy” very deliberately, intending it to be merely a statement of fact, without any judgements. The Oxford dictionary defines orthodoxy as “an authorized or generally accepted theory, doctrine, or practice.”

This certainly sounds like ITIL to me! ITIL is the lingua franca of IT Operations and Service Management, with over three million certified IT professionals and many (if not most) Fortune 500 companies using it. At a minimum, ITIL is something that everyone in the DevOps community should be familiar with, if only to be able to form credible and mutually-respected relationships with those we need to work with. Also, as organizations born in the DevOps world are growing, there is a lot to learn from the experience and codified practices of the past 26 years - both in terms of what to do, and what not to do.

I’ll speak more specifically about some of the common challenges with how organizations interpret ITIL later in this article, but first, I want to describe my relationship with the ITIL community. My ITIL adventures started around 2001 with Kevin Behr (one of my fellow co-authors of The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win). It provided a structure and a lens to study the practices of high-performing technology organizations. Hanging out with ITIL people was extremely rewarding, and I learned so much about continuous improvement in practice, it substantiated my belief that process and controls were important in order to achieve organizational outcomes. (As you might imagine, these beliefs would later become even further crystallized studying audit!).

You can get a glimpse of how I view the ITIL community in The Phoenix Project — the two characters that our protagonist Bill relies upon most are Patty and Wes. Wes is the Director of Distributed Technology, embodying the cowboy server admin culture, and Patty is the Director of IT Service Support, embodying many of the sensibilities of ITIL. I still love this description of them as the opposite poles:

Where Wes is loud, outspoken, and shoots from the hip, Patty is thoughtful, analytical, and a stickler for processes and procedures. Where Wes is large, combative, and sometimes even quarrelsome, Patty is elfin, logical, and level-headed. She has a reputation for loving processes more than people and is often in the position of trying to impose order on the chaos in IT. She’s the face of the entire IT organization. When things go wrong in IT, people call Patty. She’s our professional apologist, whether it’s services crashing, web pages taking too long to load, or, as in today’s case, missing or corrupted data.

But let’s face it, many of the challenges with ITIL adoption that we faced fourteen years ago are still here: how do we best use the guidance to create processes that don’t suck the will to live out of everyone it touches, especially around change management? How do we compel everyone to keep our configuration management system up to date? How do we ensure that problem management doesn’t turn into a nasty blame game?

One of the modern miracles of DevOps principles and practices is that many parts of ITIL processes can now be automated, solving significant challenges, especially in the configuration, release and deployment management processes. For instance, a deployment pipeline often fully automates our deployment and release steps, and infrastructure management tools such as Zookeeper and Consul make service discovery and dependency mapping (the traditional domain of configuration management) just one more part of every development team’s daily work - if developers don’t get it right, their service won’t run, won’t know how to connect to other services, etc.

And because DevOps requires fast detection and recovery when service incidents occur, the ITIL disciplines of event, incident and problem management remain as relevant as ever. And automation continually frees more of our time to focus on value-adding service improvements.

But if we want DevOps to be widely adopted in large, complex organizations, the DevOps community must earn the trust of ITSM professionals and see how our efforts can help solve some of their most fundamental and chronic challenges—the same challenges that many in the ITIL community have been trying to solve for over two decades.

Here’s one of the sessions I was most excited about at the DevOps Enterprise Summit that took place in London on 30 June and July 1 2016: Kaimar Karu from Axelos, the custodians of ITIL, hosted an Open Space session, teaching us how to bridge the gap between DevOps and the ITIL processes and practices that are found in almost every enterprise. He taught us what we should say when we hear a change manager say, “we do DevOps over my dead body,” or when a service manager says, “this will never work here.”

Kaimar explained what has changed in ITIL in the last 10 years as the framework has evolved from a primary focus on IT Operations to covering the whole Continual Service Improvement powered service lifecycle from Strategy and Design through to Transition and Operation. He also discussed the philosophy behind the recently released ITIL Practitioner guidance, designed by a global team of industry heavyweights including our own Kevin Behr, to help IT professionals get the customer back to the centre of everything they do, and move away from the often too common process-first view of the world. He described the magic words that we can use to build a mutually collaborative relationship that helps our organizations win in the marketplace.