How DevOps Organizational Changes Impact ITSM

Imagine a river or sea separating two lands. On one side is the “Land of IT” and on the other is the “Land of Business and Customer.” A concrete bridge called “IT Service Management” (ITSM) exists to connect the two lands over the water that allows IT changes into the business in one direction, and requirements and feedback from the business into IT from the other direction.

This sounds sensible, but from a DevOps viewpoint the concrete ITSM bridge is an inhibiting chokepoint, which clashes with each of the three ways (or principles) of DevOps:

1. Systems thinking
2. Amplifying feedback loops
3. Culture of continual experimentation and learning

And if DevOps cannot co-exist with this concrete-bridge-choked organization, what is the impact on ITSM when DevOps is universally adopted? I might have just worried myself, and my mortgage provider, a little with this question.

The answer is that ITSM organizations need to be aware of the impact of DevOps, and then must consider and address the issues and challenges caused by traditional ITSM structures, processes, and behaviors. In this blog, I cover the main impacts of DevOps and then what ITSM organizations need to do to reduce the clashes with the three DevOps ways.

Systems Thinking: Move from Two Lands to One Nation

The first way of DevOps, the adoption of systems thinking, impacts ITSM because it requires an end-to-end (system) value stream that everyone can see and understand instead of siloed interconnected process-oriented functions.

There are three ways in particular that DevOps’ systems thinking is incompatible with ITSM:

1. DevOps requires a loop structure for delivering value and amplifying feedback that is inconsistent with ITSM process functions.
2. In terms of focus, ITSM is resource-oriented (“How do we make change management efficient?”) whereas DevOps is flow-oriented (“How do we efficiently get value into customer hands?”).
3. In terms of control and processes, ITSM has functional silos (change and incident) and DevOps has product teams (inventory, billing, and orders, for example) that are responsible for the value stream of their product.

What ITSM professionals need to do:

The impact of DevOps will thus mean that life will most likely become very uncomfortable for ITSM staff because their world view (controls and processes) doesn’t work with DevOps. And the result is either parallel, bi-modal IT or that ITSM collaborates with DevOps by moving from functional silos to distributing its business knowledge into the DevOps value streams.

Feedback Loops: Getting Out of the Way

An ITSM organization might pride itself on being the communication bridge between IT and the Land of Business and Customer. However, this can be seen by people outside of ITSM as being an awkward third wheel in the organization, being neither experts in IT nor in the business and customer.

Plus, many traditional IT organizations live in a climate of fear of the next outage or security breach, and for this reason they have top-heavy control systems that strangle not only change but communication. Someone, somewhere decides on who needs to know, which often results in thirty-person, ten-hour bridge calls that most sane people hate.

The second way of DevOps is to ensure that the performance of all aspects of the value stream, owned by the product team, are amplified and available to all. This is incompatible with traditional ITSM in the following three ways:

1. ITSM is no longer the sole conduit of communication. Functions such as the service desk can contribute to the feedback loop but they cannot control it all.
2. Traditional ITSM tracking systems, such as incident management, need to focus outwards not inwards, and have to evolve from being “process focused” to “product focused.”
3. Change management process and organizational structures such as change advisory boards (CABs) are a curse to iterative small changes and the feedback they require. With DevOps, CABs have to change and “get out of the way.”

What ITSM professionals need to do:

These impacts will cause discomfort for traditional ITSM communication methods that focus on control from the organizational center, which is not fit-for-purpose for distributed DevOps flows. These DevOps flows make all information available so a central team can monitor things without getting in the way. But for that to happen, the ITSM organization needs to move the change model away from CABs.

Experimentation and Learning: Why Can’t We All Get On?

In an ITSM model the organizational “tribes” are aligned to abstract processes that somehow play a part in getting value to customers, though not everyone understands how it works (never mind how well it works). In the DevOps model, the tribes are aligned with tangible products that customers consume and derive value from.

The ITSM and IT Operations organization is often described as a series of “towers,” which is a very apt description suggesting a 13th century castle to defend against angry, potentially hostile invaders. And usually everyone’s forgotten how the battle started. This silo or tower approach is incompatible with DevOps in three ways:

1. In a product-aligned, value-stream-owning team, everyone knows what the “battle” is about (customer value) and they all share a collective goal. This encourages team work.
2. In a climate of fear where invention is ignored and outages are punished, little experimentation happens. In organizations that adopt DevOps you will find cross-team lunchtime hackathons, even involving outside “strangers.”
3. In ITSM, the learning is focused on the function, silo, or tower (“How do we resolve incidents better?”) rather than how the value stream is improved. Unless the barriers are broken down across ITSM silos, shared learning will not happen.

What ITSM professionals need to do:

The failure to adopt the DevOps third way is well characterized in the book The Phoenix Project – with one symptom of the book’s subjects failing to experiment and learn being local (function) optimization versus global (value stream/system) optimization. ITSM teams must therefore establish new structures to foster learning and experimentation, such as hackathons and allowing teams autonomous development of their product without strangulation from the dictating organizational center.

So ITSM organizations are highly impacted by the “Three Ways of DevOps” and must consider how they will need to change in light of them. Hopefully this blog has given you food for thought and some initial potential issues to isolate and address.