Integration Governance and Change Control for Microsoft-Based Systems

Integration projects get treated as builds with an end date, and that framing is where the trouble starts, because the integration does not stop existing when the project closes. It keeps running, the systems it connects keep changing, and every one of those changes is a chance to break something downstream that no one remembered was connected. The failure is rarely dramatic at first; a field changes, a system is upgraded, an interface is adjusted, and a report three systems away quietly goes wrong. By the time anyone traces it back, the trust in the integrated estate is already damaged.

Integration governance is the discipline that prevents that, and it rests on three things.

A living inventory of what is integrated. You cannot govern what you cannot see, and most organizations cannot produce a current map of their integrations and what depends on what. The inventory, kept current rather than drawn once and abandoned, is the foundation, because every change-impact question starts with “what depends on this.” Without the map, every change is a gamble on undocumented dependencies.

Versioned, contract-based interfaces. When systems integrate through defined interfaces rather than directly into each other’s internals, a change can be made to a new version of an interface while the old one keeps serving existing consumers, so changes do not have to be simultaneous and risky. This is the operational payoff of an API-first architecture, and it is what makes controlled change possible at all. Without versioned contracts, every change is a synchronized big-bang across everything connected.

A change process scaled to blast radius. Before a change ships to a system that others depend on, its downstream impact is assessed and the affected owners are coordinated. The key word is scaled: a change with a large blast radius warrants real coordination, while a change that touches nothing downstream should not be dragged through heavy process. Governance that treats every change the same is the failure mode on the other side, because change control that becomes bureaucratic theater gets routed around, and routed-around governance is the same as none.

The honest tension in this topic is exactly that balance. Too little governance and changes break things unpredictably; too much and people circumvent the process to get work done, which reintroduces the unpredictability you were trying to prevent. The discipline is to make the governance proportional, heavy where the blast radius is large, light where it is not, so it is worth following rather than worth evading.

What this looks like where it is non-optional is the proof. For a global professional services firm, i3 unified siloed systems for 125,000 users through a managed integration layer, and at that scale ungoverned change is not a risk to manage, it is a guarantee of breakage. The managed layer, kept under exactly that discipline, is the only reason an integration estate that size stays coherent as its systems evolve. Integration governance is not overhead on top of the integration; past a certain scale it is the thing that keeps the integration alive.

Key Takeaways

• After systems are integrated, the risk shifts from building to changing safely; an uncoordinated change to one system silently breaks integrations downstream.
• Integration governance rests on a living inventory of what is integrated, versioned contract-based interfaces, and a change process scaled to blast radius.
• The inventory is the foundation; every change-impact question starts with “what depends on this,” and most organizations cannot answer it.
• Versioned interfaces (the operational payoff of API-first) let changes happen without risky simultaneous cutovers.
• Scale the process to blast radius; change control that becomes bureaucratic gets routed around, which is as bad as no governance.

Frequently Asked Questions

What is integration governance and change control?

The operating discipline that keeps integrated systems from breaking each other as they change: a current inventory of integrations and dependencies, versioned contract-based interfaces, and a change process that assesses downstream impact and coordinates the affected owners.

Why do integrations break after the project ends?

Because the integration keeps running while the connected systems keep changing, and without governance no one has a current picture of what depends on what. A change to one system silently breaks something downstream.

What is the most important foundation?

A living inventory of what is integrated and what depends on what. You cannot assess the impact of a change without it, and most organizations cannot produce a current one.

How does this relate to API-first integration?

API-first is the architecture; integration governance is the day-two operating discipline. Versioned, contract-based interfaces, the payoff of API-first, are what make controlled change possible without risky simultaneous cutovers.

Can change control be too heavy?

Yes. Governance that treats every change the same becomes bureaucratic and gets routed around, which reintroduces the unpredictability it was meant to prevent. It should be scaled to blast radius: heavy where impact is large, light where it is not.

If you have integrated systems but no current map of what depends on what, the useful first step is to build that inventory and a change process sized to your actual risk. Bring us your integrated estate and we will help you establish integration governance that is proportional, enough to stop uncoordinated changes from breaking things, light enough that people follow it instead of routing around it.

About the Author

Michael Branson, Founder and COO, i3solutions. Connect on LinkedIn.