ITIL, DevOps, Whatever – The Labels Don’t Matter

There are many labels for how IT functions. The latest one is DevOps, with its predecessor (several times since iterated on) being ITIL. 

If you’re new to IT and unfamiliar with ITIL, it was introduced in the 1980s as the Information Technology Infrastructure Library and was comprised of IT best practices for a mainframe system. To avoid confusion as well as evolve with the modern IT environment, ITIL is now simply referred to as just "ITIL," and is defined as a library of information or a set of best practices for managing IT services. ITIL is often associated with ITSM, which stands for Information Technology Service Management. ITIL is the best practices, ITSM is the discipline. 

ITIL has been through several iterations and was most recently updated in 2011. However, a new update to ITIL is slated to publish this year and is expected to address ITIL as a complement to DevOps environments among other things. 

While the truest description of ITIL is a set of best practices, many IT teams took the five ITIL books (now six) and turned them into a rigid framework. ITIL is also often associated with the word bureaucracy, a slow, laborious process of approvals. This is where strict DevOps fans cringe because DevOps doesn’t have a definition and definitely isn’t a framework. 

There has been a lot of debate about whether ITIL is still relevant in a world consumed by software, or if it should be called something else, but experts believe that ITIL still holds relevancy even in a technology environment drastically different from the 1980s.

“As long as organizations rely on IT to run the business, and as long as they care about their customers, ITIL will stay relevant, -- but things do need to change,” says Kaimar Karu, international consultancy director for Mindbridge, and former Head of ITSM at AXELOS.

One of the issues that surround the ITIL relevancy debate, says Karu, is a collection of misconceptions about ITIL and how it is meant to function within an IT team.  

"ITIL is not about processes. It’s about customer value, flexibility, and continual improvement -- whatever the actual processes look like,” says Karu.

He also says that many IT departments didn’t evolve their IT strategy with the changing times, which can lead to a false perception of what ITIL is today.

"They were likely heads down trying to get their daily work done, and sometimes busy 'implementing ITIL', to notice the updates to the framework," says Karu, adding that many people still reference the previous versions of ITIL that had a stronger emphasis on processes, compared to the customer-centric approach from the past 11 years.

In interviewing IT experts about this topic I couldn’t help but notice how similar the misinterpretations of ITIL sounded like the issues that plague many DevOps teams today. Trying to make DevOps a framework for application and software development, where individuals in charge of different stages of the value stream become hyper-focused on their own metrics and can’t see the customer through the process.  

Damon Edwards, founder of Rundeck Inc. summed up this thought nicely:

“I think where the root of the problem is both where DevOps and ITIL go wrong. Think about what they are…ITIL is a library of IT best practices…the idea is you can take this to give you a common vocabulary and take it and mix and match and make it work for your organization. But then it’s become into a rigid implementation…It looks like a very siloed, fragmented world.

If you look at what DevOps is, it’s a cultural and professional movement…breaking down existing barriers to development and operations. There’s no implementation to it, it's a movement. Some people have taken it, especially in the enterprise, and have turned it into a rigid implementation.”

Whatever you call your IT team, the same issue keeps appearing: IT struggles to trust a philosophy over a process.

Image: Shutterstock

“The problem isn’t really ITIL and DevOps. The problem is IT,” says Jayne Groll, CEO of the DevOps Institute and former president of the ITSM Academy. 

“In IT, we are very loyal to our frameworks…thinking each one is going to be the magic bullet to solve IT’s problem,” says Groll. “While each of IT’s frameworks (ITIL, Agile, Lean IT, etc.) has delivered a specific area of improvement, none addresses all of the capabilities required to increase the flow and efficiency across the entire value stream. It is only when we instill systems thinking across all of IT’s frameworks, practices, and automation that transformation becomes a possibility.”

In other words, the perfect IT label won’t fix a broken mindset.  

Greg Sanker, author of ITSMtransition.com says the division that can happen when IT teams put their stake in the ground on a label can be damaging to the cause of that new movement.

“A split happened, and then people started applying a religious fervor to ITSM versus DevOps. The separation between the two is almost entirely beside the point and it’s the largest threat to the value that DevOps can bring us, which is focus on time to value, horizontal collaboration, and a culture of continual learning,” says Sanker, who is also the CIO at the Oregon Department of Administrative Services.

He adds that organizations don’t have to choose between DevOps or ITIL/ITSM because the two are not competing in any way.

“You can’t DevOps a firewall upgrade or a large scale Software-as-a-Service implementation, but you absolutely can and should apply the DevOps cultural principles to everything IT does,” says Sanker. 

The division between IT culture and capability labels is also almost entirely serving technology vendors and not the IT teams. 

"There’s a lot of tribalism in IT. Any framework or approach can become a religion when it becomes a label. There’s also a lot of money behind those labels,” says Karu. He adds: "Labels lose nuance and detail, so a great idea can become a bland fit-for-all 'silver bullet' that does stir things up, but rarely leads to any significant improvement." 

Rather than focus on labels, Karu says moving forward, we should place our focus on the principles. 

“If we focus on labels and multi-year implementation projects where the means become the ends, we will inevitably fail, again. I think that to find a way forward, we need to go back to basics, back to the guiding principles. Let’s focus on the principles.”