If you work in a large organization with a traditional, sequential release process such as ITIL, the idea of a continuous flow of change may sound unfamiliar. That's been the case at several organizations with which I've consulted recently, so I use the term "continual service transition" as an easier way to explain continuous delivery (CD) to people familiar with ITIL—and you can too.
If your organization has adopted ITIL, you’re probably already familiar with the concept of service transition, the process where a service moves from development into live operation.
In a traditional IT environment, various service readiness checks help teams assess and improve software before it goes live. In a continuous delivery world, however, you don't have discrete phases (such as service transition), but you can and should adopt best practices from ITIL around service readiness.
When I discussed new deployment models with an ITIL-trained release manager recently, he responded, "Ah, so we'll always be doing service transition." Exactly right. In a DevOps world, service transition as a separate phase after your software has been built makes little sense.
You need continual service transition, where you're always assessing service readiness and the operability of the changes flowing toward production. Here's how it works.
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.). But in a DevOps world, where there is value in making changes every day, a large service transition phase is less useful.
Many organizations 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 happen only after the software has been mostly built. (ITIL 4 does aim to address the problems of a phased approach.) Source: Axelos.
What's needed in these waterfall-like situations is a way to continually assess service readiness and operability in a way that can meet ITIL standards but also allow for a rapid flow of small updates to software systems.
Axelos, which maintains the ITIL standards, launched ITIL 4 in early 2019 as a way to address the problems with a phased approach. This update focuses on practices rather than processes, which is welcome because practices are more easily adapted to new technologies and new technology dynamics than are processes. However, it will take many years for organizations with existing ITIL expertise to adopt ITIL 4.
How can you help organizations using ITIL move away from a waterfall-like large-phase approach and toward a more continuous flow of change? This is where the concept of continual service transition comes in.
Continual service transition for ITIL practitioners
Since 2014 I have helped many organizations around the world adopt continuous delivery practices. Many 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-oriented 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, I had to find ways to help people with ITIL-specific roles such as 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, and 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.
The concept of continual service transition seems to help people understand continuous delivery from an ITIL perspective. Service transition is a specific phase in ITIL 3 that occurs after software has been built and needs to be moved into live service.
In a DevOps world, however, you're releasing small chunks of software whenever they're ready. This continual flow of change helps you detect problems with the design and implementation, giving you the chance to fix problems quickly.
In this context, you need to apply service-transition principles all the time, assessing the operability of the software and validating service readiness. With DevOps, you 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 to production (see Figure 2).
Figure 2: Continual service transition, with (1) feedback from software changes running in production (2) informing and influencing the next software change being written. Source: Conflux.
This continual service transition helps organizations make rapid course corrections based on small, low-risk changes. Co-opting the ITIL language of "service transition" allows people from an ITIL background to more readily grasp the nature of the new DevOps ways of working.
In addition, there are a few practical techniques that work well alongside continual service transition that can help your organization 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 plaintext file, such as readme.txt, to the production environment. The file will not be visible publicly, but the deployment steps will be tracked, logged, and visible to release managers and change managers.
Why start with a 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 plaintext 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 into 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, while bringing other people on the journey.
Design for operator experience
A key part of DevOps is making software easier to operate. Software with poor operability leads to extended service recovery periods, more damaging incidents, and higher burnout in IT operations teams. This is why SRE teams sometimes refuse to partner with development 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 service and Ops teams when they're 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.
To achieve this, you may also need to review the wording of commercial or internal contracts to look for ways to increase responsibility for operational effectiveness in groups that are building the software.
It may be useful to insist that the group or supplier building the software define service readiness criteria, rather than the people running the software in production. Force commercial or contractual responsibility for the operability of the software being written.
Shift your mindset
The focus of service transition in ITIL on operability and service readiness is very valuable. Service transition as a separate phase only after 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 among the groups involved.
The mindset shift is quite large, so use some techniques to help: Deploy a plaintext 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 your IT Ops team. And revisit and evolve commercial contracts to help ensure that operability and service readiness are built into the software all the time.
To improve your approaches to service readiness and operability, see The Site Reliability Workbook, from Google, which includes practical tips for SRE implementation based on work with Google's customers, and also the Team Guide to Software Operability, from Conflux Books, which contains practical, team-focused techniques for enhancing operability in modern software.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
