DevOps vs ITIL. Fight! (... or Friends?)

Posted on: April 30, 2014 by Mike Smith

Over the past 25 years IT service management has evolved into a set of well-defined processes and procedures, with most of the industry adopting ITIL; the IT Infrastructure Library.

But a new kid on the block is changing the way we approach the management and operation of our IT services – providing a more responsive and dynamic application environment. And keeping our service managers awake at night.


DevOps is a combination of Development and Operations (as the name suggests!) It is a software development philosophy to encourage the communication, collaboration and integration between software developers and the operations environment. The objective of DevOps is to diminish the barriers between software development and IT operations and is used by organizations pursuing both continuous integration and continuous delivery.

Addressing the demand to reduce “time-to-market” for applications and services, we have seen many initiatives to increase efficiency, effectiveness and agility of organisations. Initiatives such as service-oriented architectures, industrialisation, software quality improvement, agile processes and lean, among others.

However, all of these initiatives are largely focused on the speed of development, and most of them are the domain of the project team. They are instruments to assist in the development of applications predictably, rapidly and to eliminate errors and waste during the development process.

But this is only half of the story. The application or new piece of functionality has to be made available to the users; in production.

This is where DevOps, managing code all the way into the production environment, makes the difference.


Let’s now take a look from an operations perspective. The latest version the library (ITIL 2011 edition) has five volumes, of which volume four covers “Operations”, describing the essential standard processes for efficiently managing IT services. However, it is actually volume three, Service Transition, where we see the most profound impact by DevOps – and specifically with the areas of Change Management, release, deployment and monitoring.

In the well managed and well-controlled IT environments we have historically presided over, we have experienced (… and continue to experience) long release cycles; with perhaps just one or two major application releases per year. We store up a plethora of requirements and resulting changes, then in the landscape of development, test, pre-production, production, disaster recovery (and perhaps more) environments we slowly test, prove and gradually roll out each release across the landscape over a period of time. Change Management and precise control over the Configuration Items helps us understand the impact of what we are doing, and enables us to roll back in the event of an issue; or manage situations using our other favourite processes from volume four – incident and problem management!

The other common characteristic is that this managed release of new features is accompanied by planned service outages. Something that IT has imposed on the business historically, but which is increasingly spurned.

We are also witnessing the development of a new paradigm in the IT services industry today; as customers seek to award smaller outsourcing contracts to multiple services provider we are seeing the emergence of Service Integration and Management (SIAM), especially in the realm of UK Government again. SIAM could be considered an evolution of ITIL in some respects; joining together the delivery of technology Towers from different service providers, all managed and assured by a SIAM function which undertakes various ITIL processes (and more) across the whole landscape.

When Worlds Collide

So development and operations come from two different worlds today. The development process is focused on delivering new features faster; Operations is focused on a manageable and stable production environment. During the development process, many concerns of different stakeholders are taken into account, but often the requirements of the operations stakeholder are forgotten. One of the principles of DevOps is to involve operations into the development process and to involve developers into the operations environment. Or further, do away with the divide altogether and have a combined production team.

Joining these different roles and making both parties aware of their service focus and concerns lowers the barrier for dialogue. Developers will get to know the constraints of operations and are able to take into account these constraints during the development process.

But it goes further than that. When we discuss DevOps approaches we are now also (sometimes) implementing Kanban techniques to manage the workload of a continuous release train of small incremental changes; perhaps performing ten releases per day, delivering software and adding new features and functionality to address the demands of the business. A whole new way to deliver agility right into the production environment; exploiting automation technologies to give consistency, repeatability and efficiency.

I’ll just pause here and recognise now that there are some environments where DevOps will not be appropriate today – I’m not saying we should use it everywhere. Okay, let’s move on.

Another area where we have a crashing together of these different styles of management is when we have DevOps application deployments that are hosted on traditional shared hosting services. We need to marry the continuous and lightly managed Kanban environment with the heavily ITIL changed-managed network and hosting infrastructures. In some ways, the necessary rigidity of the network change environment will hamper the DevOps philosophy, so it may make more sense to move to a new type of software-defined architecture. Indeed, some of the technologies that are enabling this new approach include Software Defined Networks with OpenFlow, OpenStack and OpenShift. (Everything is Open these days isn’t it!)

Next Generation Service Management

Service management will need to evolve. The Service Manager (which may be executed by various roles in different organisations) is now not only responsible for the availability and performance of the production environment; but now also responsible for the development process and deliverables too! Not just reporting on availability and performance of a service against arbitrary KPIs (Key Performance Indicators); but driving the rate of change and dexterity that is required to respond to business demands.

We can no longer rely on a monthly reporting regime and just attend a monthly service management meeting – it is a continuous interactive activity; marrying the daily demands of the business with the delivery of new functionality.

As with other Agile development techniques a standard Waterfall approach is incompatible with DevOps and Kanban; we can’t just wrap old-world techniques around new approaches and expect them to work. The same applies to the typical CAB (Change Approval Board); often held weekly on complex services, or daily in busy environments, but this has to be replaced by automated testing, approval and release techniques. So most organisations will find themselves having to cope with a mixed DevOps and Waterfall environment. At least for the next few years.

In such a dynamic environment Product Managers own the user story, and this drives the development of any new piece of functionality. Quality Assurance managers need to ensure functionality is not broken by new features, and special care needs to be taken to ensure configuration issues don’t affect other customers if there is a common code base.

The service desk, ticketing systems and service monitoring tools all rely on the information contained within a Configuration Management Database (CMDB); if DevOps now begins to dynamically change the environment we need to ensure we capture this in the CMDB too.

We’re Building the Bridge

We are using DevOps for some of our services already … and we’re introducing more. This, combined with open source tooling and GitHub repositories, is increasing development agility all the way into production. Github, for the uninitiated, is a cloud-based software version control system with collaboration features. But this also breaks down the barriers between the historically separate Development (“Systems Integration”) and Operations (“Managed Services”) organisations – and whilst there can be problems (we noted above that rapid development can lead to configuration management issues) the pros do outweigh the cons in the right circumstances and for the right services. This DevOps approach also goes hand-in-hand with new dynamic infrastructures with automated provisioning for scalability – another transformation that we are seeing in the industry at the moment.

It’s an exciting time – what we’re doing right now is building the bridge between ITIL (and SIAM) and Agile. Maintaining control of the production environment whilst enabling the speed of delivery for new functionality; getting the best out of both worlds. So I believe DevOps and ITIL will indeed become friends and we’ll see both playing together, though like all maturing friendships they’re bound to have a few hurdles along the way.

Share this blog article

  • Share on Linked In

About Mike Smith
Chief Technology Officer, Atos Distinguished Expert, Founding member of the Atos Scientific Community
Mike has been in the IT industry for over 20 years, designing and implementing complex infrastructures that underpin key Government and private sector solutions. Setting Atos technical strategy, researching new technologies and supporting the consulting and architect communities. Previously Mike has held technical and management positions in British Rail, Sema Group and Schlumberger. He has a daughter and a son, both keen on anything but technology. Mike's sporting passion rests with Test Match Special, and is jealous/proud of his son's Ice Hockey skills.

Follow or contact Mike