What IT service management can learn from DevOps

What is DevOps?

Many that have expressed dissatisfaction with ITIL processes have found that the DevOps model – an extension of the agile methodology – ticks many of the boxes ITIL and IT Service Management can’t.

DevOps as a concept rose to prominence in 2009, mostly by the launch of “DevOps Days” in Belgium by Patrick Debois. DevOps is a portmanteau word combining Development and Operations, which describes what appears to be the core ethos of the approach: development and operations working together.

The greatest difficulty with DevOps is that no one, not even its practitioners, seems quite sure of what DevOps is exactly. Some call it a software development method, some an approach to IT management, while others call it a “global movement”.

The common thread in describing DevOps is largely a reaction to the silo approach taken by many companies when they implement ITIL processes.

In the ITIL world, developers are responsible for updates and changes, while IT operations are responsible for keeping everything running. This approach often leads to mismatched incentives, where operations is motivated to reduce change (and keep things stable) while development is all about changing things.

The rise of the Agile approach to software development in the early 2000s - and its emphasis on rapid release cycles - placed pressure on the formal change management and service transition processes recommended by ITIL. If a change board only meets once a week, releases into production cannot happen any faster. But if a company follows Agile to the letter, as many online companies do, you might release changes into production multiple times per day. The two worlds don't fit together very neatly.

So just as the Agile approach to software development replaces the waterfall method of SSADM, DevOps aims to replace the slow formality of ITIL-like processes when it comes to operations. DevOps requires that developers own the full lifecycle of an application, from development, through testing, deployment, and production support, all the way to decommissioning.

Large, online-centric companies like Flickr have shared their approach of merging development and operations at various conferences, and the technique has resonated with those also in a hurry to deliver value to customers.

A cornerstone of the DevOps approach is automation. Without it, large organisations couldn't conceive of such fast release cycles without introducing errors. Tools such as Puppet, Jenkins, and Selenium are all geared towards automating what were previously human-centric tasks. Instead of a change board of humans that meets once a week, automated software testing determines if a release is ready for deployment to production.

Automation tools have existed for decades, but their use has always been somewhat limited. The humble UNIX make utility was created in 1976, and subsequent tools, even HP’s internal MEDUSA tool, can all claim seniority over more recent tools like Puppet, Ansible, and Jenkins.

But as with so many technologies, arguably the previous tools arrived too early. There just wasn’t enough widespread need for them to be used outside of specific niches or companies. DevOps style automation has exploded in popularity because the timing was right.

Automation has very much been in demand since the turn of the millennia, initially for large online companies like Google, Yahoo, Facebook, and others. The success of these firms all depended on economies of scale for commercial success, and none could afford to hire a great many humans to achieve it. The task of curating search results, running AdWords auctions, and showing you which of your friends just became single is impossible for humans to do when you have millions of members. Paying one really good developer three times market rate to write software that replaces 15 systems administrators feels like a good deal.

Automation also fit the culture of online development in the ‘digital era’. Techniques and code originally developed by these large, online companies has been released into the world at large (consider Apache Hadoop and the Yahoo! User Interface Library), usually long after they conveyed any significant competitive advantage to the original company. It is easier for a tool or practice to become widely adopted if many people know that the tool exists, and even easier if the cost of acquisition is low. Today’s ‘digital’ operations within banks or telcos are often recycling code developed for social networks a decade earlier.

By the late 2000s, a critical mass of tools and techniques had arisen that would begin to seriously challenge the dominance of ITIL.

But does it really have to be a stark choice between ITIL or DevOps?

Can the two approaches co-exist? Read on as business leaders discuss this option...