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 a common reason 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?"

For an architect, Phase A is where the questions get agreed: what problem the architecture will address, for whom, and what decisions it will inform. Today the architect then builds the motivation model, the stakeholder register and the documents by hand. The AI-augmented way is to settle the scope, drivers and principles with sponsors, then have AI create the motivation package and draft the documents from the model for the architect to review. The skill is asking sponsors the right questions and stating the scope precisely, because AI builds what you tell it to and cannot tell you which problem matters.

What Phase A 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 outputs this article covers 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. Kept short, 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 the model packages in scope so there is no ambiguity about what is included.

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.

High-level roadmap milestones. High-level milestones only, no work packages yet; the roadmap is populated during Phase E. The milestones keep 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. Model Phase A outputs instead of storing them as attached documents. The sequence below turns the motivation package into a single reviewable view.

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 and the sponsor approve 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, because there is none yet. It approves the mandate to do the work. If your organization does not have a functioning ARB, Phase A is where you establish one, and Configure the Solution covers setting up the governance around it.

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 usually 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 and structured, whether you query it directly, through a report, or with an AI assistant that can read the repository.

Frequently asked questions

What this means for the architect

If your architecture program lacks a functioning Phase A process, with no formal SoAW, no ARB approval gate and no stakeholder register in the model, Paralysis to a Plan is a starting point. If Phase A is in place and you want to run the full TOGAF ADM with Sparx EA as the single source of truth, Configure the Solution covers the framework and the team's way of working. In both cases the architect's contribution is agreeing the scope and questions with sponsors, and AI carries the modeling.