Architecture Vision and the Statement of Architecture Work

C220 Part 2 sets out specific objectives for Phase A. Each one addresses a risk that will undermine the ADM cycle if it is left unresolved. Here is the complete set, with a plain-language explanation of what each objective is really asking the team to do.

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 stakeholders 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.

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.

3. Define what is in scope and what is out of 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 objective addresses is scope creep: the gradual expansion of the architecture effort until it becomes unmanageable and loses credibility.

4. Identify stakeholders, concerns, and business requirements. The team must map the concerns 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 objective addresses is an architecture that solves the wrong problems because it was not grounded in real stakeholder needs.

5. 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 business scenario from Module 11 provides the primary evidence for this objective. The risk is an architecture effort that is internally consistent but disconnected from the enterprise situation that justifies it.

6. Evaluate business capabilities. Phase A should assess the current state of relevant business capabilities 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.

7. 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.

8. Define the Architecture Vision. This is the formal output: a document that articulates the direction, value proposition, 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.

These objectives are not a checklist to be completed mechanically. They represent the questions that Phase A must answer. If any one remains unanswered, the architecture effort starts the detailed design phases on unstable ground.

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 stakeholder 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 governance 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 artefacts 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.

TOGAF C220 describes the Architecture Vision as a deliverable 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 business scenario 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 principles 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 target architecture, 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. This section explains 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.

The Statement of Architecture Work 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 governance forum knows what process is being followed.

5. Deliverables, artefacts, and building blocks. A list of the specific deliverables, artefacts, and building blocks 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 Architecture Board or review forum, the frequency of reviews, the escalation path for disputes, and the compliance and exception 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.

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 traceability means 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 Phase C deliverable that corresponds to that commitment. If the work statement excludes technology infrastructure, that exclusion should appear in the Phase D 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.

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 six principles from Module 10, including "One published truth per data item per date" and "No operational change without documented rollback." 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 to meet the regulatory target protects London Grid's regulatory standing and public reputation. Establishing a single authoritative data source eliminates contradictory publications. Governed resilience across OT, IT, and telecoms reduces the risk of operational incidents during the transition.

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, OT/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 value stream 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 repository 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 CIM 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.