Enterprise Architecture Myth: Your Enterprise Architecture Will Just “Emerge” from Solution Designs

Why you can’t build enterprise architecture from the bottom up—even if it sounds agile

I’ve actually heard this claim—seriously—from very credible people:

"We don’t really need to document enterprise architecture (EA) separately. It will naturally take shape as we create more and more solution architecture."

At first, it sounds appealing. Lean. Agile. Efficient. Why bother with a top-down architecture model if your projects are already producing solution designs? Isn’t that enough?

This thinking especially resonates in agile environments, where documentation is minimized and architecture tends to follow delivery. Solution designs accumulate over time—so wouldn’t EA just… emerge?

But as nice as that sounds in theory, it simply doesn’t work in practice.

Why Doesn’t It Work?

Let’s break it down. While solution architecture is undoubtedly important, it only covers a narrow slice of your organization’s architecture—usually focusing on a very limited set of processes and applications. Expecting EA to “emerge” from these bits and pieces over time just doesn’t work in reality.

Here’s why:

• It would take forever. Waiting for every organizational function, business process, capability, application, and integration to eventually be covered by solution projects is extremely slow—and you’ll always have gaps. Solution architecture also typically focuses on the target state of a specific solution, not the existing landscape. That means important parts of the current state may never be touched at all, leaving critical elements undocumented and invisible to the broader organization.

• It leads to fragmentation. Every solution is designed by different people, for different reasons, using different methods. Descriptions vary in detail, there’s no shared modeling approach, and elements get duplicated. Teams call the same thing by different names, and no one ensures it all adds up to a consistent, cohesive whole.

• You lose critical context. EA isn’t just a top-down vision—it provides the foundation for practical development. Without a clear current-state view, you can’t define a meaningful target state or understand how new solutions fit into the big picture. Solution architects are left without essential information like which capabilities already exist, what application support them, where data lives, or what interfaces can be reused. As a result, each project starts from scratch, planning becomes harder, and alignment suffers.

The Reality: Enterprise Architecture Supports Solution Architecture—Not the Other Way Around

In reality, the relationship between enterprise and solution architecture flows in the opposite direction from what some might assume: EA supports and enables effective solution architecture—not the other way around.

EA provides the foundation that solution architects rely on. It offers a shared language, reusable architecture content, and a high-level structure that helps guide and accelerate design work. Without this structure, each solution must be developed in isolation, often without visibility into how it fits into the broader organizational landscape.

For example, without a clear application portfolio, how can you know what applications your new solution should integrate with—or whether an existing component could be reused instead of building something from scratch? Without capability models, it’s difficult to understand where a new application fits within the business or what value it is intended to deliver. And without integration maps, the risk of duplicative applications and messy point-to-point integrations increases dramatically.

Simply put, solution architecture becomes significantly more efficient, coherent, and aligned when EA is there to support it.

Start Light—but Start with Enterprise Architecture

This doesn’t mean you need to build an all-encompassing EA repository before starting any projects. Quite the opposite.

Even a lightweight EA baseline—like a current-state capability map, a high-level application landscape, and key data flows—makes a real difference.

These assets provide a structure that provides a baseline, speeds up solution architecture, and prevents future mess.

Once the basic current-state description is in place, solution designs can build on it—rather than accidentally working against each other.

Final Thoughts

The idea that EA will “emerge” organically from project work is comforting—but it’s also unrealistic. This approach doesn’t produce a comprehensive view of the current state, since many areas of the organization may never be touched by projects. At the same time, it doesn’t result in a coherent target state either—projects focus on their own solutions, not on shaping a unified future architecture.

Without intentional effort, you end up with fragmented views and no solid baseline or shared vision to guide transformation. Instead of clarity and alignment, you get silos and inconsistencies.

That’s why EA can’t be left to chance. It must be actively developed to provide the common foundation across initiatives.

So yes, solution architecture is critical. But it only works well at scale when EA provides the structure, context, and coherence that ties it all together.

📚 Want more no-nonsense EA content like this? Subscribe to Enterprise Architecture Transformation to get practical advice on building useful, lean, and impactful EA—without the fluff.