Start by defining what should be centralized
Centralized versus federated is often framed as a choice between one integration team and many independent teams. That framing mixes together organization, technology, and decision rights. A central group can operate the API gateway, messaging backbone, identity controls, and observability stack without building every interface. Likewise, domain teams can own delivery without being free to introduce arbitrary protocols, duplicate master data, or bypass security controls.
The useful questions are who sets standards, who supplies shared capabilities, who owns each integration flow, and who restores service when it fails. Central governance is most valuable for enterprise-wide decisions that are costly to reverse; federated delivery is most valuable where domain knowledge and iteration speed matter. Without that separation, a centralized model becomes a ticket queue, while a federated model accumulates unmanaged interfaces and data movement.
Place delivery according to coupling and risk
Company size alone should not determine the operating model. Classify integration work by data sensitivity, blast radius, frequency of change, reversibility, and the depth of business knowledge required. Payments, workforce identity, customer master data, and core ERP transactions usually justify tighter central control. Campaign notifications, departmental workflows, and events contained within one product domain are better candidates for local ownership.
A practical governance model uses several delivery tiers instead of forcing every change through the same process:
- Enterprise-critical integrations: Centrally designed or jointly delivered, with formal architecture review, data contracts, auditability, and tested recovery procedures.
- Cross-domain integrations: Built by domain teams on shared infrastructure, following standard identity, versioning, observability, and lifecycle rules.
- Domain-local integrations: Delivered through self-service tooling as long as they remain within security, cost, and platform support boundaries.
- Experimental flows: Allowed to move quickly, but given explicit data restrictions, an expiry date, and criteria for promotion into production.
Federation needs an enforceable platform contract
Federated governance is not a committee followed by informal coordination. The platform team must turn policy into a paved delivery path: approved connectors, API and event templates, CI checks, secret management, trace identifiers, retry and dead-letter patterns, and reusable deployment pipelines. When compliance depends only on documentation and reminders, teams will work around it as soon as delivery pressure increases.
The platform contract must also divide operational responsibility. Domain teams should own business logic, data quality, dependency coordination, and first-line diagnosis for their flows. The platform team should own the shared runtime, toolchain, security controls, and platform-wide incidents. Every production integration needs a named service owner, source repository, dependency list, alert destination, and recovery procedure. Otherwise, federation produces services that are easy to launch but difficult to operate.
Put governance in the delivery path
Effective governance makes routine, low-risk work faster. Automated checks can validate naming, contract compatibility, sensitive-data handling, permission scope, and deployment configuration. Human review should begin only when a change crosses a defined risk threshold. Reviewers can then focus on difficult-to-reverse decisions, such as introducing a new system of record, moving data across jurisdictions, creating synchronous coupling, or adopting another enterprise integration technology.
The central team must also control the platform's supported surface area. Supporting too many tools increases monitoring, skills, patching, and disaster-recovery burdens. Excessive restriction has the opposite failure mode: teams create shadow pipelines because the approved path cannot meet a legitimate need. A sound policy provides one preferred path, a small number of approved alternatives, and time-bounded exceptions. Governance should be evaluated through delivery wait time, duplicate interfaces, recovery quality, orphaned services, and adoption of supported patterns, not merely whether projects launched on schedule.
Evolve from a controlled boundary
An enterprise does not need to choose a permanent organization model in one redesign. Start with an inventory of APIs, batch jobs, file transfers, message queues, and SaaS automations. Identify shared high-risk capabilities, duplicated solutions, and integrations with unclear ownership. Then pilot the governance model on one cross-domain flow. The pilot should test self-service delivery, central policy, automated controls, operational ownership, and incident handling, not just whether two systems can exchange data.
More authority can move to domain teams as they demonstrate reliable engineering, observability, and on-call practices. Where contract management, monitoring, or accountability remains immature, stronger central control is appropriate until those capabilities exist. The goal is neither perfect centralization nor unrestricted federation. It is to place each decision with the team that understands its consequences and is equipped to operate what it ships.