Architecture Vision and the Statement of Architecture Work
The sets the direction for an architecture effort and the defines the commission that turns that direction into authorised, governable work. The earlier Stage 2 outputs (boundary, stakeholders, principles, scenarios, scope, governance) converge in these two Phase A deliverables.
By the end of this module you will be able to:
- State the two Phase A objectives from C220, distinguish them from the Phase A steps, and explain each in plain language
- Explain the distinct purpose of the Architecture Vision and the Statement of Architecture Work
- List all required contents of the Statement of Architecture Work and explain what each section protects against
- Describe the complete structure of an Architecture Vision document and explain why each section exists
- Draft a London Grid Architecture Vision that traces to scenario, stakeholders, and principles
- Recognise when a polished vision is hiding the absence of a real architecture commission
A 40-page vision. No one knew what work was commissioned.
A health-sector agency completed Phase A with a 40-page Architecture Vision document. The document included a compelling narrative about patient-centred digital services, a set of architectural themes, and a technology direction. The steering group approved it with minor comments.
Two months later, the architecture team tried to begin and discovered that nobody had agreed what work was actually commissioned. The vision said "patient-centred digital services" but the business architecture team needed to know which services, for which patient groups, through which channels, against which constraints, and with what evidence requirements. The vision answered none of those questions.
The problem was that Phase A had produced a vision but not a work statement. The direction was clear enough to inspire, but not specific enough to govern. The team had to go back and write the that should have been completed alongside the vision. That two-month delay was entirely avoidable.
If a Phase A vision inspires but does not specify scope, exclusions, or governance, what has actually been approved?
That story is a useful starting point because it shows what happens when Phase A produces inspiration but not commission. The Architecture Vision and the Statement of Architecture Work do different jobs, and Phase A is weak when the team treats them as interchangeable.
14.1 Phase A in C220: two objectives, delivered through steps
The ADM volume of C220 gives Phase A exactly two objectives. Everything else the phase does is organised as steps that serve those objectives, and each item addresses a risk that will undermine the cycle if it is left unresolved. Here are the two objectives first, with a plain-language explanation of what each one is really asking the team to do.
Objective 1: Develop a high-level aspirational vision of the capabilities and business value to be delivered. The team must articulate what the architecture effort is trying to achieve in terms that can understand and evaluate. This is not a detailed design. It is a directional statement that connects business pressures to architecture ambition. The risk this objective addresses is an architecture effort that produces technically sound work but cannot explain why it matters.
Objective 2: Obtain approval for a Statement of Architecture Work. The team must produce and secure sign-off on a document that defines the scope, approach, schedule, governance, and expected outputs of the architecture engagement. This is the formal commission. Without it, the architecture team has direction but not authority to proceed. The risk this objective addresses is an architecture effort that starts work without agreed boundaries and later faces scope challenges it cannot resolve.
The other concerns practitioners associate with Phase A are not additional objectives. C220 lists them as steps within the phase: the working route to the two objectives above. Certification exams test that distinction, so keep the two lists separate in your head. The steps are set out below, in the order the standard presents them.
Establish the architecture project. Before any analysis begins, the team must confirm the engagement exists as a resourced piece of work: a named sponsor, an agreed way of working with any wider programme, and a mandate to proceed. The risk this step addresses is an architecture effort that starts analysing stakeholders and drivers before anyone has confirmed it is authorised to happen at all.
Identify stakeholders, concerns, and business requirements. The team must map the of different stakeholder groups so that the architecture can address them systematically. This connects directly to the stakeholder work from Module 9. The risk this step addresses is an architecture that solves the wrong problems because it was not grounded in real stakeholder needs.
Confirm and elaborate business goals, business drivers, and constraints. The team must verify that the architecture direction is traceable to real business pressures, not to generic transformation language. The from Module 11 provides the primary evidence for this step. The risk is an architecture effort that is internally consistent but disconnected from the enterprise situation that justifies it.
Evaluate capabilities. Phase A should assess the current state of relevant business to understand where gaps exist. This is a high-level assessment, not a full capability model (that comes in Phase B). The risk is an architecture effort that proposes solutions without understanding the current capability landscape.
Assess readiness for business transformation. The team must evaluate whether the organisation is ready for the changes the architecture will propose. This includes assessing change capacity, stakeholder willingness, and governance maturity. The risk is an architecture that is technically achievable but organisationally impossible to deliver.
Define scope. Phase A must establish clear scope boundaries and explicit exclusions. This means naming which parts of the enterprise are covered, which domains will be addressed, and what is deliberately left out of the first cycle. The risk this step addresses is scope creep: the gradual expansion of the architecture effort until it becomes unmanageable and loses credibility.
Confirm and elaborate architecture principles. The team must agree the that will govern trade-off decisions for the rest of the cycle, alongside any business principles inherited from the enterprise. This is a distinct step from defining scope: scope says what the effort covers, principles say what rules the team will follow once it is inside that scope. The risk this step addresses is an architecture team that reaches a difficult trade-off with no agreed basis for resolving it, so the decision falls to whoever argues loudest in the room.
Develop the Architecture Vision. This is the formal output: a document that articulates the direction, high-level target state, and key architectural decisions for the engagement. The vision must be traceable to stakeholder concerns, business drivers, and the business scenario. The risk is a Phase A that ends without a clear, reviewable statement of architectural direction.
Define the target architecture value propositions and KPIs. Once a vision exists, the team must state the value it will deliver in terms that can actually be measured, not only asserted. This step is what turns "this will improve customer service" into a claim someone can check a year later. The risk this step addresses is a vision that sounds valuable in the room but leaves the sponsor with no way to confirm, after the fact, that the value was actually delivered.
Identify the business transformation risks and mitigation activities. The team must go beyond naming risks to pairing each one with a mitigation the organisation can actually act on. A risk register that lists concerns without owners or mitigations is a symptom of this step being done superficially. The risk this step addresses is an architecture effort that is derailed by a transformation risk that was visible in advance but never assigned to anyone to manage.
Develop the Statement of Architecture Work and secure approval. This is the step that turns the vision into a governable commission: the team drafts the work statement, takes it through the forum, and does not proceed into Phase B until it is approved. The risk this step addresses is an architecture effort that starts detailed work on the strength of an approved vision alone, with no equivalent sign-off on scope, method, or resourcing.
Neither list is a checklist to be completed mechanically. Together the objectives and steps represent the questions that Phase A must answer. If any one remains unanswered, the architecture effort starts the detailed design phases on unstable ground.
14.2 Vision and work statement do different jobs
Phase A is weak when the team treats the vision and the work statement as interchangeable. They are related, but they answer different questions and serve different audiences.
The Architecture Vision explains where the enterprise is trying to go, why that direction matters, and which value or control outcomes justify the change. It should be traceable to concerns and business drivers but does not need to specify every target-state detail. Its primary audience is executive sponsors and steering groups who need to understand and endorse the direction.
The Statement of Architecture Work defines what architecture effort is being commissioned now, under which scope, constraints, methods, and review arrangements. It turns direction into a governable commission. Its primary audience is the architecture team itself, the forum, and delivery partners who need to know what the architecture team will produce, when, and under what rules.
The distinction matters in practice because a compelling vision can mask the absence of a real commission. If the steering group approves a vision that says "we will become a digitally enabled network" but no work statement specifies which will be produced, which domains are in scope, what is excluded, and how the work will be governed, then Phase A has not actually authorised anything. The architecture team will spend the first weeks of Phase B renegotiating scope instead of producing architecture.
An architecture team completes Phase A with a polished Architecture Vision but no Statement of Architecture Work. The team begins Phase B. What is the most likely consequence?
14.3 The Architecture Vision document: complete structure
TOGAF C220 describes the Architecture Vision as a of Phase A. While the exact structure can be tailored to the organisation, a strong Architecture Vision should contain the following sections. Each one exists to answer a specific question that sponsors and governance bodies need answered before they authorise the architecture team to proceed.
1. Problem description and business context. This section summarises the enterprise situation that makes architecture work necessary. It should be traceable to the from the Preliminary Phase. The question it answers: why is this architecture effort happening now?
2. Stakeholder map and key concerns. This section identifies the stakeholder groups whose concerns the architecture must address and summarises the most significant concerns in each group. It should be traceable to the stakeholder analysis from Module 9. The question it answers: whose problems are we solving, and what do they need from the architecture?
3. Business drivers and objectives. This section names the specific business pressures that justify the architecture effort and the measurable outcomes the effort is expected to achieve. The question it answers: what business outcomes will the architecture enable?
4. Scope of the architecture engagement. This section defines what the architecture effort covers and, critically, what it excludes. It should be traceable to the scope work from Module 12. The question it answers: what are the boundaries of this architecture effort?
5. Architecture principles that govern the effort. This section lists the that will shape design decisions throughout the ADM cycle. Each principle should have a statement, rationale, and implications. The question it answers: what rules will the architecture team follow when making trade-off decisions?
6. High-level target-state description. This section provides a directional view of the , typically at the conceptual level. It does not need to specify every component but should show the intended direction of change across the relevant domains. The question it answers: where are we heading?
7. Key risks and constraints. This section identifies the most significant risks to the architecture effort and the constraints that will shape design decisions. These should include organisational, technical, regulatory, and resource constraints. The question it answers: what could prevent us from achieving the vision, and what limits our options?
8. Value proposition. The value the architecture effort will deliver in terms that the sponsor and steering group can evaluate. Value may be expressed in terms of risk reduction, cost avoidance, regulatory compliance, service improvement, or operational efficiency. The question it answers: why is this architecture effort worth the investment?
The test for a complete Architecture Vision is whether a senior stakeholder who has not been involved in the Preliminary Phase work can read it and understand: why the effort exists, what it aims to achieve, whose concerns it addresses, what principles govern it, and what direction it is heading. If any of those questions remain unanswered, the vision is incomplete.
14.4 Statement of Architecture Work: all required contents
The is the formal commission for the architecture engagement. TOGAF C220 identifies specific contents that the Statement should include. Here is the full set, with an explanation of what each section protects against.
1. Architecture project description and scope. A concise description of the architecture effort, including its purpose, the enterprise context, and the scope boundaries. This section protects against ambiguity about what the architecture team is responsible for.
2. Architecture Vision summary. A brief reference to the Architecture Vision that provides the directional context for the work. This section protects against a work statement that is disconnected from the agreed direction.
3. Scope and exclusions. Explicit statement of what is in scope and what is deliberately excluded from the architecture effort. The exclusions are as important as the inclusions. This section protects against scope creep and against stakeholders assuming their area is covered when it is not.
4. Architecture approach and method. A description of how the architecture work will be conducted, including which ADM phases will be followed, what tailoring has been applied, and what tools and techniques will be used. This section protects against methodological ambiguity and ensures that the forum knows what process is being followed.
5. Deliverables, artefacts, and building blocks. A list of the specific , , and that the architecture engagement will produce. Each output should have a named owner and a defined review point. This section protects against ambiguity about what the architecture team will actually produce.
6. Roles, responsibilities, and resource plan. Identification of the architecture roles required, who fills them, and what resources are allocated. This section protects against the common failure where architecture work is assigned to people who have competing priorities and no ring-fenced capacity.
7. Schedule and milestones. A timeline showing when key deliverables will be produced and when governance reviews will occur. This section protects against architecture work that drifts without checkpoints and loses momentum.
8. Governance and review arrangements. A description of how the architecture work will be governed, including the or review forum, the frequency of reviews, the escalation path for disputes, and the and process. This section protects against architecture conclusions being ignored or bypassed.
9. Constraints, assumptions, and dependencies.Documentation of the constraints that limit the architecture team's options, the assumptions that underpin the work, and the dependencies on other programmes, systems, or external bodies. This section protects against assumptions being treated as facts and dependencies being discovered too late.
10. Acceptance criteria and success measures.Definition of how the architecture outputs will be evaluated and what constitutes successful completion of the engagement. This section protects against subjective assessment and ensures that both the architecture team and the governance forum agree on what "done" looks like.
A Statement of Architecture Work without explicit exclusions is almost always over-scoped. Naming what the cycle will not address is as important as naming what it will. Without exclusions, every stakeholder will assume their concern is in scope, and the architecture team will be held accountable for breadth it never intended to cover.
Common misconception
“A work statement without exclusions is complete if the deliverable list is long enough.”
A work statement without explicit exclusions is an implicit promise to cover everything. When stakeholders later discover that their area received less depth or was deferred, they will feel misled. Explicit exclusions protect the architecture team and set honest expectations from the start.
The Phase A gate that turns the vision into a Statement of Work
The Architecture Vision reaches the signed Statement of Architecture Work only after four named checks pass, each owned by a sponsor or board, so one failed check holds the whole statement and returns the vision for another iteration rather than letting weak scope through.
14.5 How traceability protects Phase A
The most useful Phase A work is traceable backwards and forwards. Backwards to concerns, principles, scope choices, and scenario evidence. Forwards to artefacts, review checkpoints, and later ADM stages.
Backward traceabilitymeans that every element of the vision can be connected to a stakeholder concern, a business driver, or a scenario finding. If the vision says "improve connections responsiveness," there should be a traceable path to the scenario that documented the 90-day response time, the stakeholder map that identified applicant frustration, and the principle that requires data integrity at every handoff.
Forward traceability means that the work statement connects to specific deliverables that later phases will produce. If the work statement says the architecture will address data architecture, there should be a named deliverable that corresponds to that commitment. If the work statement excludes technology infrastructure, that exclusion should appear in the planning as a deferred item.
That traceability is what stops the vision becoming aspiration and stops the work statement becoming administration. Each one gives the other practical force. A vision that cannot be traced to evidence is rhetoric. A work statement that cannot be traced to direction is paperwork.
Common misconception
“A polished vision that sounds impressive is strong enough to begin Phase B.”
A vision can sound impressive while still telling delivery teams almost nothing. If it cannot be traced to scope, constraints, and expected outputs, it is not yet strong enough. The test is whether someone reading the vision and the work statement together can explain what the architecture team will produce and what it will not.
Vision claim promoted through six gates to a signed work-statement clause
In TOGAF Phase A every vision claim earns binding weight at each gate it clears, from a loose draft down through review, principle test, scope, schedule and a signed clause, so a claim that never reaches a Statement of Architecture Work commitment leaves the work entirely.
14.6 London Grid Distribution: the vision for network transformation
The London Architecture Vision should follow the structure described above, grounded in the specific pressures and evidence assembled across Modules 8 through 13. Here is what each section should contain for the London case.
Problem description.London Grid's connections process averages 90 days against a 65-day regulatory target. Information publication across the network is inconsistent and sometimes contradictory. Operational resilience depends on ageing OT and telecom systems that are not governed under a shared architecture authority. These pressures are documented in the business scenario from Module 11.
Stakeholder map. The vision identifies distinct stakeholder blocs: Ofgem (regulatory performance and compliance), NESO (planning data for national coordination), operations (network safety and supply continuity), cyber security (OT and telecom estate protection), the connections team (process efficiency and data quality), and connection applicants (response time and transparency). Each bloc has different concerns that require different architecture views.
Business drivers. Connections reform pressure from Ofgem. Unstable information publication affecting regulatory standing. Resilience concerns across OT, IT, and telecoms. The need for coherent data governance across multiple operational systems.
Scope. The first cycle covers the connections process end-to-end (from application to works scheduling), the information-publication chain, and the OT/IT/telecoms resilience interfaces. It excludes generation connection assessment, wholesale market interfaces, and long-term network investment planning (all deferred to cycle two).
Principles.The architecture principles set out earlier in the course, including "One published truth per date," are applied here. Each principle traces to a tension visible in the scenario.
High-level direction. Move from fragmented, system-specific data processes to a governed, traceable information chain. Replace manual data re-entry with structured handoffs at identified integration points. Establish a shared architecture authority that spans operations, IT, cyber, and telecoms. This is directional, not encyclopaedic.
Key risks. The works management system is shared with another programme on a conflicting upgrade timeline. Legacy systems use pre-CIM data formats that require translation. Organisational resistance to cross-functional governance. Regulatory reporting deadlines that constrain transition timing.
Value proposition.Reducing connections response time from 90 days to the 65-day regulatory target is a measurable KPI, not an aspiration, and protects London Grid's regulatory standing and public reputation. Establishing a single authoritative data source eliminates contradictory publications, checked by counting conflicting publication incidents per quarter. Governed resilience across OT, IT, and telecoms reduces the risk of operational incidents during the transition.
14.7 London Grid Distribution: the Statement of Architecture Work
The matching Statement of Architecture Work should specify the first cycle boundary, the artefacts to be produced, the source discipline, the stakeholder and review path, and the issues deliberately left outside the first cycle.
Scope and exclusions. In scope: connections process (application to works scheduling), information-publication chain, /IT/telecoms resilience interfaces. Excluded from cycle one: generation connection assessment, wholesale market interfaces, long-term network investment planning, smart-meter data integration. Each exclusion has a documented rationale.
Deliverables. Business architecture: connections map, capability assessment, organisation mapping. Data architecture: information flow model, data-authority assignment, publication-chain design. Application architecture: integration pattern for the five handoff points. Technology architecture: OT/IT/telecoms resilience baseline (assessment only in cycle one, full target-state design deferred to cycle two).
Governance. Fortnightly Architecture Review with the sponsor, lead architect, repository steward, and rotating domain representatives. Decisions recorded in the with traceability to principles and scenario evidence. Escalation path through the sponsor to the programme board.
Schedule. Phase B (business architecture): 6 weeks. Phase C (information systems): 8 weeks. Phase D (technology baseline): 4 weeks. Phase E (opportunities and solutions): 4 weeks. Total first cycle: approximately 22 weeks with governance reviews at each phase boundary.
Constraints and dependencies. Works management system shared with another programme. Legacy pre- format in the network planning tool. Regulatory reporting deadlines that constrain transition timing. Architecture team capacity limited to one lead architect and two domain architects for the first cycle.
Acceptance criteria. Phase A is complete when the Architecture Vision and Statement of Architecture Work have been reviewed and approved by the governance forum, the sponsor has confirmed the resource commitment, and the repository contains the versioned opening pack (boundary statement, stakeholder map, principle set, scenario, scope statement, vision, and work statement).
The early London pack is coherent only if the vision and work statement reinforce one another. Phase A should leave the team authorised to continue, not merely inspired to continue.
A Statement of Architecture Work lists twelve deliverables across all four architecture domains but does not name any exclusions. What risk does this create?
The Architecture Vision for a retail bank says: 'We will become a digital-first bank.' The lead architect argues this is not yet a working vision. Why?
C220 lists 'assess readiness for business transformation' as a Phase A step (not one of the two Phase A objectives). Why does this step matter?
Core distinctions
- Phase A has two objectives in C220: develop the aspirational Architecture Vision, and obtain approval for a Statement of Architecture Work. The Phase A steps, from stakeholder identification through principles, the vision itself, measurable value propositions, transformation risk mitigation, and the work statement, exist to deliver those two objectives.
- The Architecture Vision explains direction and value. The Statement of Architecture Work defines the commissioned architecture effort. Both must exist and reinforce each other.
- The Architecture Vision should contain: problem description, stakeholder map, business drivers, scope, principles, high-level direction, risks, and value proposition.
- The Statement of Architecture Work should contain: project description, scope and exclusions, method, deliverables, roles, schedule, governance, constraints, and acceptance criteria.
- Strong Phase A work is traceable backwards to concerns and evidence and forwards to deliverables and review points.
- A polished vision cannot compensate for a weak work statement. Phase A should end with authorised, governable work, not only with persuasive prose.
Standards and sources cited in this module
The TOGAF Standard, 10th Edition (C220)
Architecture Development Method: Phase A (objectives and steps)
The core standard for Phase A, including the Architecture Vision, the Statement of Architecture Work, the two Phase A objectives, and the Phase A steps.
Full guide
Connecting scenario outputs to the vision, ensuring the Architecture Vision is grounded in real enterprise problems.
G184, Leader's Guide to Establishing and Evolving an EA Capability
Full guide
Capability context for the work statement, including governance and sponsorship arrangements that the Statement of Architecture Work must reference.
G186, Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM
Full guide
Practical Phase A guidance, including how to produce a vision and work statement that can survive real governance review.
G249, Architecture Roles and Skills
Full guide
Roles context for Phase A governance, including who should review and approve the Statement of Architecture Work.
You now understand how the Architecture Vision and Statement of Architecture Work turn direction into a governable commission. The final Stage 2 question is: how do all these techniques come together in one coherent kickoff pack for the London case? That is Module 15.
Module 14 of 72 · Preliminary Phase and Architecture Vision