Enterprise Architecture Isn’t Dead — It Was Just Misunderstood (and Occasionally Misdirected)

TL;DR:

Enterprise Architecture isn’t dead — but it must get out of the ivory tower. Real architects need to jump into the deep end, understand the domain first, or have the humility to involve those who do. Only then should frameworks and principles be applied — as tools to connect systems, people, and outcomes that genuinely matter to business stakeholders.

Not long ago, I found myself at an IT-Business Alignment conference, surrounded by architects, engineers, business leaders, and strategy folks—all debating a familiar topic:

Is Enterprise Architecture still relevant?

As you’d expect, opinions were polarised. Some declared EA dead. Others claimed no organisation could survive without it. Both camps had valid arguments. But I found myself asking a different question:

Was enterprise architecture ever properly understood to begin with?

Let me explain—because I’ve seen this from both sides of the fence.

From the Assembly Line to the Technology Architecture

I began my career not in IT, but on the shop floor—as a line engineer in a car manufacturing plant.

There, the job was clear: build things that work, deliver quality, and never lose sight of the final output. Processes mattered. Timing mattered. And above all, accountability mattered.

That grounding in real-world engineering has stuck with me ever since—and it’s why I get twitchy when I see enterprise architecture drift into theoretical territory.

“Traditional” EA misnomer

People often talk about traditional enterprise architecture. But to be honest, that phrase has always struck me as flawed. There’s nothing “traditional” about EA. From its early days—Zachman, TOGAF, frameworks galore—it was meant to simplify complexity, not generate more of it.

Yet over time, very clever people unintentionally turned EA into a theoretical ivory tower discipline. What began as a way to unify business and IT devolved into an industry of frameworks, templates, checklists, meta-models, and review boards.

EA function lost the plot.

Enterprise architects became known more for their ability to create compelling PowerPoint decks than for delivering business outcomes. They talked the talk. They created gorgeous “as-is” and “to-be” states. And then threw the deck over the wall to delivery teams, hoping for the best.

But there’s more to it.

The abstraction-heavy nature of EA gave rise to a generation of architects who were light on process analysis, system design, or delivery experience, but heavy on presentation skills. EA became the highest-paid intellectual club in IT—drawing in people who had never built a system but could write a white paper on why someone else should.

This shift aligned beautifully with the rise of ERP waves, package applications, ESB, SOA, and new tech hype cycles—all championed by product vendors, advisory firms, and consultancies.

The result? Gorgeous frameworks. Thought leadership slides. Zero ownership of outcomes.

The Plant Manager Test

Let’s go back to the plant floor for a moment.

As a line engineer, I worked under a plant manager who didn’t need to know the exact pressure required to glue a windscreen or the precise torque setting on the impact wrench used to tighten bolts. That was the line supervisor’s job.

But when a car rolled off the line and failed the shower test—leaked glass, misaligned panels, failed sensors—the plant manager was the one who had to answer.

They understood the flow, the tools, the interdependencies. They didn’t own every detail—but they owned the outcome.

Compare that with the traditional EA model. A deck is created. It covers the vision, the principles, the “north star.” It’s delivered with confidence.

But when the implementation goes sideways, no one circles back to the architect. Why? Because they were “strategic.” Their job was to define, not deliver.

And that’s the fundamental flaw.

EA Role - My perspective

In my experience, effective enterprise architecture isn't about abstractions or alignment in theory. It's about meaningful engagement with delivery teams, business partners, and platform owners.

• Architects understand where systems, data, and processes intersect—even if they’re not hands-on with every line of code.

• They build bridges across domains: data, integration, infrastructure, applications, vendors.

• They guide initiatives through clarity and coherence—not control—ensuring people and platforms move in the same direction.

• They speak the language of the business—outcomes, risks, value chains—while also being respected by engineering for their grounding in how things actually work.

It’s also critical to maintain architectural oversight across engineering teams—not to restrict autonomy, but to ensure cohesion. In the absence of this, even highly capable Agile teams can inadvertently create siloed or conflicting solutions. Oversight done well is not bottlenecking—it's orchestration.

