In a typical architecture operating model, how do the responsibilities of an Enterprise Architect differ from those of a Solution Architect, and how would you express that split using a RACI matrix for a new cross-team initiative?

## Scope and horizon, not seniority Architecture roles in most operating models are differentiated by **scope and time horizon**, not by seniority alone. - **Enterprise Architect (EA)** — works at the portfolio or organization level: they maintain the technology strategy, the reference architectures other teams build from, the approved technology radar, and standards for data ownership, integration patterns, and security baselines. Their horizon is typically long — 1 to 3+ years — because their job is to make sure decisions made today don't box the organization into a corner later. - **Solution Architect** (sometimes Project or Application Architect) — works at the level of a single initiative: given the standards and reference architectures the EA function has set, they design the concrete solution — which services exist, how they talk to each other, what technology is used within the approved radar, and how non-functional requirements are met for that specific system. - **Domain or Technical Architect** — sits between the two, owning architecture for one bounded business domain across multiple projects — narrower than enterprise scope, broader than a single solution. ## What a RACI adds RACI (Responsible, Accountable, Consulted, Informed) is a mechanism for making this scope split explicit and auditable rather than left to informal negotiation. For a new cross-team initiative, a workable RACI typically looks like: | Role | Where it lands on the matrix | |---|---| | **Solution Architect** | Responsible for producing the solution design and often Accountable for the technical decisions within it — they're the one who has to defend the design and live with its consequences | | **Enterprise Architect** | Consulted during design — brought in early enough to flag conflicts with reference architectures and catch cross-system impacts before they're baked in — and Informed once the design is finalized, unless the design touches something genuinely cross-cutting (a new technology entering the radar, a shared data domain, a compliance-relevant system), in which case the EA becomes Accountable for that narrow compliance slice specifically | | **Delivery leads and product stakeholders** | Round out the matrix, usually Consulted on feasibility and priority and Informed on the final design | Writing this down per initiative forces different people to be explicitly accountable for different slices of the same decision, instead of it being assumed. ## Why formalize it Why formalize this at all, instead of letting architects sort it out informally? Without an explicit split, two failure patterns recur. 1. **First**, EAs drift into reviewing (or redesigning) every solution in detail, because nothing stops them — this recreates a centralized bottleneck under a federated-sounding title, since the EA becomes accountable for decisions they don't have the local context to make well. 2. **Second, and more commonly**, Solution Architects make decisions that quietly violate enterprise standards because no one was ever explicitly Consulted or Accountable for compliance — the standard existed on paper but no role was on the hook for applying it to this project. The RACI closes both gaps: it names who must be asked before a decision is final, and who has to answer for it afterward. ## The trade-off The trade-off is **process weight versus decision quality**. A well-run RACI catches standards violations and cross-system impacts before they're expensive to fix, but adds coordination overhead — someone has to convene the Consulted parties, and if the EA function is small relative to concurrent initiatives, being Consulted on every one becomes its own lighter-weight bottleneck. Loosely run, the RACI becomes a document nobody checks, and the role split degrades back into whoever happens to be in the room making the call. ## Failure modes Failure modes show up concretely. - **A common one:** the EA is marked Consulted but is looped in only after the design is essentially final (a rubber-stamp review), so 'Consulted' is theater and standards drift happens anyway. - **Another:** the Solution Architect role is filled by whoever is senior on the delivery team with no explicit architecture mandate, so 'Responsible' exists informally but nobody outside the team knows who to ask, and cross-team dependencies get missed. - **A third:** role titles exist but the RACI was never written for this initiative, so when a production incident traces back to an architecture decision, there's a real governance dispute about who was accountable. ## Where it shows up A concrete instance: many enterprises with a TOGAF-influenced EA practice explicitly separate 'Architecture Vision/Business Architecture' work (EA-owned) from 'Opportunities & Solutions/Migration Planning' (solution-architect-owned) as distinct phases of the same ADM cycle — effectively this RACI split formalized into a methodology's phase structure.