Another day, another LinkedIn hot take on enterprise architecture. They fall into various camps: those confusing EA with a Marvel villain, others who think that the 10-year-old religious war between “business” and “enterprise” architects has any actual meaning (pro tip: it’s about as relevant as whether Han shot first), or folks who think that EA is primarily a conceptual exercise, so we need to continue building semantic castles in the air in the futile hope that the perfect metamodel will finally pave the way to EA utopia.
I try not to get too cranky about it, but when you’ve spent a few years managing a global EA awards program, reviewing dozens of case studies, talking to many clients, and running a global survey with a large EA component, the endless, poorly grounded opinions in my feed grow wearying. “In the one career experience I’ve had with it, EA was an utter failure! Look at this diagram that I don’t understand! So worthless!” Perhaps I’m making my transition to curmudgeonly analyst, but I’m starting to call this stuff out.
So let me base this discussion on something real: our new Forrester report, Scale And Federate: The EA Journey To Business Value. It is grounded in actual patterns we’ve seen across years of direct interviews, statistical research, award submissions, and advisory engagements.
This report lays out how architecture teams evolve — not should evolve and not theoretically evolve but actually do evolve — when they’re building credible, durable enterprise architecture programs. Spoiler: There’s no silver bullet, value can be found at all phases (even “mere” technical architecture), and federation isn’t some magical end state. It’s a consequence of growth, scale, and the ongoing fight against organizational entropy. As the report Architecture Is Expanding Its Reach (based on three years of trending data from our Modern Technology Operations Survey) points out, EA’s prevalence is increasing, whether measured as organizations with a formal “architecture” organization or having “architect” job classes.
EA’s Identity Crisis, Still In Full Swing
We do need to address the elephant in the ivory tower: architecture’s lingering credibility problem. The EA skeptics have their points:
Too many EA groups still struggle to explain their value beyond “We’re smart, draw pictures, and go to meetings.”
Others get stuck in endless debates over business vs. enterprise vs. solution vs. technical vs. data architecture — as if these distinctions matter to anyone outside the EA Slack channel.
Still others cling to top-down authority, issuing standards from on high while being ignored by delivery teams who are too busy shipping to read your 40-slide PowerPoint/UML mashup on design patterns.
But as much as my friends in the agile/DevOps community love to focus on these antipatterns, they are not the whole story. The best EA teams — the award winners I see every year — aren’t falling into these traps. They’re busy running architecture like a real program, with operating models, service catalogs, architecture decision records, feedback loops, and (*gasp*) traceability to actual business outcomes.
Yes, Architecture Has Customers
You wouldn’t know it from some EA content out there, but architecture does have customers — and they’re demanding actual value. The successful EA orgs know their job isn’t just to document complexity; it’s to reduce it. And they do it by drawing clear lines of sight from architecture activities to measurable business benefits: reduced risk, improved cost efficiency, improved CX, faster time to market, and better overall business and mission outcomes.
We’ve seen EA teams justify their existence by slashing technical debt, improving reuse, optimizing cloud spend, and even accelerating M&A integration. And yes, they had the dashboards and specific cases to prove it.
The Progression: From Lone Wolf To Federated Force
Here’s the real kicker: The journey to business value is a journey. It’s not an overnight transformation, and it’s not a maturity model in the condescending sense. It’s a progression we’ve seen play out repeatedly:
Solutions architecture (the lone wolf stage): Starts with your classic “smart dev” who becomes the de facto architect. Writes patterns, documents things, tries to set a good example — too often, without nearly enough backing given the value that they are providing.
Technology governance (the centralized phase): Someone finally gets tired of the chaos. A senior leader (CIO, CTO) mandates a formal architecture unit. Processes and standards emerge. A spreadsheet of approved technologies appears. There are meetings. There is friction. It’s progress.
Application and data architecture (the scaling stage): Suddenly, the focus shifts from infra to applications and data. This is where the CMDB rears its head again (don’t shoot the messenger). Data architecture joins the party, sometimes reluctantly. The EA group starts acquiring real tooling — yes, the EA repository arrives. And early federation starts. There’s no way security architects aren’t going to report to the CISO.
Federation (the grown-up phase): The center cannot hold everything. Lines of business want their own architects. Everyone wants autonomy, but no one wants chaos. So you federate — on purpose — with communities, cross-functional processes, service offerings, shared artifacts, and other shared alignment mechanisms. The central architects take ownership of the strategic shared domains: payments, supply chain, customer experience. And architecture gains its seat at the strategic table.
Does every org hit all the stages in identical order? Of course not. But the point is: If you’re not thinking about architecture as a program and a journey — not just a role or a few boxes on a slide — you’re not playing the long game.
Federation Isn’t A Buzzword — It’s Inevitable
Too many EA teams still treat “federation” like it’s some best-practice ideal they’ll get around to once they finish modeling every business process in ArchiMate. In reality, if your company grows beyond a few hundred people, federation happens to you. The question isn’t whether you’ll federate; it’s whether you’ll do it well.
The best federated models we’ve seen have steering councils, shared services, reusable artifacts, and — crucially — strong internal brands. They know what services they offer, they market those services, and they constantly evolve. This isn’t some abstract “target-state architecture”; it’s a real operating model.
Don’t Be The Architect Left Behind
I’ll end with this: The EA world is shifting — fast. GenAI, platform engineering, FinOps, the redefinition of EA repos and CMDBs as living graphs — this is not background noise. These new elements are structural changes to how we manage IT.
If your EA program is still obsessing over which modeling notation to use or whether the business architects should report to you, you are missing the plot.
Get serious. Build an operating model. Show value. Scale and federate. Or risk becoming another architectural artifact no one uses.
For in-depth insights into enterprise architecture, Forrester clients can access our exclusive reports and set up guidance sessions to continue to explore current trends and solutions. You can also email us at [email protected].
