Adapt ITIL to DevOps with continual service transition
By Matthew Skelton, founder of Conflux
Key takeaways
The concept of Continual Service Transition can be helpful to move from an older ITIL model of change management to a smoother flow of smaller changes
A single phase of Service Transition does not fit well with Continuous Delivery
Start by deploying a simple readme.txt file and show the monitoring and dashboards
Design for the Operator Experience - whoever is running the software in Production
Change commercial contracts to increase responsibility for operability
In large organizations with a traditional, sequential release process (such as ITIL), the ideal of a continuous flow of change can be quite unfamiliar. In several organizations recently I have found it useful to talk about "continual service transition" as a way to explain Continuous Delivery to people familiar with ITIL.
If your organization has adopted ITIL, you’re probably already familiar with the concept of Service Transition, the process whereby a service moves from development into live operation. In a traditional IT environment, various service readiness checks help teams to assess and improve the software before it goes live. In a Continuous Delivery world, however, you don't have discrete phases (like Service Transition) but you can and should adopt some of the good practices from ITIL around service readiness.
I remember recently discussing new deployment models with an ITIL-trained Release Manager; at one point he said “ah, so we’ll always be doing Service Transition” and I said “yes, exactly!”. Service Transition as a separate phase after the software has been built makes little sense in a DevOps world. Instead, we need “continual service transition”, always assessing service readiness and operability of the changes flowing towards Production.
The problem with Service Transition as a phase
The concept and details of Service Transition are excellent: assess service readiness in many different dimensions (supportability, performance, help desk, end-to-end physical plus digital interactions, etc.). However, in a DevOps world where there is value in making changes every day, a large Service Transition phase is less useful.
Many organisations assess service readiness and operability properly only during Service Transition, meaning that there is little time or possibility to fix operational problems.
Figure 1: the traditional phases in ITIL 3, with Service Transition often happening only after the software has been largely built.
What’s needed in such situations is a way to continually assess service readiness and operability in a way that can meet ITIL approaches but enable a rapid flow of small updates to the software systems.
Axelos, the maintainers of the ITIL standards, recognised the problems with the phased approach and in early 2019 launched an update to ITIL, known as ITIL 4. ITIL 4 has a focus on practices rather than processes, which is really welcome because practices can be more easily adapted to new technologies and new technology dynamics than processes. However, it will take many years for ITIL 4 to be adopted by organisations with existing ITIL expertise.
How can we help organisations using ITIL to move away from a waterfall-like large-phase approach towards a more continuous flow of change? This is where the concept of “Continual Service Transition” comes in.
The concept of ‘Continual Service Transition’
Since 2014 I have helped many organizations around the world to adopt Continuous Delivery practices. Quite a few of these organizations used some aspects of ITIL to manage the release and change processes and we had to adapt these to suit a more “DevOps” way of working.
For example, I recently worked as Engineering Lead for a UK Government department covering many teams, locations, and suppliers. As part of championing Continuous Delivery practices there, we had to find ways to help people with specific ITIL roles like Release Manager and Change Manager to see things in a different way.
To many people familiar with ITIL, software delivery is all about defining the scope, building something with all the functionality together, then getting that software into Production. The idea of a continuous flow of small changes can be baffling to people who think in terms of releasing “complete” software. Jez Humble - co-author of the 2010 book Continuous Delivery - wrote a great article that covers in detail how to extend and adapt the concept of the ITIL Standard Change to be more suited to Continuous Delivery.
One concept I have found that seems to help people understand Continuous Delivery from an ITIL perspective is “Continual Service Transition”. Let me explain. As we’ve seen above, Service Transition is a specific phase in ITIL 3 that occurs after the software has been built and needs to be moved into live service. However, in a DevOps world, we’re releasing small chunks of software whenever these are ready and are suitable to put in front of users. This continual flow of change helps us to detect problems with the design and implementation, giving us a chance to fix the problems quickly.
In this context, we need to apply the Service Transition principles all the time, assessing the operability of the software and validing service readiness. With DevOps, we have a very tight feedback loop between Service Operation (software running in production) and Service Design (software development). All the key activities that used to happen during Service Transition in an ITIL 3 model now need to happen continually - for every small chunk of new software heading towards production (Figure 2).
Figure 2: Continual Service Transition with feedback from software changes running in production (1) informing and influencing the next software change being written (2).
This “continual service transition” enables organisations to make rapid course corrections based on small, low-risk changes. By co-opting the ITIL language of “Service Transition”, I found that people from an ITIL background could more readily grasp the nature of the new DevOps ways of working.
In the next sections, I’ll describe some practical techniques that work well alongside Continual Service Transition to help organisations adopt Continuous Delivery.
Start by deploying a simple readme file
A useful technique for demonstrating the Continuous Delivery approach is to use a walking skeleton - essentially a bare bones deployment pipeline that does very little initially. Begin by deploying a plain text file - such as readme.txt - to the Production environment. The file will not be visible publicly but the deployment steps will be tracked and logged and visible to release managers and change managers.
Why start with readme.txt? It’s about minimal risk. The least risky software deployment is a simple text file with some searchable content. This means that - from a risk perspective - the deployment is safe and of minimal complexity. Almost anyone can reason about the possible impact of a plain text file in Production.
As part of the deployment, show people the metrics, logs, and dashboards that track the deployment activities, and demonstrate that they have full visibility of changes. When you have won their trust, deploy a simple “hello, world!” application (slightly more risk, but still understandable). Over time, deploy increasingly larger chunks of software, whilst bringing other people on the journey.
Design for the Operator Experience
A key part of DevOps approaches is to make software easier to operate. Software with poor operability leads to extended service recovery periods, more damaging incidents, and higher burn-out in Ops teams. This is why SRE teams can refuse to partner with software teams that have not invested properly in operability.
A key part of Continual Service Transition (and DevOps in general) is therefore to define and address the experience of live service and Ops teams when working with software: the Operator Experience. What do these teams need to see on dashboards? What query tools do they need to find failed transactions or stuck processing jobs?
Use standard User Experience (UX) techniques to design a good UX for people running the software in Production by treating Live Service/Ops/SRE people as a user of the software.
Update supplier contracts to increase focus on operability
You may need to review the wording of commercial or internal contracts to look for ways to increase responsibility for operational effectiveness in the groups building the software. It can be useful to insist that service readiness criteria are defined by the group or supplier building the software rather than the people running the software in production. Force commercial or contractual responsibility for the operability of the software being written.
Summary
The focus of Service Transition in ITIL on operability and service readiness is really valuable. However, Service Transition as a separate phase only after the software has been developed does not fit well with a modern DevOps-style incremental delivery of small changes. Instead, the attention to service readiness and operability should happen all the time - “Continual Service Transition” - with close collaboration between different groups involved.
The mindset shift is quite large, so use some techniques to help: deploying a plain text readme.txt file to Production and demonstrate the metrics, logs, and dashboards that track changes. Explicitly design for the Operator Experience through the use of UX practices applied to Ops team. And revisit and evolve commercial contracts to help ensure that operability and service readiness are built into the software all the time.