They don’t need to know the torque of the API, but they know when that torque matters, and who should care. They understand where to go deep, and where to step back. And most importantly, they help teams stay connected to a bigger picture—without slowing them down.

Ultimately, architecture should enhance delivery—not trail it. And if frameworks or principles are used, they should support that outcome, not lead it.

How Enterprise Architects Should Work — and Where It Breaks Down

Many people in senior business positions have grown up through diverse, hands-on roles. A senior research VP of innovation, for example, likely worked their way up from analyst to production manager—gaining exposure to operations, supply chain, planning, costing, and more.

That experience matters. It teaches you to understand process before trying to transform it. It builds credibility.

And it’s exactly the mindset enterprise architects need.

In my view, this is how EA should work: jump into the deep end, do the research, understand how things really work—and then apply architecture knowledge to connect the dots. In many of my freelance roles, this approach won respect from senior business leaders. Some even joked that I was doing a stint in IT from the business side—because the principles worked, regardless of org chart.

Where EA consistently struggled was in environments that overemphasised abstract alignment or trend-based planning, while missing opportunities to engage directly with users, operations, and delivery teams. Architecture disconnected from domain understanding quickly loses credibility.

If you want to deliver something valuable and tangible, something people can actually use—you have to understand the domain deeply enough to help shape it.

That’s not easy. But if an organisation builds its EA function with a thoughtful model—one that includes experienced architects who can engage across IT and business and pairs them with learners who actively document outputs, patterns, and decisions—it creates a sustainable path for growing the next generation of enterprise architects. In doing so, the team not only delivers value today but builds a living knowledge base that future professionals can learn from and contribute to.

EA - The Japanese Way

One of the best counterexamples to the “PowerPoint-first” school of enterprise architecture comes from where you might least expect formal frameworks: Japan.

Successful Japanese companies like Toyota, Sony, and Hitachi have long practiced a form of implicit enterprise architecture—without ever naming it as such. Their approach is embedded in culture, not codified in documents.

Here’s how they do it:

• Architecture Through Culture, Not Committees

• Long-Term Vision Without Over-Specification

• Systems That Evolve via Kaizen, Not Big Bangs

• Tight IT-Business Integration Through Keiretsu

• No Formal EA Role—Yet the Outcomes Are Better

Architecture lives in the roles of engineers, product owners, and department leads. The results? Stable, integrated, and adaptable systems. No formal “EA,” but unmistakable enterprise-wide thinking.

EA Is Not Dead — But It Must Evolve

Let’s be clear. The principles of EA still matter. Probably more than ever.

We’re dealing with more complexity, more platforms, more data, and faster business cycles. But EA needs to show up differently:

• Embedded in delivery

• Empowered with context

• Accountable to outcomes

• Agile in spirit, even if not by methodology

Frameworks, principles and review/collaboration committees aren’t the enemy. But they must be a means to clarity, not an end in themselves.

Maybe it’s time we stopped trying to define architecture with documents—and started proving its value through outcomes.

Final Thought

Enterprise Architecture isn’t dead. But the ivory tower version of it should be.

The next generation of architects won't be the PowerPoint champions. They'll be the people who can span product, platform, and process. Who can work in the detail just enough to influence outcomes. Who know when to build, when to standardize, and when to get out of the way.

Because in the end, architecture isn’t about alignment slides.

It’s about how everything fits together — and whether it actually works when it rains.

The plant manager would roll up the sleeves - often with experts - until the problem is resolved. EA needs to do the same.

Let’s Talk

Agree? Disagree? I’d love to hear your take. If you’re in EA, delivery, IT strategy, or leadership — let’s connect and keep the conversation going.

#EnterpriseArchitecture #DigitalDelivery #Leadership #BusinessITAlignment #Agile #Architecture #Strategy #EA #ProductThinking #TechnologyLeadership #ManufacturingMindset #ITStrategy #LeanArchitecture