Direct Answer
TOGAF Phase A — Architecture Vision — produces five core outputs: the Architecture Vision document, the Statement of Architecture Work (SoAW), an outline Architecture Definition Document (ADD), a stub Architecture Roadmap, and a Communication Plan. In Sparx EA, you capture these not as Word documents but as live model elements: drivers, goals, stakeholders, and principles in the motivation layer; an ArchiMate motivation viewpoint; and a requirements package seeded with high-level constraints. The outputs are reviewed and approved by the Architecture Review Board (ARB) before Phase B begins. Skipping Phase A — jumping straight to current-state mapping — is the most common enterprise architecture failure pattern because it produces a model with no authorised scope, no agreed problem statement, and no stakeholder sign-off. Phase A is the foundation that makes everything else defensible.
What Phase A Actually Produces
Most practitioners treat Phase A as an administrative hurdle — a document to get signed so they can start “real” architecture work. That framing is wrong, and it explains why so many EA programmes drift into scope creep, stakeholder conflict, and inconclusive outputs.
Phase A establishes the architectural scope of work and gains formal approval to proceed. Without it, every Phase B deliverable is vulnerable to challenge: “Who agreed we were solving this problem? Who authorised this scope?”
The five formal outputs are:
Architecture Vision document. A high-level description of what the target architecture will achieve, why this initiative exists, and what business value it delivers. Written for executives and sponsors — not architects. Typically 5–15 pages. Sparx EA generates this from model elements; it should not be authored independently of the model.
Statement of Architecture Work (SoAW). The formal contract between the architecture team and the sponsor. It defines 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 Phase A stub ensures that the timeline assumptions visible to executives are traceable to actual architecture decisions rather than being invented after the fact.
Communication Plan. Who receives what artefact, 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.
Drivers, Goals, Goals and Principles. In Sparx EA, create a Motivation package under your architecture root. Populate it with:
- Driver elements for each business driver (e.g., “Regulatory compliance — APRA CPS 230”, “Cost reduction — 20% OpEx reduction by FY27”)
- Goal elements for each architecture goal, linked to drivers with Influence relationships
- Principle elements for each architecture principle, with rationale and implications captured in tagged values
- Stakeholder elements for each key stakeholder, with their concerns documented
This is not busywork. AI tools querying your model via MCP need this structure to answer questions like “what business goals does this application serve?” without that answer being locked in a PDF.
ArchiMate Motivation Viewpoint. From the motivation package, create a Motivation viewpoint diagram showing the stakeholder-goal-principle-driver relationships. This is the single diagram you present at Phase A ARB review. It fits on one slide and tells the whole story.
Requirements Package. Seed a Requirements package with high-level constraints and assumptions captured during stakeholder interviews. These are not detailed functional requirements — they are the boundary conditions on the architecture. Tag each with source (stakeholder name), status (confirmed/assumed), and phase (Phase A).
Stakeholder Register. Model each stakeholder as an ArchiMate Stakeholder element. Capture their role, their concerns, and their communication preference (tagged values). This feeds directly into the Communication Plan.
Who Approves Phase A Outputs
The Architecture Review Board (ARB) approves the Statement of Architecture Work before Phase B begins. In most organisations the ARB is chaired by the Chief Architect or CTO and includes senior business representatives, IT leadership, and security.
What the ARB actually reviews at Phase A:
- 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 organisation does not have a functioning ARB, Phase A is where you establish one. The Amplify engagement 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 programmes, and it is almost always rationalised 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 that the business did not prioritise, and consuming months of effort 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 AI Tools Use Phase A Outputs
When you model Phase A correctly in Sparx EA, AI tools operating via MCP (Kernaro, Copilot Studio) can interrogate your motivation layer directly.
Practical queries that become possible:
- “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?”
- “Summarise the architecture scope approved in the current Statement of Architecture Work.”
None of these queries 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.
Frequently Asked Questions
Q: How long should Phase A take? A: For a well-bounded initiative with engaged sponsors, two to four weeks. For a programme-level engagement with complex stakeholder landscape, four to eight weeks. Phase A should not take longer than ten percent of the total programme timeline. If it is taking longer, scope is not agreed — which is itself a governance problem Phase A should surface.
Q: Does Sparx EA have a TOGAF ADM template? A: Yes. Sparx EA ships with a TOGAF ADM framework that includes pre-built packages for each phase, standard ArchiMate viewpoints, and a catalogue of TOGAF-aligned element stereotypes. The MDG Technology for TOGAF extends this with additional tagged values and diagram types. Contact us if you need help configuring the baseline.
Q: What is the difference between the Architecture Vision and the Architecture Definition Document? A: The Architecture Vision is a high-level executive summary of what the target architecture achieves and why. The ADD is the detailed technical specification built across Phases B, C, and D. The Vision is typically 5–15 pages; the ADD can run to hundreds of pages for complex programmes. The Vision is approved in Phase A; the ADD is approved in Phase E before migration planning.
Q: Who should attend stakeholder interviews for Phase A? A: Business sponsors, capability owners, and the CIO or equivalent technology executive at minimum. Also include the chief risk officer and compliance team if the driver is regulatory. Avoid inviting only technical staff — Phase A stakeholder interviews should surface business concerns, not technical preferences.
Q: Can we run Phases A and B in parallel to save time? A: No. Phase B scope depends on Phase A scope approval. Running them in parallel means Phase B work may be invalidated when the ARB modifies the Phase A scope. The apparent time saving becomes a rework cost. If the programme timeline is genuinely constrained, the right response is to narrow Phase A scope, not to skip the approval gate.
Q: How does the Communication Plan actually work in practice? A: At minimum it defines: stakeholder group, what they receive, in what format, at what cadence, and who is responsible. For example: “Executive sponsor — Architecture Vision summary — PowerPoint — monthly — Chief Architect.” In Sparx EA, communication artefacts can be generated from model views so the Communication Plan is delivered from a live source, not maintained separately.
Next Step
If your architecture programme lacks a functioning Phase A process — no formal SoAW, no ARB approval gate, no stakeholder register in the model — the Discover engagement 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, the Amplify engagement delivers the framework, templates, and team uplift to make that happen.
