May 26, 2026
Community Voice
.png)
High-performing teams deploy multiple times per day. Traditional configuration management frameworks were designed for change cycles measured in weeks or months. When software velocity outpaces your governance model, the instinct is to conclude the framework is broken.
That instinct is usually wrong. The framework is not the problem. The granularity of its application is.
A 2026 analysis of DevOps trends found that the industry is shifting from raw deployment frequency toward outcome, risk, and resilience as the primary metrics. The question is moving from “How fast can we ship?” to “How well can our systems absorb constant change?” That shift sounds familiar to anyone who has worked in configuration management. It is the difference between speed and control, and the answer has never been to choose one over the other.
What most organizations get wrong is applying the same governance threshold to every change. A cosmetic UI update and a safety-critical algorithm change do not require the same review depth. But without a framework that explicitly defines where the boundary sits, organizations default to one of two failure modes: everything gets full review (creating bottlenecks that teams circumvent), or nothing gets meaningful review (creating risk that surfaces in production).
CM2 offers something distinct here. Not a fourth industry-specific answer, but a framework-neutral vocabulary for asking the right question. Not “what does your standard require?” but “what is your governance structure actually trying to accomplish, and where should the threshold between fast and slow sit?”
This maps directly to tiered change governance. Low-risk changes with adequate test coverage can flow through lightweight approval paths. High-risk changes that affect safety, interoperability, or regulatory compliance require a full CRB review and CIB implementation planning. The ServiceNow DevOps Change Velocity model implements exactly this pattern: auto-approving low-risk changes while preserving manual review for high-risk ones.
The key insight is that software-intensive products do not need less configuration management. They need more granular configuration management. The governance structure must match the velocity profile of each change category, rather than applying a single speed to all changes.
Is your CM framework slowing down software delivery? Or is it your application of the framework that cannot distinguish between changes that require governance and those that require velocity?
Use code Martijn10 for 10% off training—and don’t forget to tell them Martijn sent you 😉.
Copyrights by the Institute for Process Excellence
This article was originally published on ipxhq.com & mdux.net.
Known by his blog moniker MDUX—Martijn is a leading voice in enterprise configuration management and product lifecycle strategy. With over two decades of experience, he blends technical depth with practical insight, championing CM2 principles to drive operational excellence across industries. Through his blog MDUX:The Future of CM, his newsletter, and contributions to platforms like IpX, Martijn has cultivated a vibrant community of professionals by demystifying complex topics like baselines, scalability, and traceability. His writing is known for its clarity, relevance, and ability to spark meaningful dialogue around the evolving role of configuration management in Industry 4.0.
