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.”
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:
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).
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:
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.
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:
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? Read about our DevOps Foundation training.