Solution Architects vs Enterprise Architects: Where the Model Overlaps

Ask a solution architect and an enterprise architect to define their own job, and you'll get two answers that sound like they belong to different professions. Ask them to define where one job ends and the other begins, and the answers get vague fast. That vagueness isn't a failure of either role. It's a sign that the boundary was never really about subject matter — it's about zoom level, drawn over the same underlying territory.

A distinction that's cleaner on paper than in practice

On paper, the split is tidy. A solution architect owns a system, or a delivery initiative built around one — its internal structure, its component boundaries, the way it talks to the three or four systems it integrates with, and whether the design it's shipping toward will actually work when it goes live in six weeks. The horizon is a release. The unit of concern is a system.

An enterprise architect owns the portfolio — dozens or hundreds of those systems at once, not any single one in detail. The questions are different in kind, not just in scale: does the organization have three CRMs doing overlapping jobs because nobody was looking across delivery streams? Does a given capability have a clear owning system, or five partial ones? Is the direction of travel toward the target architecture, or away from it? The horizon is measured in years. The unit of concern is the capability, the standard, the redundancy — not any one system's internals.

Where this gets messy is that both roles are staring at the same organization, and most of the time, at the same systems. The solution architect's system doesn't stop being a system just because someone else is looking at it from further away. It's simultaneously "the payments service I'm redesigning this quarter" and "one of four systems in the portfolio doing payment orchestration, two of which are candidates for consolidation." Those are two descriptions of one object, seen at two distances — not two objects that happen to share a name.

In practice, organizations rarely acknowledge that plainly. They set the two roles up as separate functions with separate deliverables, separate review boards, and — this is the part that actually causes damage — separate tools and separate models of the world that nobody is responsible for keeping consistent with each other. The solution architect's design lives in a project repository, a set of diagrams, maybe a wiki page. The enterprise architect's landscape lives in a different tool entirely, updated on a different cadence, by a different person, from a different set of inputs. Two models of the same reality, drifting apart from the day they're created.

Two zoom levels, one set of facts

The cleaner way to think about this — and the way Mooodels is built to support it — is that solution architecture and enterprise architecture are not two disciplines that happen to look at related things. They're two views into the same underlying model, distinguished by scope and vocabulary rather than by subject matter. The solution architect's system is not like one of the enterprise architect's landscape elements. It is one of the enterprise architect's landscape elements, examined at a resolution the portfolio view doesn't bother to render.

This is easiest to see by walking the zoom levels directly. At the portfolio level, "Claims Processing" is a single box: a capability, served by one or two applications, with a handful of relationships to adjacent capabilities like Policy Administration and Customer Communications. That's the right amount of detail for a portfolio review — anything more would be noise for that audience. Zoom into the box, and it stops being one thing: it's an API gateway, three internal services, a message queue, a database, and a batch job nobody documented until someone finally modelled it. That's the solution architect's view of the exact same territory, at the resolution that matters for a delivery decision.

Nothing about that zoom-in invents new facts. The internal services are real; they existed before anyone drew them. What changes between the two views is which facts are shown and at what granularity — not which facts are true. A model that treats these as one connected graph can produce both views from the same data, because they always were the same data. A pair of tools that treat them as separate artifacts has to invent the connection by hand, every time, and usually doesn't.

Where the concerns genuinely differ

None of this means the two roles think about the same things, or should. The scopes overlap; the concerns don't. A useful way to lay it out:

That last row is the important one, because it's where the theoretical distinction turns into a practical cost. Both failure modes are consequences of the same root cause: two people, two models, no shared spine connecting what one of them decided to what the other one is tracking.

What breaks when the two stay separate artifacts

The solution decision made blind

A solution architect redesigning claims processing doesn't set out to create redundancy. They're solving a real, immediate problem: the existing service can't handle the new volume, the old integration pattern is brittle, and there's a delivery deadline. Given those constraints, standing up a new orchestration layer that talks directly to three downstream systems is a perfectly sound local decision. It ships, it works, it gets signed off.

What that decision doesn't have visibility into — because the tool it was made in has no concept of "portfolio" — is that a different delivery stream, eighteen months earlier, built almost the same orchestration capability for a different line of business, under a different name, and it's still running. Nobody making the current decision was negligent. The information that would have surfaced the overlap simply lived somewhere the solution architect had no reason to open: a portfolio tool maintained by a different team, updated on a different schedule, that this delivery wasn't plugged into. The redundancy gets discovered eventually — usually in a rationalization exercise a few years later, at which point untangling two production systems that both grew real dependents is an order of magnitude more expensive than it would have been to notice the overlap during design.

