DevOps: From Threat to ITSM Friend

For those of us in the IT service management (ITSM) space, DevOps appeared on our scene around five years ago. And at that time, to most in ITSM, DevOps was seen as an outsider pushing in to places it didn’t know enough about. Specifically, it seemed to be an entirely development-driven concept that suggested IT operations wasn’t actually needed – that getting development right meant NoOps was perfectly possible, where NoOps is “the concept that an IT environment can become so automated and abstracted from the underlying infrastructure that there is no need for a dedicated team to manage software in-house.”

In the absolute sense, this is perhaps even correct. If you could build an IT system that was perfect, in that it never failed, and is so flexible that it’s adaptable to every change in customer needs, environment, legislation, etc. – then surely all you need to do is build and test it, then let it go delivering the service without any need for tinkering, fixing, or updating.

It’s like the idea of a car that never breaks down or needs servicing.

Of course, anyone who has ever owned a car knows that it’s a worthy ideal but a practical impossibility. To take the truism from continuity management and disaster recovery: “Anything that can go wrong will, and lots of things that can’t possibly go wrong, also will go wrong”. Translated into the world of DevOps, this means that while we can build the best, we’ll still need to then manage, maintain, and improve it, plus fix it when, inevitably, there are issues.

This was the logical reason for many ITSM people initially rejecting DevOps, backed up by the inevitable human dismissal of anything external venturing into your own backyard and telling you what to do. Whichever reason for the knee-jerk dismissal you go with, there was certainly resistance and resentment from the mainstream ITSM community.

Time and Understanding Can Heal

But, fast-forward five years, and things are now different. Now it seems that DevOps and ITSM are synergistic; with both essential elements of getting the right service built and in place, and then keeping that service right, proper, and adapted to changing circumstances.

It turns out that established ITSM approaches, such as ITIL, already have lots of stuff in there that’s “DevOps supportive” (of course I never doubted it). In other words, as with just about every framework and cultural approach, sensible approaches to IT management look similar. In the “ITIL supports DevOps” case, we find many synergistic planning and operational elements such as:

• Make maximum possible use of operations staff in service design, and
• Think about how you will run the service before you build it, and then build it so you can run it.

And there are many more specific little points we could pick up, but instead let’s look at the two key factors that have made DevOps and ITSM good friends and collaborators after all. These are having:

1. The right mix, or blend, of skills
2. One team pulling in the same direction

Mixed Skills in a Single Team

DevOps isn’t about employing “DevOps trained people” instead of development or ITSM staff. Instead, it’s all about putting a range of people together and benefiting from the multiplication of benefit that comes from having a single team with a range of skills and abilities working together. It isn’t saying that someone needs to be equally good across the whole development-to-operations range. It’s all about being a team where everyone:

• Understands that range well enough to see the whole service lifecycle from the initial gleam in the eye to a mature product
• Knows which of their teammates will be best at any specific aspect of the service build and delivery value chain
• Is happy to support every other team member by sharing their special skills and knowledge freely

And that leads us to the second key factor: it is ONE team, with ONE set of performance measures. When it’s understood that everyone succeeds, or everyone fails, then the artificial, and damaging, boundaries between groups can be broken down. By taking us to that single team, who swim or sink together, synergies emanate automatically.

What DevOps now offers to ITSM practitioners is to be part of a bigger “us” and not a “them” to waste effort disagreeing and competing with.

So how is DevOps in your company? Have you seen a coming together for the collective good or is there still a divide that stifles the IT organization from delivering the best possible IT services to its parent company? I’d love to hear your feedback. 

Oh, and if you want to read more about DevOps and ITSM working well together, please read another of my blogs: Where Is the IT Service Desk in a DevOps World?