Kosli devop change management devops lite trap

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

Bruce Johnston
Bruce Johnston
Published January 25, 2022 in technology

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

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.

devops change management continuous compliance

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


About this article

Published January 25, 2022 in technology

About the author

Bruce Johnston

Bruce Johnston


ABOUT THIS ARTICLE

Published January 25, 2022, in technology

AUTHOR
Bruce Johnston
Bruce Johnston
Live in Git Blame? Don’t spend hours searching for the change that broke your application! Query, search and discover all the changes in one place

Latest articles

Kosli announces Innovation Partnership with DNB and Firi

We are pleased to announce that Innovasjon Norge has awarded Kosli an innovation grant of 3.4 million NOK to pursue a R&D project with DNB and Firi. In this blog we’ll give you an overview of the …

The Ultimate Guide to git blame: A How To with Examples

Source control tools give users many powers and one of the big ones is traceability. With traceability tools you can know exactly who made each change and when they made it. In Git, you use the git …

Git Blame in VS Code: The 4 Best Options

Most production projects have a team collaborating on them, so even in a single file there can be multiple contributors. When things go wrong, it’s useful to understand how and why certain changes …

Sign up to our newsletter

We'll let you know about the Kosli launch, product news, features and updates
Kosli is committed to protecting and respecting your privacy. By submitting this newsletter request, I consent to Kosli sending me marketing communications via email. I may opt out at any time. For information about our privacy practices, please visit Kosli's privacy policy.
Kosli team reading the newsletter

Let’s chat!

Got a question about Kosli? An idea for a new feature? Join Kosli Slack and talk to us.

Join
Developers using Kosli