This is not a training problem or a communication problem in the way it usually gets diagnosed after the fact ("the solution architect should have checked with EA first"). It's a structural problem: the information needed to make the local decision well lived in a model the local decision-maker had no route into. Telling people to check a portal nobody keeps current doesn't fix that. Connecting the two models does.

The landscape that was never actually updated

Run the same failure the other direction and you get the complaint enterprise architects make most often, usually in exactly these words: the landscape is stale. Not wrong in principle — stale, meaning it was accurate once and nobody told it what changed. The reason is almost always the same. Solution architects build the real thing; enterprise architects maintain a separate description of it; and updating that description after delivery is somebody's optional extra task, competing for time against the next deadline, in a tool most delivery teams barely open.

So the landscape drifts. Not dramatically at first — one undocumented integration here, one decommissioned system left in the diagram there. But drift compounds, and eighteen months in, an enterprise architect presenting the "current state" landscape to leadership is presenting something closer to a snapshot of intentions from the last time someone updated it than a description of what's actually running. Every capability assessment built on top of that landscape inherits the staleness. Every redundancy analysis misses what was never recorded. The portfolio view isn't wrong because enterprise architecture did a bad job — it's wrong because it was structurally disconnected from the only place the ground truth actually gets produced, which is delivery.

Both failures have the same shape: information generated at one zoom level doesn't reach the other, because reaching it requires a manual re-entry step that competes with everything else on someone's plate and reliably loses. Fixing that by asking people to be more diligent about updating two systems has been tried, repeatedly, at most organizations that run this way. It doesn't hold up under deadline pressure, because it isn't supposed to — it's asking humans to do consistency-maintenance work that the tooling should have made unnecessary.

The same handoff, on one connected model

Take the claims processing example again, but run it through a single canonical model instead of two disconnected ones — the way it plays out when a solution architect and an enterprise architect are both working in Mooodels, each in the profile suited to their scope, against the same underlying facts.

The solution architect opens the workspace and works largely in the Generic or C4 profile, because that's the vocabulary that fits a system redesign: containers, components, APIs, data stores. They model the new orchestration layer for claims processing — an API gateway in front of three internal services, a queue for async settlement, a database. Nothing about this feels like enterprise architecture to them; it's a delivery task, done in the language a solution architect actually thinks in. But because the profile is a lens on the canonical model rather than a separate file, every element they create — the gateway, the services, the relationships between them and the systems they call — lands in the same model an enterprise architect's portfolio view is built from.

Before they finalize the design, they run an impact query on the systems they're about to integrate with — a five-second operation in a connected model, not a research project. The query surfaces something they wouldn't have known to look for by name: an existing element, tagged under a different business unit, already realizing a capability that looks a lot like what the new orchestration layer is about to duplicate. That's not the enterprise architect manually catching it in a review meeting three weeks later. It's the solution architect seeing it themselves, at design time, because the query runs against one graph that already contains both systems — not because someone remembered to cross-check a second tool.

They flag it, adjust the design to extend the existing capability rather than duplicate it, and ship. No separate diagram had to be drawn for the enterprise architecture team. No status meeting had to happen for the redundancy to surface. The information was available at the moment it was cheapest to act on, because it lived in the same place the decision was being made.

Meanwhile, the enterprise architect never touched the component-level detail of claims processing, and doesn't need to. Working in the ArchiMate profile over the portfolio, they see "Claims Processing" as one capability-realizing application, its relationships to Policy Administration and Customer Communications intact, its status current — because it's current by construction, not by someone remembering to update a second artifact after go-live. When the redundancy review comes around at the quarter's end, the landscape view already reflects what was actually built, not what was drawn eighteen months ago and never touched again. The enterprise architect's job in that review shifts from "first, figure out what's actually true" to "now, decide what to do about what's true" — which is the part of the job that actually needs their judgment.

Neither architect had to learn the other's tool, adopt the other's vocabulary, or sit through a handoff meeting to keep the two views aligned. The solution architect worked in C4/Generic elements scoped to one system; the enterprise architect worked in ArchiMate scoped to the portfolio. What made the handoff work wasn't process — it was that there was only ever one model underneath both profiles, so nothing needed to be synchronized because nothing was ever duplicated in the first place.

Pluggable profiles, not merged roles

