ITIL and DevOps: Complementary or contradictory?

With the arrival of new technologies like virtualization and cloud, as well as new methods such as “agile,” pressure is on the release management and operations team to deliver development outputs to production more quickly. DevOps is a relatively new development that meets this need, raising many hopes for the faster, better delivery of new functions, from development to production.

DevOps is also a cultural movement bringing together the diverse capabilities and traditions of application development, release management, testing and operations – hence the name DEVelopment and OPerationS.

The diagram below depicts the critical drivers (red) and enablers (blue) for  DevOps success, thus establishing DevOps as a critical foundation for the digital era.



However, integration of Ops and Dev teams does not mean returning to old, bad habits of developers having access to production systems for on-the-spot tweaking or ops folks applying untested patches! Too much of  business today depends on IT. We can’t put our IT systems at risk by getting lax on governance and compliance.

Frameworks like ITIL (IT Infrastructure Library) or COBIT (Control Objectives for Information and Related Technologies) provide the processes and measurement systems to control risk and establish governance. However, these processes have often been implemented too rigorously and inflexibly in the past, to the extent that a “wall” was built between dev and ops that one could only scale with approval from the infamous “change advisory board.”

This concept was introduced in ITIL’s change management process. But it doesn’t have to be applied so rigorously. The architecture of the process allows for flexibility, depending on the nature and risk impact of the change.

Only “normal changes” with a certain, predefined level of risk have to be evaluated and authorized by a change advisory board or another level of seniority. “Standard changes” that come with little risk, are well understood and highly automated do not need the same level of review. Thus, they become the perfect type of change for DevOps!

Standard changes are used for routine requests such as installation of a new program on a PC or the delivery of a patch to a single server. The procedures are well known and completely automated. The same is true for DevOps-style changes: The risks are comprehensible and the possible impact limited since each step, from testing and packaging to deployment and monitoring, is heavily automated.

Thus, adding DevOps to ITIL is not a contradiction but a perfect complement, updating ITIL for the new reality of IT management. And this framework will be needed more and more as technology moves toward modern, single-purpose, loosely coupled systems and apps. Adding DevOps capabilities to our traditional process and governance environment will allow us to jumpstart in the digital era.

Shifting the emphasis on new technologies and process structures also has an impact on the IT organization. IT will now have to operate in two modes, since not all applications are suited for DevOps-style delivery. Besides mainframe solutions, the big, packaged applications such as SAP or Oracle will be upgraded in major releases for the foreseeable future.

With a bi-modal approach, organizations will need to move away from the traditional understanding of ITIL, being mostly for operations with emphasis on “incident-problem-change-config,” to the strategic elements of the service lifecycle, such as demand management, service portfolio management, governance and continual service improvement.

Markus Schweizer is an Associate Partner at DXC’s Digital Strategy and Transformation team in Switzerland. He has extensive experience in IT management consulting with emphasis on service management, governance and strategy. Connect with him on LinkedIn.


  1. Tim Coote says:

    ITIL’s definition of Configuration Management is different from, and incompatible with the development view. This can create a language trap.

    DevOps, if implemented using public cloud dramatically reduces the size of the CMDB/CMS, making it the revision control system, which includes the automated tests and actions to build the systems from scratch.

    Traditional ITIL approaches are often not economical: I’ve seen plans for ITIL CM where there’s much more spent on just identifying CIs than there is in managing the whole estate. The big challenge is data quality, which is hard to keep up, or even to measure. DevOps makes the configuration more reliable and ensures that it cannot drift from the running systems – not least because if it does, you just redeploy from the revision controlled deployments!


Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.