Why DevOps is like IT service management

Why is DevOps like IT service management?  

Because neither of them are fundamentally about the technology...but as technology advances, so do our ways of managing it.  In this blog, we'll explain more.

There has been a lot of discussion, and argument, on how DevOps will be the downfall of IT service management (ITSM) and ITIL; or alternatively, that DevOps and ITSM complement each other.

But it’s not so “black and white” – DevOps is incompatible with ITSM in many ways, but it’s strangely compatible in others. For instance, for years the ITSM community has used the mantra of “a fool with a tool is still a fool” as a way of saying that successful ITSM requires so much more than just new technology. That, while new technology can help, it also requires an investment in people and process. Ideally with an accompanying mind-set shift that takes on board the concept of “IT as a service.”

So ITSM adoption can range from a mind-set change, with new processes, training, and the re-skilling of existing and new staff through to buying the simplest of help desk tools to merely do the most basic of ticketing.

Equally you can do (parts of) DevOps “on a dollar a day.”

ITSM: Why a Fool with a Tool is Still a Fool

There are no shortcuts to real ITSM success and no shortcuts with DevOps, especially not in large, complex enterprise organizations.

History is littered with the corpses of failed ITSM tool projects. You know the story: a huge investment in an ITSM tool failed to deliver the promised benefits or maturity. So cue the blaming of the tool vendor, the blaming of the implementation staff, and the blaming of ITIL.

People aren’t fools, so why does this happen? Consider the following scenarios/approaches:

1. “If I make people use the tool that I choose and control, then I will ensure that we do ITSM my way” – and then the organization has multiple ITSM tools owned by different people.
2. “The existing tools aren’t fit for purpose; they aren’t “cloudy” enough. I need the latest whizz-bang-shiny gadgets” – and cue the groans from the old timers who’ve seen it all before.
3. “If I install this tool with all the ITIL processes in it then, voila! We are ITIL ‘compliant’” – and veins start to bulge in the temples of seasoned ITSM professionals.

Let’s Take a Trip Down Memory Lane

How did IT support people track incidents, share knowledge, and do other ITSM activities before the fancy ITSM tools arrived with promise of help? White boards, paper forms, telephone calls, maybe email and Microsoft Excel. Plus of course we had far more unrecorded “walk ups,” with immediate fixes, than most likely seen these days.

While it might not have been scalable, it probably worked. Responses and fixes might have been slower, and maybe some fell through the cracks but the IT still got supported. The technology then improved upon manual methods in many ways from tracking events (communications, changes, incidents), enforcing policies, and reporting performance and insights but IT support did manage to work without it (albeit in a suboptimal manner).

DevOps: It’s the Way Not the What

As with IT support, the “Three Ways” of DevOps” actually do not need any technology at all. The first way can be done by value stream mapping a product process with paper and pen. The second way can be done with a wall chart. The third way can be people sitting around a table.

The issue with these DevOps “ways” is that, well, it’s all people stuff and people stuff is hard for those who are more comfortable sitting in front of a keyboard than being in front of people. As with the ITSM scenarios, typical technology-led DevOps approaches are:

1. “I need an online Kanban Board with an API that we can all access remotely because we never meet each other in person.”
2. “I can only do Continuous Delivery when I have the latest Continuous Integration suite from Acme Corp that integrates with all the clouds.”
3. “To amplify feedback I need the latest metering system and artificial intelligence to understand what’s happening in the real world.”

And, as with ITSM, the technology is not mandatory. James Shore blogged that it’s possible to do Continuous Integration on a Dollar a Day with no advance technology. All you need is an old computer, a rubber chicken, a desk bell, a script, and a can of Kool-Aid.

But Expect DevOps and ITSM Technology Convergence

While DevOps and ITSM can both start from a position of “technology not required,” as they develop, and technology is introduced to help operations scale, then the two technology approaches diverge:

• ITSM technology is focused around the processes of service management. Think service desk, communicating with customers and others, and change management to track change requests.
• DevOps technology is focused around the products of the business, often depicted as a value stream (a series of steps that deliver value to a customer, such as a feature to pay a bill).

This divergence of paths suggests little overlap and offers opportunities for integrating both systems; and indeed we are seeing ITSM tool vendors add “DevOps” modules to their suite of more traditional products.

It makes sense that the tools for DevOps activities, such as Continuous Integration, are integrated with ITSM where that works in an organization. It also makes sense that the essential first step of Continuous Delivery in DevOps (track all configurations) is integrated with ITSM’s configuration management.

So DevOps and ITSM start together, then diverge, and finally converge together if an organic, evolutionary path is followed by an organization. But I know someone out there is thinking “Why don’t I shortcut all of this and just buy a tool that does it all?” And pretty soon...you will be able to.

Want to learn more?  View our  our course catalogue!