It's worth being precise about what "one model" does and doesn't mean here, because the objection writes itself: surely forcing an enterprise architect to think in component diagrams, or a solution architect to think in capability maps, makes both jobs worse. It would — which is why that isn't what a shared model requires. Mooodels keeps the profiles separate and pluggable on purpose: Generic and C4 for the solution-scoped work, ArchiMate for the portfolio-scoped work, each with its own vocabulary, its own element types, its own visual language. A solution architect never has to open an ArchiMate palette to get their job done, and an enterprise architect never has to think in containers and components to get theirs done.

What's shared isn't the vocabulary — it's the underlying object graph the vocabularies both describe. An application in the C4 profile and an application component in the ArchiMate profile can be the same canonical element, described two ways for two audiences, rather than two elements that happen to correspond if someone remembers to keep them matched. That's the actual mechanism behind the scenario above: the redundancy query worked across profiles not because the tool forced both architects into one notation, but because notation and underlying identity are two different layers, and only one of them needs to be shared for impact analysis, rules, and search to work across the whole portfolio at once.

This also means the boundary between the two roles doesn't have to be re-litigated every time it gets blurry in practice — which, as the opening of this piece argued, is most of the time. A team lead who does a bit of both isn't forced to pick a tool and lose visibility into the other half of their own job. A solution architect curious about portfolio-level redundancy doesn't need permission to open a different system — the query is available from where they already are. An enterprise architect who wants to sanity-check whether a landscape box still matches reality can drop into the same element's solution-level detail without switching tools, asking someone for a screenshot, or waiting for the next scheduled sync.

Signs your organization is running two models by accident

Most organizations don't decide, deliberately, to keep solution architecture and enterprise architecture as disconnected artifacts. It happens by accumulation — a delivery team picks a tool that suits a project, an EA function picks a repository that suits a portfolio review, and the two choices are never revisited against each other. A few questions tend to surface whether that's happened, regardless of what either team would say if asked directly:

• When a solution architect finishes a design, does anything about it reach the portfolio view without someone manually re-drawing it there?
• If an enterprise architect asks "what does this application actually integrate with today," is the honest answer sourced from a model, or from asking around?
• Has a redundancy or duplication ever been discovered after the fact — in a cost review, a consolidation project, an audit — that a design-time check could plausibly have caught?
• Does updating the enterprise landscape after a delivery depend on someone remembering to do it as a separate step, on their own initiative, after the actual work is done?
• Could a solution architect, mid-design, answer "does anything like this already exist elsewhere in the portfolio" themselves, in minutes, without opening a ticket to another team?

None of these questions is really about tooling maturity in the abstract. They're about whether the two zoom levels are reading the same facts or two separately maintained approximations of them. An organization can have excellent solution architects and an excellent enterprise architecture function and still fail every one of those checks, because the failure lives in the seam between the two roles, not in either role's competence.

It's also worth being honest about what doesn't fix this. Governance boards, architecture review gates, and mandated sync meetings are all attempts to patch the seam with process — and they help, at the margin, for exactly as long as everyone involved has the time and discipline to run them consistently. They tend to degrade under deadline pressure precisely when they matter most, because a review gate is a checkpoint on top of two separate models, not a change to the fact that two separate models exist. The organizations that stop having this problem are the ones that remove the seam itself — by making the solution-level design and the portfolio-level landscape two views of one thing, so there's nothing left to keep in sync by hand.

This is also where interoperability with the tools architects already use matters in practice, not just in principle. Most enterprise architecture functions have years of history sitting in Archi or Sparx EA, and most delivery teams aren't going to abandon whatever they use for solution-level design overnight. A connected model only earns its keep if it can absorb that history rather than asking everyone to start over — importing an existing ArchiMate landscape without flattening it into a generic diagram, and letting a solution-level design round-trip back out to the tools an EA board already trusts. The point isn't to replace either tool by decree; it's to give both roles one place where the facts agree, whichever surface they touch it from.

The boundary is real; the disconnect doesn't have to be

Solution architecture and enterprise architecture are legitimately different jobs, with different questions, different time horizons, and different stakeholders to satisfy — nothing here argues for collapsing them into one role or one vocabulary. The mistake isn't treating them as different disciplines. It's the assumption, baked into most tooling, that different disciplines require different models — and the years of quiet cost that assumption produces: local decisions made without portfolio visibility, and portfolio views that describe a system that stopped existing in that form the day it shipped.

Once the model is shared and the profiles stay separate, the two roles stop needing a handoff process to stay aligned, because there's nothing to hand off. There's one set of facts, examined at whatever zoom level the question in front of you actually calls for.