TOGAF Phase A: Architecture Vision in Sparx EA — Artifacts, Stakeholders and Outputs

Most practitioners treat TOGAF Phase A — Architecture Vision — as an administrative hurdle to clear before the "real" work starts. That framing is exactly why so many enterprise architecture programs drift into scope creep, stakeholder conflict, and inconclusive outputs. Phase A establishes the scope of work and gains formal approval to proceed. Without it, every later deliverable is open to the question: "Who agreed we were solving this problem? Who authorized this scope?"

What Phase A actually produces

Phase A establishes the architectural scope of work and gains formal approval to proceed. Treating it as a document to get signed so you can start "real" architecture work is the framing that leads to scope creep and inconclusive outputs. The five formal outputs are:

Architecture Vision document. A high-level description of what the target architecture will achieve, why the initiative exists, and what business value it delivers. Written for executives and sponsors, not architects. Typically 5–15 pages, and generated from model elements rather than authored independently of the model.

Statement of Architecture Work (SoAW). The formal contract between the architecture team and the sponsor: scope, timelines, resources, constraints, and sign-off criteria. This is the document the ARB approves. In Sparx EA, the SoAW references model packages by GUID so there is no ambiguity about what is in scope.

Architecture Definition Document (ADD) outline. Phase A does not complete the ADD — it creates the structure, sections, and metadata. The ADD is populated across Phases B, C, and D. In Sparx EA, this is the top-level package hierarchy with placeholder diagrams.

Architecture Roadmap stub. High-level milestones only, no work packages yet — the roadmap is populated during Phase E. The stub keeps the timeline assumptions visible to executives traceable to actual architecture decisions rather than invented after the fact.

Communication Plan. Who receives what artifact, at what cadence, in what format. Architects routinely skip this and then wonder why stakeholders are surprised by Phase B outputs.

Capturing Phase A in Sparx EA

Sparx EA's motivation layer is purpose-built for Phase A. Do not store Phase A outputs as attached documents — model them. The sequence below turns the motivation package into a single reviewable view.

This is not busywork. A structured motivation layer is what lets later queries against the model answer "what business goals does this application serve?" without that answer being locked in a PDF.

Who approves Phase A outputs

The Architecture Review Board approves the Statement of Architecture Work before Phase B begins. In most organizations the ARB is chaired by the Chief Architect or CTO and includes senior business representatives, IT leadership, and security. At Phase A, the ARB reviews:

• Is the scope clearly bounded and agreed by sponsors?
• Are the business drivers documented and validated?
• Are the architecture principles correct and complete?
• Is the SoAW achievable within the proposed timeline and resource?

The ARB does not review technical detail at Phase A — there is none yet. They are approving the mandate to do the work. If your organization does not have a functioning ARB, Phase A is where you establish one; Configure the Solution includes ARB charter development and facilitation design as a standard deliverable.

The most common Phase A mistake

Skipping Phase A and going straight to current-state mapping. This is the most common mistake in enterprise architecture programs, and it is almost always rationalized as "we need to understand where we are before we can say where we're going."

The problem is not the current-state mapping — it is doing it without an agreed scope, an approved problem statement, or stakeholder sign-off on what questions the architecture is supposed to answer. The result is a beautiful current-state model that no one asked for, answering questions the business did not prioritize, and consuming months before anyone asks: "What decision does this enable?"

Phase A forces that question first. The Statement of Architecture Work is literally a contract that says "we will answer these questions, for these stakeholders, by this date, to enable these decisions."

How Phase A outputs pay off later

When you model Phase A correctly in Sparx EA, the motivation layer becomes queryable rather than buried in a Word file. Practical questions a structured model can answer:

• "What business drivers are not yet addressed by any architecture initiative?"
• "Which stakeholders have concerns that are not mapped to any goal?"
• "Which architecture principles have no associated design decisions?"
• "Summarize the architecture scope approved in the current Statement of Architecture Work."

None of these work if Phase A lives in a Word document on a SharePoint site. They work when Phase A is in the model, structured, and tagged — whether you query it directly, through a report, or with an AI assistant that can read the repository.

Frequently asked questions

Where Sparx Services fits

If your architecture program lacks a functioning Phase A process — no formal SoAW, no ARB approval gate, no stakeholder register in the model — Paralysis to a Plan is the right starting point. We audit your current EA practice, identify governance gaps, and deliver a recommended architecture operating model including Phase A process design.

If you have Phase A in place but want to build out the full TOGAF ADM practice across all phases with Sparx EA as the single source of truth, Configure the Solution delivers the framework, templates, and team uplift to make that happen.