“Enterprise architect” and “solution architect” are often used loosely, but they're distinct roles working at different altitudes. Understanding the difference clarifies who does what.
Both roles design. They differ in scope, time horizon and what they are accountable for. An enterprise architect is accountable for coherence across the organisation over years; a solution architect is accountable for a specific system working over months.
| Enterprise architect | Solution architect | |
|---|---|---|
| Scope | The organisation or a major domain | One solution or programme |
| Horizon | Two to five years | Three to eighteen months |
| Unit of work | Capability, portfolio, standard | System, integration, component |
| Optimises for | Coherence, reuse, long-run cost | Delivery, fitness for purpose, time to value |
| Main stakeholders | Executives, investment boards, domain leads | Programme managers, delivery teams, vendors |
| Typical output | Target state, roadmap, principles, assessment | Solution design, interface spec, NFRs |
| Judged on | Whether decisions still make sense in three years | Whether the thing works and shipped |
The work is portfolio-level and mostly analytical: describing current state, defining a target, assessing capability maturity, rationalising the application estate, setting standards and running governance.
The role's leverage comes from operating before commitment. An enterprise architect who influences an investment case shapes what happens; one who reviews designs after funding is approved is largely commenting. The most common failure of the role is drifting into the second position and then wondering why nobody listens.
The work is design-level and much more concrete: choosing components and patterns, specifying integrations, defining non-functional requirements, guiding developers, resolving the daily trade-offs between what is ideal and what ships.
Solution architects live with consequences enterprise architects often do not. They are in stand-ups, they answer for slipped dates, and they are the ones who have to make an elegant enterprise standard work against a vendor product that does not support it. That proximity is the role's strength and the source of most friction with EA.
The productive relationship is constraint-and-design. Enterprise architecture sets the boundaries — principles, standards, target state, approved technologies. Solution architecture designs freely within them and escalates when the boundary genuinely does not fit.
That requires two things from the EA side. Constraints must be few enough and clear enough to design within — an ambiguous standard is worse than none, because it produces rework at review. And there must be a legitimate route to deviate, which is what an exception process provides. Without one, solution architects deviate silently, and enterprise architecture loses both the standard and the visibility.
The overlap is real, usually at the boundary of a large programme where a solution is big enough to have enterprise consequences. Three frictions recur:
Solution architecture is the more common route into enterprise architecture, and the transition is harder than it looks. The skills that make a strong solution architect — decisiveness, technical depth, ownership of a deliverable — matter less than the ones enterprise architecture actually runs on: influence without authority, comfort with ambiguity, and patience for decisions that take a year to prove out.
The most common stumble is continuing to solve problems personally instead of shaping the conditions under which others solve them.
MethodVault's toolkits support both altitudes — governance and capability assessment for the enterprise view, architecture review for solution-level work.
