What IT service management can learn from DevOps

Lessons from past, present and future

Cultural changes aside, the root cause of the rise of DevOps is the benefits accrued via an increased use of automation.

It avoids many of the famed communication issues between silos, mostly because in most cases, the humans that might have communicated have been replaced by computers. Unlike humans, computers do exactly what they’re told, so there is no such thing as miscommunication. Computers also do repetitive tasks with great accuracy. Would an ITIL approach still work if most of the humans were replaced with Jenkins, Puppet, and shell scripts?

Don Meij, CEO of Domino’s Pizza, says the operational problems besetting most IT organisations are usually more to do with the implementation than the choice of approach.

“Too many companies become all about process,” he says. “CEOs fall in love with process. It’s almost how you justify what you do. It’s the cancer of an organisation if you don’t manage it properly.”

Peter Nikoletatos, acting IT director at the University of New England, says that IT Service Management and ITIL will still be relevant in the future. But organisations need to get better at how they apply it.

“ITIL is a framework, it requires tailoring,” he says. “Most organisations err on the side of too much sophistication. This makes things too bureaucratic.

“The enthusiasm for execution when implementing ITIL should be tempered. You need to put a realistic timeline in place. Build the services incrementally. Start with the easy things: incident management and problem management.

“Ground zero to fully deployed ITIL could take two to three years. That’s a significant investment in time. You don’t have to do all of it.

“Not every organisation lends itself to Agile,” he continued. “ITIL is just a way of thinking about a problem, but not the only one. ITIL is convenient because most people understand it. With Agile, we’re still learning how to use it. It takes a few years to build evidence that it works.”

Confounding everything is the rapid pace of change in the IT industry generally, courtesy of Moore’s Law. The kind of automation possible today was unthinkable in the mid-80s, while at the same time the explosion of data and data processing has created new problems that didn’t exist then. With the landscape shifting under your feet this much, can one approach to managing things really cover all bases?

To the delight of consultants everywhere, the answer on which of ITIL and DevOps to pursue seems perpetually to be: “It depends.”

As the old project management joke goes: you can usually only choose two out of three variables - fast, cheap and good. Both ITIL and DevOps purport to have the same ultimate goal—better business outcomes. It could be the case that ITIL has been optimised for Cheap and Good Quality, with less emphasis on speed while DevOps offers a different optimisation point - much faster and invariably cheaper. The question many are waiting to answer is whether it will deliver to the same quality.

A more constructive way to make a choice between the two is to assess the cost of change for any given solution.

Software benefits from rapid change because the cost of change is low. The lower the cost of change, the more change you can afford to contemplate. But the hardware it runs on is rarely so easy to change. Those who deploy hardware still need to consider the longer-term ramifications of their actions, or at least the cost impact of getting it wrong and having to change.

It makes sense to use the technique the matches the amount and cost of changes to your environment. Something that doesn’t change often, and costs a lot when it does, requires careful planning and change management. But for things that are relatively easy to change and don’t cost as much, trying many different options quickly makes a lot more sense.

On that basis, the need for complete reinvention is somewhat overstated. There is nothing in ITIL that says processes can’t be automated. It is, after all, just a framework, ready to be adapted to the specifics of your business, while still providing a standardised way of thinking about business problems.

ITIL folks stand to learn a lot by borrowing ideas from DevOps, just as DevOps people tend to recycle their configuration management software and trade Puppet recipes over the internet.

Compare and Contrast