Designing the Service Provider

I am often asked by fellow practitioners and clients whether DevOps is compatible with ITIL? Whether the practices are complementary or if it is a case of mixing oil with water? When I think about these questions I often think to myself that they emerge from a fundamental misunderstanding of what ITIL is or at times from a narrow reductionist understanding of ITIL – typically a limited process orientated perspective.

ITIL makes claim to a volume of ‘Best Practice’ guidance for IT Service Management which can then be used as a yardstick to guide the high level holistic design of a service provider. The key is to explore ITIL from a more holistic perspective in order to gain a better understanding and to consider how DevOps may be integrative.

When I originally published this blog post in 2015, Charles Betz challenged the appropriateness of ‘Best Practice’ in the context of a Service Provider, referring to David Snowden’s CyneFin context typology and implied that problem situations that IT Service Management attempts to intervene in do not always fit into ‘obvious’ / ‘simple” contexts appropriate to tackling with ‘Best Practice’. I agree, problem situations within Service Management can often exist in the Complicated or Complex contexts of the Cynefin model. One needs supplementary approaches to explore and be effective in dealing with those more complex contexts. Probing and sense-making approaches which I think can be effective are Systems Thinking approaches and in particular Systems Dynamics, Viable Systems Model, Strategic Options Development and Analysis (SODA), Soft Systems Methodology and Critical Systems Heuristics. They should be used iteratively to inform ongoing intervention methodologies, the efficacy of which should be evaluated via feedback and reflection. I have written about these thinking approaches and Systems practice in other blog posts.

I view ITIL as a conceptual interconnected mental model, the ‘cognitive niche’ of a mature IT Service Management practitioner. In that respect the ITIL materials can be used to think about the Service Provider in a systemic way.

Viewing it from this perspective, ITIL becomes a holistically orientated system comprising interconnected sub systems,service lifecycle phases which incidentally have nothing to do with the now unpopular ‘waterfall’ software development method, a common yet ignorant misunderstanding of the term ‘lifecycle phases’ within this context.

ITIL includes within these lifecycle phases elements of strategy making, design, transition and operations set in the abstract context of conceiving and realising services, whatever those services may be. Its process areas can be selected from its library of ‘Best Practice’ (Currently the ITIL V3 2011 Guidance) or completely redesigned to suit the needs of specific service providers. It is not prescriptive, it is just a map but once interconnected it is a way to explain why the service provider exists, what the staff inside of it are doing and it gives insights on how to manage the service provider and its services in the context of its holistic lifecycle.

It becomes a dynamic system with the inevitable system feedback that exists in all complex systems. The feedback can be analysed as the abstract starts to gradually materialise into real tangible service delivery across the lifecycle. It can can be continuously improved on, further analysed and improved on in an ongoing reinforcing loop constrained only by the limitations of its territory or changes to its external environment.

The map is high level, to quote Polish-American scientist and philosopher Alfred Korzybski, “the map is not the territory”.

The map is just the map. The map can of course become out of date from time to time but there are experienced practitioners reflecting on the collective wisdom of their experiences to keep the map current.

The territory exists within the map. This is where DevOps exists, DevOps influences territory or is territory. Typically territory in the Transition and Operations parts of the map but more broadly, certainly also in the Strategy and Design parts of the map. DevOps is about elements of culture, automation, lean, measurement and sharing – (CALMS).

These concepts of territory can be applied throughout the systemic and abstract ITIL service map.

 

Q&A

Is DevOps easier or more effective in an environment where ITIL is embedded?

DevOps can be highly effective in the transition and operations stages of an ITIL V3 lifecycle enabled service provider which is being managed using lean. Using Kanban to interconnect the lifecycle processes that deliver the service creates visibility of the service providers entire organisational system leading to a more profound understanding of the system (Deming). This is akin to Gene Kims 1st way ‘Systems Thinking’ but with ITIL V3 strategy and design connecting into development and operations.

Furthermore a feedback loop from problem management in operations can extend all the way back into all parts of the lifecycle (not only the transition phase – the typical DevOps framed area of the lifecycle). This is akin to Gene Kims 2nd way ‘Amplify Feedback Loops’ but it can take the feedback deep into the early lifecycle phases. A simple example, Operations can after doing problem management on a service that is performing poorly tell strategy that the design capacity has not been regulated to meet the strategic demand.

The service provider can then use Theory of Constraints to see why this may be happening. Perhaps capacity management is a bottleneck and needs to be appropriately exploited? Or perhaps capacity management is in fact overproducing and the consequences are being felt in service validation and testing? What does the WIP (Work In Progress) inventory say?

How can ITIL be used to accelerate the effective adoption of DevOps methodologies?

ITIL can be very effective if it is being considered in a lifecycle sense. ITIL V3 provides an impeccably sound map for left to right service delivery. In the transition phase, application development, service validation and testing, change management and release and deployment management are the areas directly relevant, ripe for automation and synthesizable with continuous delivery which forms the backbone of the DevOps value stream. Applying lean to ITIL V3 interconnects all the lifecycle phases, casting the collaboration net wide, from Strategy through to Operations, not limiting it to collaboration between Development and Operations.

Patrick Hyland