What is the difference between a centralized, a federated, and a decentralized architecture operating model, and what problem is each trying to solve?

## The question the model answers An architecture operating model answers one organizational-design question: **who has the authority to make architecture decisions, and at what scope?** Three archetypes sit along a spectrum of centralization. ## The three archetypes **Centralized.** In a centralized model, a single enterprise architecture (EA) group — often reporting into a CTO or CIO — owns architecture decisions for the whole organization: - technology selection - integration patterns - non-functional standards - often the review gate a project must pass before build starts Delivery teams submit proposals upward and the central group approves, modifies, or rejects them. The mechanism is a **hub-and-spoke decision flow**: requests flow to the hub, decisions flow back out. **Decentralized.** In a decentralized model there is no hub. Each delivery team (or product line) has full authority over its own architecture; there may be no enterprise architects at all, or they exist only as advisors with no approval power. Decisions are made locally, close to the people who will live with the consequences. **Federated.** A federated model splits the decision space by scope rather than by team. A small central function — an Architecture Guild, Council, or EA team — owns decisions that are inherently cross-cutting: - the technology radar - shared platform choices - integration and data-exchange standards - security and compliance baselines - reference architectures Everything else — how a given service is internally structured, which libraries it uses within the approved radar, its own deployment topology — is delegated to architects embedded in or aligned with each delivery team. Federated models also define an **escalation path**: local architects raise a decision to the central body when it crosses domain boundaries, introduces new technology, or carries org-level risk. ## Why the models exist at all Why do these models exist rather than just letting engineers decide? Architecture decisions have **externalities** — a database choice, an API contract, or a data-ownership boundary made by one team constrains every team that has to integrate with, operate, or later migrate off it. - Left fully decentralized, an organization accumulates technology sprawl and duplicated platform investment whose integration cost only becomes visible later. - Left fully centralized, the organization instead accumulates a decision queue: every team waits on the same small group, throughput caps out, and central architects — structurally distant from the code — make decisions with incomplete local context. ## The trade-off The trade-off is consistency-and-reuse versus speed-and-context. Federation tries to buy most of both; here is what each model buys, and at what cost: | Model | Buys | Cost | |---|---|---| | **Centralization** | a smaller supported-technology footprint, easier compliance auditing, and cheaper cross-team integration | decision latency | | **Decentralization** | fast, well-informed local decisions and autonomy | integration debt that shows up later as a costly consolidation project | | **Federation** | most of both | continuously renegotiating where the 'cross-cutting, goes to the center' line sits | ## Failure modes Failure modes are visible in how organizations experience each model. 1. **An outgrown centralized model** produces the classic 'review is the bottleneck' complaint — projects queue for weeks, and teams route around the process by shipping first and asking forgiveness, which quietly makes the model decentralized in practice while it's still centralized on paper. 2. **An unconverged decentralized model** shows up as a platform team drowning in requests to integrate N different auth schemes, deployment pipelines, and logging formats — the org eventually funds a 'platform consolidation' initiative to claw back standards it never set. 3. **A federated model fails quietly** when the center grabs too much scope (recreating a centralized bottleneck) or lets the escalation path atrophy (local architects stop escalating because nothing happens when they do, and it decays into decentralized). ## Where it shows up A concrete example: Spotify's widely cited squad/tribe/chapter/guild structure is a federated model applied to engineering broadly — chapters and guilds carry cross-team standards while squads keep local autonomy. Large regulated enterprises (banks, insurers) instead often lean more centralized for compliance-and-auditability reasons, accepting slower delivery for a smaller, more defensible surface to certify.