6 min read
Key takeaways
- ITIL change management framework doesn’t work for frequent software releases
- That’s a problem because regulated teams want continuous delivery
- By automating change management they can release software as standard changes
Introduction
There are quite a lot of articles out there on this topic, usually trying to score for SEO, that promise to show you how to do this without actually ever getting there. But it can be done and in this piece I will explain how. Let’s recap the nature of the problem before we dive in.
Continuous Delivery (CD) is about making software releases multiple times per day. But in regulated industries we have this thing called change management where we have to approve our changes before they can be released. It’s a process usually done through the ITIL framework of change advisory board meetings (CABs) and ticketing systems 🙄
So, our problem is quite straightforward. Releasing software every few hours or even minutes isn’t possible if you need to call a meeting first to get managerial approval. To achieve genuine Continuous Delivery in a regulated industry we need to find a way to release software that doesn’t involve tickets and meetings. The question is - how?
Moving beyond the traditional ITIL change process
It’s important that our solution works within the ITIL framework because ITIL isn’t going anywhere any time soon. If you’re a non-regulated startup, born in the cloud, you’re free to choose your own adventure. But many of us work in regulated or legacy organizations where ITIL is the norm and we have to live within it whether we like it or not.
We also want to do DevOps though, so how do we fit our DevOps into this rigid system? More specifically, how do we get to Continuous Delivery where we can deploy software whenever we like? It seems to be a paradox where the unstoppable force of Continuous Delivery meets the immovable object of change management.
On one side we have ITIL - slow, risk averse, careful and really not compatible with daily or hourly deployments. And on the other we have DevOps - fast, agile, automated and with absolutely no time for meetings and ITIL ticketing systems to approve software releases.
But if regulated teams in critical industries are going to release software to customers on a daily/hourly basis we have to solve this puzzle. We need bureaucracy-free Continuous Delivery that’s safe, secure, and compliant. Fortunately, and perhaps counterintuitively, the ITIL framework offers us a way to do exactly that - IF we interpret it in the right way.
At the risk of annoying absolutely everyone - let’s dig in ⛏️
Why is the ITIL change framework a barrier to Continuous Delivery?
The ITIL framework defined change management long before DevOps, Continuous Delivery, or even Agile was a thing. As an infrastructure library, ITIL was mainly concerned with setting down best practices for managing the lifecycle of IT assets from initial strategy and planning, through to adoption, maintenance, and eventual replacement. You can already see how far removed this is from delivering software every day.
We have previously discussed the different types of changes that are defined by the ITIL framework. But basically, there are emergency changes, normal changes (sometimes further categorized as major changes and minor changes) and standard changes.
When ITIL was initially defined, a software release was a rare event that took place maybe once a year. It was also seen as risky. It made sense that, under the ITIL framework, a software release was defined as a normal change. But what does this mean in practice?
What is a normal change in the ITIL framework?
A normal change has to go through a change management process before it can be made. For software releases, change management acts as a gatekeeper to make sure only changes that have been approved can be deployed to production. It’s a way of mitigating risk by making sure changes have been adequately tested and are therefore safe for customers to use.
A normal change requires a change request, assessment and planning, and managerial approval before implementation can be made. It’s a process that’s usually carried out using ITSM software like Service Now (maybe Jira for younger organizations) and CAB meetings. These days, teams batch up their software changes and every few months they’ll have a meeting to go through all of the necessary paperwork that tells them - in theory at least - whether all of their risk mitigations have been met.
And this process kind of works* when software releases are still being made every few months. But as you can see for yourself, they’re wholly inadequate for multiple releases every day.
*I say “kind of” but research is increasingly unkind so far as external approvals are concerned. In Accelerate, Dr. Forsgren et al found that external approvals were worse than no process at all. So, if they’re slowing everything down without actually mitigating risk, what are they for? 🤔
On top of this, batching changes that will be approved in a few weeks or months, creates the illusion that changes are deployed fast - aka the DevOps Lite trap ⚠️
Normal changes v standard changes
Earlier we mentioned standard changes as one of the types of changes defined under the ITIL framework. Standard changes are interesting because they are pre-approved, meaning they do not require the change management process described above.
So how do we make our changes standard? There are three important criteria to meet. The changes must be:
- low risk
- relatively common
- following a procedure
Good news - most changes delivered as part of DevOps workflow meet these criteria! If our pipelines deliver a result (and proof) that is low risk, common, through an automated procedure, then we can meet these requirements.
Standard changes can be made freely as part of standard operating procedure, without any ceremony or bureaucracy.
If we can define and automate a repeatable process for managing and mitigating risk, we can release our software without tickets and meetings. It’s a problem that has a DevOps solution and it opens the change management gate to production for regulated teams.
And you can check if the process has been followed!
DevOps enables you to automate the risk controls and release approvals in your pipeline and Kosli can show you whether or not a release candidate has met all of your criteria for mitigating risk before deployment.
If some evidence is missing, hold the release back until the outstanding test/scan/pull request has been done. But if all the evidence is present you can release the change to the live environment without delay.
There is no need for any manual documentation or further discussions to ensure compliance in your process. They have zero value to add 🙅 Send a report to Service Now showing all the latest changes if your framework requires it, but there’s no need to delay the release before you do so.
With systems in place you can pre-approve individual software releases as standard changes. With Kosli, you can automate your change management requirements and can deploy compliant software continuously without batching changes into a large, risky release that requires a much more intrusive ITIL process 🙌
