How regulated teams can avoid the DevOps Lite trap with DevOps Change Management

DevOps is being adopted across regulated industries, but old ITIL approaches to change management still create unnecessary lead times and risks. Fortunately, you don’t have to fall into the DevOps Lite trap with 20th century change management. Not when DevOps provides all the compliance automation you’ll ever need. 🙌

Technology organizations are moving away from large, monolithic, centrally managed IT systems towards a future with small, loosely coupled and rapidly updated micro-systems. And this shift is resulting in exponential rates of change.

In the past we were used to quarterly releases orchestrated by IT departments. Now, we have a continuous stream of changes to production, delivered by cross functional teams operating in a you-build-it-you-run-it ownership structure.

And all of this has been made possible by DevOps culture, practices and tooling.

Ok, but what does this change mean for regulated industries?

“We can’t do DevOps because we’re regulated and/or embedded” isn’t something we hear as often as we used to. As far as the best approach to delivering software goes, DevOps has won the argument, even in the regulated and embedded worlds. Technology orgs in these areas desire the same gains and efficiencies as everyone else, even if they have to negotiate extra gates in their value stream.

If you work in an industry like finance or healthcare, or even if you just need to follow certain industry standards such as ISO27001, the way you make software must comply with a defined process. And that means you must have a change management process in place before you can deliver changes to production.

What does this look like in a DevOps context?

Let’s start with defining our change management requirements and then consider how it aligns with our DevOps. Achieving compliance in your software process requires three essential components:

1. Process: You must have a defined (documented) way of working
2. Implementation: You must follow this process
3. Proof: You must be able to prove that you have followed this process

There are three general approaches we can take to satisfying these requirements. We have the old ITIL way, a mixed “DevOps Lite” approach, and full DevOps change management automation.

It’s quite common to see teams adopting DevOps while continuing with a traditional change management approach. In this setup, you implement continuous integration and continuous delivery, and when the time comes to release, you create the necessary proof that the processes have been followed with some ITSM.

So, instead of hearing things like “We can’t do DevOps because we’re regulated and/or embedded” we now hear things like ‘We do DevOps, but we glue a change management process on the end of our value stream with Jira tickets and Service Now.”

The DevOps Lite Trap

This is the DevOps Lite Trap, and while it’s much better than the old quarterly release, it still carries many of the same risks. It may provide the illusion of speed, but it comes with some serious drawbacks. While the team can feel that they are efficient and able to work in fast loops, they are not connected to the final delivery to the customer until long after the work is complete.

This batching of changes increases lead times, increases the risk that a change will fail, and makes it difficult to debug failures that occur. You could be in this trap if your team has CI which automatically builds and tests their software, but you:

• Cannot deploy on demand
• Depend upon another team to deliver your work
• Are not responsible for operating the application

Sounds familiar? A lot of regulated technology orgs celebrate the reduction of lead times from months to days - and rightly so. But what if you could get from months to minutes? Because that is where the winners in regulated verticals are heading.

DevOps Change Management

A better approach is to automatically bake in as much change management and risk controls as possible into every change, using DevOps Change Management.

With this approach you can

• Reduce manual work
• Improve process conformance
• Shorten lead time for changes
• Lower deployment risks

A significant part of shifting from DevOps Lite to DevOps Change management is psychological. Human beings tend to assume there’s a tradeoff to be had between speed and safety, and this is certainly true for people who develop software in a regulated context. Some find it impossible to conceive of a release process that doesn’t feature a CAB meeting.

But, as we discovered in one of our previous blogs, software compliance is a lot more like ice skating than walking a tightrope. It might be counterintuitive, but for some activities going slower increases risk.

Change management is one such activity, but with DevOps speed and compliance go hand in hand. Why not enjoy the best of both worlds?

Looking to level up from DevOps Lite? Talk to us