My take is federated with some teeth. I’ve run architecture both ways, and now I sit on an EA board that has to answer this question with actual budget and actual risk attached to it, not as some abstract debate you have over coffee. A pure central-authority model doesn’t survive a modern delivery cadence, full stop. A pure distributed model quietly gives up the consistency that security, compliance, and cost control all depend on, and it does it fast. The fix isn’t a philosophy. It’s a short list of non-negotiable central guardrails, plus a system of record that makes every distributed decision visible to the people who have to answer for it later.
Centralized Review Boards Train Teams to Avoid Them
The classic model puts a small central team in charge of reference architectures and requires their sign-off before anything significant ships. On paper, that looks like consistency. In practice, Forrester’s been tracking why it falls apart for a while now: EA became a checkpoint instead of a catalyst, cranking out artifacts that were stale before delivery teams ever opened them. I’ve watched this mechanism up close, more than once, and it’s almost boring how predictable it is. Give a central board a two-week review queue and you haven’t stopped bad architecture. You’ve taught every product team exactly how to route around governance instead of through it. The real cost of the ivory tower was never the speed, or at least that’s not the part that should keep you up. It’s that it teaches the whole organization that architecture governance is something to negotiate past, not a discipline worth following.
Full Autonomy Multiplies Risk Instead of Removing It
Push architects fully into domain teams, pull the central function out entirely, and you solve the speed problem by creating a worse one. Without a shared set of principles and a shared inventory of what already exists, five teams solve the same integration problem five different ways, three SSO patterns end up running in production side by side, and nobody, not even the board, can answer a simple question like “what’s our actual exposure if this vendor gets breached.” Gartner’s research on federated organizations backs this up directly: distributing decision rights without a coordinating layer produces fragmentation, not agility. I push back hard on peers who lean fully distributed in cybersecurity architecture specifically, because inconsistency here isn’t a delivery inconvenience. It’s attack surface, plain and simple. A domain team that’s never heard of the central identity standard isn’t moving fast. It’s building the next incident, and they usually don’t know it until someone else finds it for them.
The Research Doesn’t Actually Point to Either Extreme
Gartner’s 2026 guidance for heads of EA is blunt about the function needing to match the speed of business change, and the mechanism it recommends is distributed EA intelligence combined with scaled capacity, not a bigger central team and not a hollowed-out one. That’s federation in practice: a small central function holds the line on a short list of things that can’t be locally negotiated, security baselines, reference architectures for systems with real blast radius, data classification, vendor risk standards, while everything else gets decided by architects sitting inside the value streams closest to the work.
Whether that split is actually settled anywhere is worth asking, and I don’t think it is. A neighboring discipline, data governance, shows how unresolved it still is: OvalEdge’s 2025 State of Enterprise Data Governance Report found organizations split almost evenly, 36 percent centralized, 36 percent federated, 29 percent hybrid, with no approach dominant. I wouldn’t call data governance and EA the same problem (they’re not, the stakes and the artifacts differ quite a bit), but the pattern rhymes. Mature organizations aren’t converging on one answer because the right split depends on how much local variation the business genuinely needs, weighed against how much consistency risk it can tolerate. For an EA practice with cybersecurity and infrastructure in scope, my tolerance for that risk is low. Security and infrastructure standards are exactly where I want central authority to actually hold, no negotiation.
A Guardrail Nobody Enforces Isn’t a Guardrail
Federation only works if “guardrail” means something enforceable, not a line in a wiki nobody’s opened since it was written. When a domain team wants an exception, a new integration pattern, a vendor outside the approved list, the question I ask isn’t whether they have a good reason. They usually do, to be fair. It’s whether the exception introduces risk the business hasn’t consciously accepted, and whether anyone would even see it if it did. That second question is where most federated models quietly fail: central sets the principles, distributed teams make the calls, and six months later nobody, including the board, can reconstruct why a given system looks the way it does. That’s not governance. That’s tribal knowledge wearing a governance label, and I’ve sat in enough post-incident reviews to know how that story ends.
Traceability Is the Difference Between Federated and Just Distributed
This is the part I push hardest on, and it’s why I run architecture decisions through an EAM tool rather than a folder of design docs nobody keeps current. I use LeanIX, and the platform’s own roadmap reflects the same problem the industry is converging on: SAP LeanIX has been rolling out unique, referenceable identifiers for architecture decisions, specifically so a call made by an embedded architect in one domain can be cited, audited, and reused outside that team’s own context. That’s the mechanism that makes federation safe instead of just fast. A domain architect making a local decision is fine, more than fine, as long as the decision, its rationale, and the standard it was measured against all land in the same system the central function and the board can actually see. Skip that step and “federated” is just “distributed” with better branding, carrying all the fragmentation risk of the fully autonomous model without ever admitting it.
Which brings it back to the checkpoint-versus-catalyst tension Forrester named. A board that can’t see distributed decisions is running an ivory tower with extra steps, no matter what it calls itself, and a board that can see them is running something that survives a security audit and a delivery deadline in the same quarter. I don’t have every corner of this solved either, honestly, but the shape of it is clear to me now in a way it wasn’t a few years back. Build the short, defensible list of what central architecture owns outright. Push everything else to the value streams with real authority attached, not veto power held hostage to a review queue. Make the whole thing show up in one system of record so the answer to “why does this exist” is a lookup, not a scavenger hunt. That’s not a compromise between the two extremes. It’s the only version of either one that actually holds.
Photo by Piotr Chrobot on Unsplash