merkely devop change management devops lite trap
merkely devop change management devops lite trap

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.

Approach Process Implementation Proof
Traditional Wiki Documentation Manual build, qualification, and deployment Meeting minutes and Change Documentation
DevOps Lite Wiki Documentation DevOps Pipelines Meeting minutes and Change Documentation
DevOps Live Documentation DevOps Pipelines DevOps Journal

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.

Change Management as a gate. Build, qualify, compliance, deploy MerkelyThis 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.

DevOps Change Management process graph MerkelyWith 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

Top Articles

How to do Continuous Delivery in your ITIL framework?

Continuous Compliance: A DevOps culture

We’re going to DevOpsDays Denmark 🎉

Published January 25, 2022 in
Bruce Johnston
Bruce Johnston

Subscribe to The Merkely Meteor Newsletter for all the latest on regulated DevOps, features, news and events

Merkely is committed to protecting and respecting your privacy. You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please visit our Privacy Policy.
Subscribe to the Merkely Meteor

More posts in technology

How to do Continuous Delivery in your ITIL framework?

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.

Continuous Compliance: A DevOps culture

Imagine your developers are the world’s fastest relay team 🏃 When it comes to build, test, and qualify they get round the running track faster than anyone else. Unfortunately for them the finishing line is hidden somewhere outside the stadium. Welcome to regulated DevOps How did they get to be running this impossible race? Well, better tools and working practices have meant a dramatic shift from annual software releases to a world where teams have the ability to deploy multiple times every day.

Why ITIL Change Management doesn’t work for DevOps teams

Are you trying to do DevOps under regulation? If so, you’ll know the pain of change management. In this article we’ll look at how delivering software with DevOps is incompatible with old school ways of managing change with ITIL and how you can automate your change management process with a DevOps approach. As regulated industries speed up their DevOps processes they find that managing software releases with ITIL tickets and change meetings just doesn’t scale.

Subscribe to the Merkely Meteor newsletter for all the latest on regulated DevOps, how to’s, features, news and events

Merkely is committed to protecting and respecting your privacy. You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please visit our Privacy Policy.
Subscribe to the Merkely Meteor