ITSM vs. DevOps: Which Side Are You On?

BrandPost By Barclay Rae
May 15, 2017
Cloud Computing

Don’t choose between ITSM and DevOps; embrace both disciplines for greater flexibility, agility, and control.rn


“We aren’t doing ITIL or ITSM any more – we’re a DevOps shop now.”’ “ITIL is too slow and formal for us now.” “We’re far too process driven and formal to do DevOps – it won’t happen here.”

In the IT industry, we often hear such varying opinions around DevOps and IT Service Management. These concepts are typically pitched against each other, as an ‘either/or’ decision. – so we either are an ITIL or a DevOps house. The same applies to many other ‘new’ concepts like Digital Transformation, SIAM, IT4IT, Lean etc.

It feels like we are being forced to pick a side; to put ideas and models into boxes and keep them separate – often in conflict with each other. While these trending topics provide for interesting reading in the tech news cycle, it can be costly, confusing and unhelpful for practitioners and their businesses.

Do we really need to pick a side? To the contrary, we need both. We’re talking about complementary, not competitive boxes. We need to be able to work smarter and quicker, but we also still need process and control. Modern, high performing teams and organizations are starting to realize this and use elements of both – they’ve moved beyond the “either/or’ ultimatum.


There are many misconceptions about what is delivered by ITSM and DevOps, how they work together and common mistakes made when practicing in them together. Let’s debunk these myths to avoid confusion:

1.    DevOps can replace ITSM – there’s no need for Services and Ops.

Some IT organizations proclaim that they don’t do ITSM/ITIL, as they are now DevOps organizations. While they may have moved away from ITIL training and process silos, they still need to do some aspects of Service Management. If the service is simply technology there is still a need to manage it — ops, support, governance, costing, etc. However we see these processes, they represent the key elements of Service Management. They are essential business functions that can’t be ignored.

Gene Kim, DevOps guru and author, is clear on this: 

For many years, I’ve felt that I’ve been the official ITIL® apologist in the DevOps community, because I’ve always believed that DevOps and ITIL should be able to peacefully coexist. But these days, I feel that a more activist role in the DevOps community is necessary – we must reach out and form effective bridges with the ITIL community, because ITIL is the most powerful and entrenched orthodoxy in large, complex IT organizations.

2.     DevOps is entirely about continuous development, integration, and automated delivery

This couldn’t be further from the truth. DevOps does include these things, which of course have helped to drive the opportunity to speed up development, delivery and service updates. But much of the context and ethos behind DevOps is about moving away from old divisions and working together – collaboratively. Although too often this is just seen as ‘Dev’ and not ‘Ops’.  

Whilst the opportunities created via automation and continuous working represent a catalyst for the industry, DevOps is also a huge opportunity to remove technical debt, build small agile teams across developers and operations. There is also the “new culture” aspect of DevOps, which recognizes the need for collaboration, respect and a move away from blame cultures.

3.    ITIL/ITSM involves heavy, onerous documentation and process

Nope. There are way too many bad instances of ITIL being misappropriated as “the rules,” rather than guidance, open for interpretation. Just because we need a process and a document doesn’t mean that these have to be cumbersome masses of documentation. Similarly, there is no excuse for hiding behind processes or the of ITIL “rules.” Many Ops professionals have built huge structures of process and bureaucracy to protect themselves from accountability. DevOps is a way to open that up and be successful with ITIL, across the whole business.

4.    ITSM/ITIL is only practiced by large enterprise organizations.

Again the experience is mostly true here, as it has tended to be large enterprises that have taken on ITIL. However, as in #1 above, the key business elements remain for all organizations and these need to be provided regardless of size. Cool start-ups need to get organized and structured at some point, otherwise they will fail to scale and grow efficiently.

In summary – we need the key elements that are found in both ITSM and DevOps – whether we use these explicitly or not. DevOps is much more than just automated development; it involves collaboration and a blame-free culture. As well, ITSM/ITIL shouldn’t be pigeonholed as an administrative burden, but rather used in an agile way. ITIL in particular isn’t perfect and needs a more modern veneer — but the core practices are sound and proven.

Interested in learning more about the future of ITSM software with DevOps? Find out here.