Enterprise Integration Governance

Enterprise integration governance has acquired a bad name from being implemented badly. Heavy committee-driven governance — quarterly architecture review boards, mandatory documentation in obscure repositories, sign-offs that arrive weeks after they are needed — kills the delivery velocity that the same teams claim to want. The reaction against it has produced governance-free estates that accumulate technical debt at a faster rate than the heavy-governance estates ever could.

Most enterprise integration estates oscillate between these poles. The estates that mature into platforms are the ones that find a middle path: enough governance to keep the estate coherent, not so much that delivery stops.

This piece is the framework we use to design integration governance that produces operational value.

What governance is actually for

The four jobs integration governance must do:

Coherence over time. Without governance, every integration is built against the most expedient pattern at the time. Three years later, the estate is a collection of incompatible patterns. Governance keeps the estate coherent so that engineers moving between integrations recognise the shape.

Risk management at the boundary. New integrations crossing the boundary of the enterprise — partner integrations, public APIs, customer-facing surfaces — have security, compliance, and reputational consequences. Governance ensures that crossings are deliberate, reviewed, and signed off by the right people.

Resource allocation. Integration platforms have limited capacity — compute, partner-onboarding bandwidth, senior-engineer attention. Governance is where competing demands on that capacity are reconciled.

Capability building. Governance forums are also learning forums. The reviews that catch a pattern that does not fit are also the reviews that teach the team why it does not fit. The estates that operate well treat governance partly as a training mechanism.

The mistake is treating governance as approval theatre — paperwork submitted after decisions have been made, rubber-stamped by senior architects who were not consulted during the work. That kind of governance produces friction without value.

The three governance bodies that work

Most integration estates need three forums, not one. Conflating them produces governance that fails everyone.

The integration architecture forum. Senior architects, meets monthly or fortnightly, reviews architectural decisions for new integrations and significant changes to existing ones. Output: explicit decisions captured in writing. Membership is small — three to six senior practitioners. The forum's decisions are binding, not advisory.

The platform operating forum. Platform team plus operations, meets weekly, reviews operational state of the estate. Output: action items on operational issues, capacity decisions, deployment scheduling. Membership is the people who run the platform day to day.

The integration consumer council. Representatives from teams that build on the integration platform, meets monthly. Output: backlog signals, prioritisation input, feedback on the platform's roadmap. Membership rotates; the role is to be the voice of the consumers, not to make platform decisions.

Estates that try to do all three in a single forum produce meetings where nothing is decided well. Architecture decisions get rushed because operational items took the time. Operational items get deferred because architecture got the priority. Consumer feedback never quite lands because neither architecture nor operations is the right audience for it.

What the forums should produce

A governance forum that meets but produces no artefacts is governance theatre. The forums above should produce:

• Architecture decision records for every significant architectural decision. The pattern (often called ADR or "lightweight architecture decision record") is well-documented. Each decision captures the context, the options considered, the choice, and the consequences. Future engineers can read the history.

• Standards documents that capture the patterns the architecture forum has decided are the estate's defaults. Naming conventions, error envelope, authentication patterns, document mapping conventions, audit record schema. Few pages each. Referenced from every code review.

• Operational dashboards maintained by the platform forum. The estate's current state — capacity headroom, integration count, partner count, open exceptions, recent deployments — visible to anyone who needs it.

• Roadmap and backlog maintained transparently. What the platform team is building, what the consumer council has surfaced as priorities, what the architecture forum has approved for upcoming work.

These artefacts make governance legible. New engineers can read the ADRs and understand the estate's history. Existing engineers can reference the standards. Stakeholders can see the operational state without asking. The forums become useful surfaces rather than bottlenecks.

The decision rights matrix

Most governance friction comes from unclear decision rights. Who can approve a new integration? Who can sign off a new partner? Who decides on a platform upgrade? Who owns the resolution of an operational incident?

A decision rights matrix — sometimes called a RACI for governance — names the answers explicitly:

