DevOps and ITIL:<br />Mortal Enemies or BFFs?

Do you think that DevOps and ITIL^® are BFFs? Or are you or your organization under the impression that DevOps and ITIL are mortal enemies, incompatible, or somehow mutually exclusive?

I can understand how you could fall into the latter trap. You’re likely hearing that message from multiple fronts.

Many DevOps tool vendors often talk about their tools and “ITSM tools.” Some webinars and blogs talk about a “DevOps toolchain” that does not include ITSM ticketing and workflow systems. Or they’ll discuss how ITSM is something that only the service desk does. Many blogs and social media posts tout a similar message—how ITIL is just too slow or how ITIL can never work for the modern business.

Perhaps these messages are appropriate, especially in situations where ITIL adoption has fallen short.

Where ITIL Adoptions Have Often Fallen Short

In my experience, many of the issues that organizations use to justifying an adoption of DevOps have nothing to do with ITIL itself…it’s usually how the organization adopted and adapted ITIL. Here are a few examples:

• Only the IT operations department adopted ITIL: This is one of the most prevalent reasons why ITIL adoption has fallen short.  IT operations is concerned with stability and security—and rightly so. Applications development is focused on innovation and responsiveness—and rightly so. But many IT organizations stood up ITSM only in operations in an effort to deliver stable and reliable systems to the organization. As a result, an obstacle called ITSM was put in place between the operations organization and the rest of IT.
• ITIL only supports a waterfall approach: I suppose that this is a fair argument, especially in light of how ITIL is typically presented in training courses. But nowhere does the ITIL v3 books document that ITIL is only to be used with projects that are following a waterfall methodology. 
• ITIL is too bureaucratic for today’s digital economy: I would argue that the use of ITIL within your ITSM approach is only as bureaucratic as you’ve made it to be.
• All change requests have to go before a change advisory board (CAB): This is the most egregious aspect of many ITIL adoptions, having a CAB review and “approve” every change. Making it even worse is that usually the people on a CAB have not been provided with any kind of criteria for evaluating a change request. Nor are they provided with sufficient detail or background of a proposed change. Nor is the CAB meeting anything more than theatre—a performance that delivers no relevant impact or results. But it sure looks good on paper.

The fact is that there is nothing described in ITIL v3 that indicated that any of the above approaches was how it must be done.  Each of these issues is as a result of how organizations have chosen to do things. And many times, ITSM implementation based on ITIL was treated as a “once and done” project. So, it’s easy to understand why so many organizations harbor the misconception that DevOps and ITIL are mortal enemies. The fact is that many DevOps concepts are built from or augment ITIL concepts.

Many organizations harbor the misconception that DevOps and ITIL are mortal enemies. The fact is that many DevOps concepts are built from or augment ITIL concepts.

Good DevOps Leverages ITIL Concepts

Here are just a few ways that DevOps leverages long-established ITIL concepts:

• Change: ITIL has long promoted the concept of safe and reliable delivery of changes to managed environments. DevOps has built from that concept and added the idea of smaller change increments delivered at greater velocity.
• Validation and Testing: ITIL aims to ensure the delivery of high-quality solutions to an organization; one of the ways ITIL does that is through the Service Validation and Testing process. DevOps also promotes the development and delivery of high-quality solutions by promoting smaller increments of work. This approach drives improved quality, because there is less to validate and test within those smaller increments of development.
• Configuration: Within ITIL, the Configuration Management Database (CMDB) represents the single source of truth for how managed components work together to deliver a service. The CMDB represents the known, good versions of these components within the managed environment. This information can be used as a reference when rebuilding or restoring the managed environment. Similarly, DevOps uses a shared version control repository that contains all the artifacts needed, including application code, environment creation tools, supporting scripts, configuration information, and more, that can be used to rebuild or restore the working environment. 

Along Comes ITIL 4

With the publication of the ITIL 4 Foundation volume, ITIL is undergoing a bit of a (needed) facelift. While you’ll recognize many long-standing concepts in ITIL 4, there are also some significant shifts that acknowledge DevOps thinking.

First, the concept of the “change authority” is heavily emphasized. ITIL 4 defines a change authority as “the person or group responsible for authorizing a change.” This could be anyone from a single individual to an enterprise-wide executive committee. While a change authority was also discussed in previous versions of ITIL, ITIL 4 emphasizes the importance of clearly assigning the right change authority for the right types of changes. Yes, there can (and should!) be multiple change authorities within an organization; the key is defining the criteria by which a change authority is identified for a particular type of change.

ITIL 4 separates the Release Management practice from the Deployment Management practices. This differentiation embraces how many have approached release and deployment from a DevOps perspective, in which the deployment of software is often done separately and distinctly from the packaging of a release. For organizations adopting DevOps, ITIL 4 Release Management practice accommodates continuous integration, as well as canary (or pilot) releases and blue/green releases. Likewise, the ITIL 4 Deployment Management practice acknowledges continuous delivery and continuous deployment.

ITIL 4 also explicitly identifies a software development and support practice. While software development was implied as part of the Service Design lifecycle phase of ITIL v3, ITIL 4 explicitly acknowledges the critical contribution of software development and support to products and services. 

If You’re Doing It Right, DevOps and ITIL Are BFFs

So, this notion of DevOps and ITIL being mortal enemies cannot be any further from the truth. In fact, if your organization is suffering with an ITIL adoption that has fallen short, DevOps thinking can help.  But that doesn’t mean that you must scrap what you’re doing with ITIL.

Both ITIL and DevOps want the same things: high levels of quality, high rate of success in implementing changes, great collaboration and communication within IT, and real business value. If your ITSM implementation isn’t delivering these results, try mixing some DevOps and ITIL together. If you do it right, you’ll find that DevOps and ITIL are truly BFFs.

Join Doug for a pre-conference workshop on Incident Management at Service Management World!
Join us!

ITIL^® is a registered trademark of AXELOS Limited.

Doug Tedder is a strategic, innovative, and solutions-driven IT service management professional with more than 20 years of progressive experience across a variety of industries. He’s a resourceful and hands-on leader with track record of success implementing ITSM and IT governance processes. Doug is a certified ITIL Expert and ISO/IEC 20000 Consultant Manager and holds many other industry certifications. In addition, Doug is an accredited ITIL Foundation trainer and HDI Support Center Analyst and Support Center Manager instructor. Follow Doug on Twitter @dougtedderand connect with him on LinkedIn.