| Decision | Responsible | Accountable | Consulted | Informed | |---|---|---|---|---| | New integration design | Integration architect | Architecture forum | Consumer team | Platform team | | New partner onboarding | B2B lead | Platform forum | Security, Legal | Architecture forum | | Platform upgrade | Platform lead | Platform forum | Architecture forum | Consumer council | | Standards change | Architecture forum | Architecture forum | Platform forum, Consumer council | All teams | | Production incident | On-call engineer | Platform lead | Architecture forum (if material) | Stakeholders |

The matrix is short. Filling it in for an estate is two or three hours of senior-architect time. The artefact eliminates a year of recurring "whose decision is this" questions.

The friction tax — and where it should be spent

Every governance step adds friction. The question is which steps add enough value to justify the friction and which are pure overhead. We use a simple test: would this step have caught a real problem in the last twelve months?

Steps that usually pass the test:

• Pre-build architecture review for any integration crossing a trust boundary
• Security review for any new partner onboarding
• Capacity check before any deployment that meaningfully increases load
• Standards check (often automated) at code review time

Steps that usually fail the test:

• Quarterly architecture board reviews where decisions have already been made and shipped
• Documentation requirements satisfied by mechanical artefact production with no engagement
• Sign-off chains that take longer than the decision being approved deserves
• Standards documents that are aspirational rather than enforced

The estates that have made the friction tax tolerable are the ones where every governance step has been audited against the value-test. Steps that fail the test are removed, not preserved out of inertia.

The Centre of Excellence question

"Centre of Excellence" is a phrase that has come to mean different things in different organisations. Three common patterns:

The platform CoE. A central team that operates the integration platform, sets standards, and provides senior support to consumer teams. The consumer teams build their own integrations on the platform. The CoE is the steward.

The delivery CoE. A central team that delivers integrations on behalf of consumer teams. Consumer teams submit requirements; the CoE builds. The CoE is the integration team for the whole organisation.

The advisory CoE. A central team that sets standards and reviews work but does not deliver. Consumer teams have their own integration engineers. The CoE governs.

Each works in some contexts and fails in others. The platform CoE scales well when consumer teams are large enough to have integration engineering capability. The delivery CoE scales when consumer teams cannot reasonably be expected to have that capability. The advisory CoE scales when consumer teams have strong integration engineering but the estate needs central coherence.

The mistake is implementing the wrong pattern for the organisation. A delivery CoE in an organisation where consumer teams want autonomy produces conflict. An advisory CoE in an organisation where consumer teams have no integration capability produces drift.

Most large enterprises end up with a hybrid — the platform CoE pattern for most workloads, with a small delivery capability for high-priority or high-complexity programmes. Naming this honestly helps everyone.

What we recommend

For a new integration programme:

1. Establish the three forums explicitly. Charter, membership, cadence, output expectations.
2. Write the decision rights matrix. One page. Refer to it in every forum decision.
3. Adopt the ADR practice from Day 1. Every significant decision produces an artefact.
4. Audit every governance step against the value-test annually. Remove steps that do not pass.

For an estate where governance has become friction:

1. Survey the team: which governance steps do they perceive as adding value, which as overhead?
2. Audit the steps perceived as overhead against the value-test. Remove the failures.
3. Strengthen the surviving steps so they actually catch issues. Most governance failures are not "too much governance" — they are "governance that does not catch what it claims to be catching."

For an estate where governance is absent:

1. Start with the architecture forum. Senior architects, monthly, ADRs as output. This is the highest-leverage starting point.
2. Add a standards document covering naming, error handling, authentication. One page each.
3. Adopt pre-build review for new integrations. Thirty minutes per review, written record.

Integration governance done well is invisible. Engineers do not notice it because it does not create friction; the standards are clear, the decisions arrive quickly, the forums produce useful output. Integration governance done badly is the most-complained-about aspect of working on the estate. The difference is in the design of the forums, the discipline of the artefacts, and the courage to remove steps that have outlived their value.