# Architecture Vision: [Architecture engagement name]

> Architecture Vision and Statement of Architecture Work for one
> architecture engagement, the main outputs of Phase A of the Architecture
> Development Method (ADM) in The TOGAF Standard, 10th Edition (2025
> Update). It summarises the Request for Architecture Work, maps
> stakeholders and their concerns, states goals, drivers, scope and
> constraints, sketches the baseline and target, sets the value case and
> KPIs, assesses risk and capability, and closes with the agreed Statement
> of Architecture Work. Replace every `[bracketed]` value and every row
> marked *Example*.

<!--
Guidance: How to use this template
- Phase A answers three questions before any detailed design: why are we
  doing this, what will be different afterwards, and how will the
  architecture work be run. Keep the vision short enough that a sponsor
  reads it in one sitting.
- Work in this order: 1 (request) -> 2 (stakeholders) -> 3 (goals,
  drivers, constraints) -> 4 (scope) -> 6 and 7 (baseline, target, value)
  -> 8 and 9 (risk, capability) -> 10 (Statement of Architecture Work).
  Section 10 is the contract for the engagement; do not sign it before the
  scope in section 4 is stable.
- The detailed domain architectures belong in the Architecture Definition
  Document (`architecture/architecture-definition-document`), the
  sequencing in the roadmap (`architecture/architecture-roadmap-transition`).
- The worked example follows one fictional insurer through the whole set,
  so IDs (DRV, BG, GAP, WP) line up across the four TOGAF templates.
-->

## Document control

<!-- Guidance: Identify the vision as an ADM deliverable of one engagement. Link the Request for Architecture Work it answers and the repository location where it is stored. -->

| Field | Value |
|---|---|
| Document ID | [AV-ENG-001] |
| Engagement | [Architecture engagement name] |
| ADM phase | Phase A: Architecture Vision |
| Request for Architecture Work | [RAW-YYYY-NN] |
| Architecture level | [Strategic / Segment / Capability] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner (lead architect) | [@lead-architect] |
| Sponsor | [@sponsor] |
| Approvers / reviewers | [Architecture Board, sponsor, domain architects] |
| Classification | [Internal / Confidential] |
| Repository location | [Architecture Repository path or ID] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Conditions | Date |
|---|---|---|---|---|
| Sponsor | [@sponsor] | [Approved / Approved with conditions / Rejected] | [Conditions] | YYYY-MM-DD |
| Architecture Board chair | [@chair] | [Decision] | [Conditions] | YYYY-MM-DD |
| Lead architect | [@lead-architect] | [Decision] | [Conditions] | YYYY-MM-DD |
| Finance partner | [@finance] | [Decision] | [Conditions] | YYYY-MM-DD |
| Security architect | [@security] | [Decision] | [Conditions] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Request summary, stakeholder map, first draft of goals and scope |
| 0.5 | YYYY-MM-DD | [@name] | *Example:* Value case, risks and capability assessment added; pre-review with sponsor |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by Architecture Board (outcome record ARB-2026-029) with condition C1 |

## Contents

1. [Request for Architecture Work summary](#1-request-for-architecture-work-summary)
2. [Stakeholders and concerns](#2-stakeholders-and-concerns)
3. [Business goals, drivers and constraints](#3-business-goals-drivers-and-constraints)
4. [Scope of the architecture](#4-scope-of-the-architecture)
5. [Architecture principles](#5-architecture-principles)
6. [Baseline and target summary](#6-baseline-and-target-summary)
7. [Value proposition and KPIs](#7-value-proposition-and-kpis)
8. [Risks and mitigations](#8-risks-and-mitigations)
9. [Capability and readiness assessment](#9-capability-and-readiness-assessment)
10. [Statement of Architecture Work](#10-statement-of-architecture-work)
11. [Communications plan](#11-communications-plan)
12. [Decisions requested and next steps](#12-decisions-requested-and-next-steps)
13. [Glossary and references](#13-glossary-and-references)

## 1. Request for Architecture Work summary

<!-- Guidance: Restate the request that triggered the engagement in a few lines, so readers do not need to find the original. Note where the vision deliberately differs from the request and why. Pitfall: treating the request as the scope; Phase A often narrows or reframes it. -->

The Request for Architecture Work is the sponsor's formal ask that starts
an ADM cycle. Summarise it here; keep the original in the repository.

| Field | Value |
|---|---|
| Request ID | [RAW-YYYY-NN] |
| Requested by | [@sponsor, business unit] |
| Date received | YYYY-MM-DD |
| Problem or opportunity | *Example:* Claims customers wait 11 days on average for a decision; three policy systems hold conflicting customer records |
| Requested outcome | *Example:* A target architecture and roadmap for digital claims and a single customer view within 24 months |
| Budget envelope | *Example:* Up to USD 2.5 million capital over two financial years |
| Requested by date | YYYY-MM-DD |
| Known constraints | *Example:* Policy administration contract renews in 18 months; no new on-premises hardware |
| Related strategy | [Strategy or plan name, version] |

### 1.1 Differences from the request

State plainly where this vision changes the ask. *Example:* the request
named a CRM replacement as the solution; Phase A reframes it as a customer
data problem and leaves the product choice to Phase E, because the
stakeholder interviews showed the pain is inconsistent data, not missing
CRM features.

## 2. Stakeholders and concerns

<!-- Guidance: List everyone who can block, fund, use or be harmed by the change. For each, record the concerns the architecture must address and how you will engage them. Pitfall: listing only IT stakeholders; Phase A is a business conversation. -->

### 2.1 Stakeholder register

| ID | Stakeholder | Role | Key concerns | Power | Interest | Engagement |
|---|---|---|---|---|---|---|
| SH-01 *(Example)* | Chief Operating Officer | Sponsor | Claims cycle time, operating cost | High | High | Manage closely: monthly steering |
| SH-02 *(Example)* | Head of Claims | Business owner | Staff productivity, customer complaints | High | High | Manage closely: weekly working session |
| SH-03 *(Example)* | Chief Information Security Officer | Assurance | Personal data protection, third-party risk | High | Medium | Keep satisfied: review at each gate |
| SH-04 *(Example)* | Data Protection Officer | Assurance | Lawful basis, retention, data subject rights | Medium | High | Keep informed: privacy checkpoints |
| SH-05 *(Example)* | Head of IT Operations | Delivery | Supportability, run cost, skills | Medium | High | Keep informed: architecture reviews |
| SH-06 *(Example)* | Claims handlers | Users | Fewer screens, fewer re-keyed fields | Low | High | Keep informed: user research, demos |
| SH-07 *(Example)* | Policyholders | Customers | Speed, transparency, channel choice | Low | High | Represented by customer research |
| [SH-nn] | [Stakeholder] | [Role] | [Concerns] | [High / Medium / Low] | [High / Medium / Low] | [Approach] |

### 2.2 Stakeholder map

```mermaid
flowchart TB
  subgraph HP["High power"]
    direction LR
    KS["Keep satisfied<br/>SH-03 CISO"]
    MC["Manage closely<br/>SH-01 COO, SH-02 Head of Claims"]
  end
  subgraph LP["Lower power"]
    direction LR
    MO["Monitor<br/>Regulator liaison"]
    KI["Keep informed<br/>SH-04 DPO, SH-05 IT Ops, SH-06 handlers, SH-07 customers"]
  end
  KS --- MC
  MO --- KI
```

The left column holds lower interest, the right column higher interest.
Revisit the map at each phase gate; people move as the work becomes real.

### 2.3 Concerns to viewpoints

Each concern must be addressed by at least one view in the Architecture
Definition Document. Record the intended view now so nothing is forgotten.

| Concern ID | Concern | Raised by | Addressed in (planned view) |
|---|---|---|---|
| CON-01 *(Example)* | How fast can a claim be decided end to end? | SH-01, SH-02 | Business process view, value stream view |
| CON-02 *(Example)* | Where is customer personal data stored and who can see it? | SH-03, SH-04 | Data entity and location view |
| CON-03 *(Example)* | What does the target cost to run each year? | SH-01, SH-05 | Technology view with cost overlay |
| CON-04 *(Example)* | How many systems does a handler touch per claim? | SH-06 | Application usage view |
| [CON-nn] | [Concern] | [SH-nn] | [View] |

## 3. Business goals, drivers and constraints

<!-- Guidance: Drivers are the external or internal forces; goals are what the enterprise wants to achieve in response; constraints are what limits the options. Make every goal measurable so section 7 can set KPIs against it. Pitfall: writing solutions as goals ("implement a data hub"). -->

### 3.1 Business drivers

| ID | Driver | Type | Source |
|---|---|---|---|
| DRV-01 *(Example)* | Competitors settle simple claims in under 48 hours | Market | Customer research YYYY |
| DRV-02 *(Example)* | Supervisory expectations on operational resilience of outsourced IT | Regulatory | Regulator letter YYYY-MM-DD |
| DRV-03 *(Example)* | End of vendor support for the legacy CRM | Technology | Vendor notice |
| DRV-04 *(Example)* | Operating cost per claim above industry median | Financial | Benchmark study YYYY |
| [DRV-nn] | [Driver] | [Market / Regulatory / Financial / Technology / Social] | [Source] |

### 3.2 Business goals and objectives

| Goal ID | Goal | Objective (measurable) | Driver |
|---|---|---|---|
| BG-01 *(Example)* | Faster claims decisions | Decide 70% of simple claims within 48 hours by YYYY-MM | DRV-01 |
| BG-02 *(Example)* | One trusted view of the customer | One golden customer record per person across all policy lines by YYYY-MM | DRV-01, DRV-03 |
| BG-03 *(Example)* | Lower cost to serve | Reduce operating cost per claim by 20% against the YYYY baseline | DRV-04 |
| BG-04 *(Example)* | Resilient outsourced services | Documented exit plan and tested recovery for every critical third-party service | DRV-02 |
| [BG-nn] | [Goal] | [Objective with number and date] | [DRV-nn] |

### 3.3 Constraints

| ID | Constraint | Type | Impact on options |
|---|---|---|---|
| CNS-01 *(Example)* | Capital budget capped at USD 2.5 million | Financial | Favours incremental replacement over big-bang |
| CNS-02 *(Example)* | Customer personal data must remain in the EU | Legal | Limits hosting regions and support locations |
| CNS-03 *(Example)* | Policy administration contract renewal date YYYY-MM-DD | Contractual | Sets the latest date for the replatform decision |
| CNS-04 *(Example)* | Claims operations freeze during the year-end peak | Operational | No cut-overs in [month] |
| [CNS-nn] | [Constraint] | [Financial / Legal / Contractual / Operational / Technical] | [Impact] |

### 3.4 Assumptions

| ID | Assumption | Owner | Validate by |
|---|---|---|---|
| ASM-01 *(Example)* | The existing cloud landing zone is approved for confidential data | [@platform-lead] | YYYY-MM-DD |
| ASM-02 *(Example)* | Claims staff are available two days per sprint for design work | [@head-of-claims] | YYYY-MM-DD |
| [ASM-nn] | [Assumption] | [@owner] | YYYY-MM-DD |

## 4. Scope of the architecture

<!-- Guidance: Scope has several dimensions: breadth (which parts of the enterprise), depth (level of detail), time horizon, and architecture domains. State what is out of scope as clearly as what is in. Pitfall: a scope so wide that Phase B to D cannot finish in the agreed time. -->

| Dimension | In scope | Out of scope |
|---|---|---|
| Enterprise breadth | *Example:* Retail motor and home claims, all EU markets | Commercial lines, life products |
| Business capabilities | *Example:* Claims intake, assessment, settlement; customer management | Underwriting, reinsurance |
| Architecture domains | *Example:* Business, data, application, technology | Physical facilities |
| Depth | *Example:* Capability and logical application level; physical design only for integration | Detailed solution design (left to projects) |
| Time horizon | *Example:* Baseline as of YYYY-MM; target for YYYY-MM (24 months) | Beyond 36 months |
| Partners | *Example:* Repair network and loss adjusters at interface level | Partner internal systems |
| [Dimension] | [In scope] | [Out of scope] |

### 4.1 Architecture partitioning

If this engagement is one segment of a larger landscape, name the
enterprise or strategic architecture it must conform to, and the
neighbouring segments it must not overlap. *Example:* this segment
conforms to the group strategic architecture SA-2026 and shares the
customer domain with the parallel distribution segment; the customer data
model is owned here and reused there.

## 5. Architecture principles

<!-- Guidance: Reference the principles catalogue rather than copying it. Highlight the principles most at stake in this engagement and any that are already known to be in tension. Pitfall: inventing engagement-specific principles that conflict with the enterprise set. -->

The enterprise principles are maintained in the Architecture Principles
Catalogue (`architecture/architecture-principles`). The table lists the
principles that will shape the options most strongly here.

| Principle ID | Name | Why it matters for this engagement | Expected tension |
|---|---|---|---|
| BP-02 *(Example)* | Reuse before buy before build | Several claims products already exist in the portfolio | Business preference for a bespoke portal |
| DP-01 *(Example)* | Data has one accountable owner and one master source | The core of goal BG-02 | Three policy systems each claim mastery today |
| AP-01 *(Example)* | Integrate through published interfaces | Removes point-to-point file transfers | Legacy policy system offers no APIs |
| TP-01 *(Example)* | Prefer managed services on approved platforms | Lowers run cost (BG-03) | Data residency constraint CNS-02 |
| SP-01 *(Example)* | Secure by default, least privilege always | Personal and health data in claims | Partner access for loss adjusters |
| [ID] | [Name] | [Relevance] | [Tension] |

Any principle that cannot be met is handled through a dispensation under
the Architecture Board charter (`architecture/architecture-governance-charter`).

## 6. Baseline and target summary

<!-- Guidance: A high-level sketch only, enough to show the size of the change and win agreement on direction. One diagram for each state plus a short narrative. The full baseline and target per domain belong in the Architecture Definition Document. Pitfall: detailing the target so far that Phase B to D become rubber stamps. -->

### 6.1 Baseline (current state)

*Example:* Claims are registered by phone or e-mail into the claims system,
re-keyed into one of three policy systems to check cover, and paid through
the finance system. Customer details are held separately in each policy
system and in the legacy CRM, with nightly file transfers between them.

```mermaid
flowchart LR
  CUST(["Policyholder"]) -->|phone, e-mail| CH["Claims handler"]
  CH --> CLM["Claims system"]
  CH --> PA1["Policy system A"]
  CH --> PA2["Policy system B"]
  CH --> PA3["Policy system C"]
  CLM -->|nightly file| FIN["Finance"]
  PA1 -.->|nightly file| CRM["Legacy CRM"]
  PA2 -.->|nightly file| CRM
  PA3 -.->|nightly file| CRM
```

### 6.2 Target (future state)

*Example:* Policyholders register claims online or through partners;
simple claims are triaged and decided automatically against one customer
and policy view served by a customer data hub through published APIs.
Handlers work complex claims in a single workspace.

```mermaid
flowchart LR
  CUST(["Policyholder"]) --> PORTAL["Digital claims portal"]
  PARTNER(["Repair partner"]) --> API["API gateway"]
  PORTAL --> API
  API --> CLM["Claims platform with triage rules"]
  API --> CDH[("Customer data hub")]
  CLM --> CDH
  CLM --> FIN["Finance"]
  CH["Claims handler"] --> WS["Handler workspace"] --> API
  CDH <-->|events| PAS["Policy administration"]
```

### 6.3 Size of the change

| Domain | Change summary | Indicative gap IDs |
|---|---|---|
| Business | *Example:* New straight-through decision path for simple claims; role change for handlers | GAP-B-01, GAP-B-02 |
| Data | *Example:* Golden customer record; retire three local customer stores | GAP-D-01 |
| Application | *Example:* Portal, handler workspace and data hub new; legacy CRM eliminated | GAP-A-01, GAP-A-02 |
| Technology | *Example:* API gateway and event streaming on the managed cloud platform | GAP-T-01 |

## 7. Value proposition and KPIs

<!-- Guidance: Explain the benefit to each major stakeholder group in their own terms, then set KPIs that can be measured before and after. Every KPI needs a baseline, a target, a date, an owner and a data source. Pitfall: KPIs that only measure delivery ("portal live") instead of outcomes. -->

### 7.1 Value proposition

| Stakeholder | Value delivered | Goal |
|---|---|---|
| *Example:* Policyholders | Simple claims decided in two days instead of eleven; status visible online | BG-01 |
| *Example:* Claims handlers | One workspace instead of five systems; no re-keying | BG-01, BG-03 |
| *Example:* COO | Lower cost per claim; resilient services with tested exit plans | BG-03, BG-04 |
| *Example:* DPO | Known location and owner for every customer data element | BG-02 |
| [Stakeholder] | [Value] | [BG-nn] |

### 7.2 Key performance indicators

| KPI ID | KPI | Baseline | Target | Date | Data source | Owner |
|---|---|---|---|---|---|---|
| KPI-01 *(Example)* | Share of simple claims decided within 48 hours | 12% | 70% | YYYY-MM | Claims platform reports | [@head-of-claims] |
| KPI-02 *(Example)* | Customer records with a single golden ID | 0% | 98% | YYYY-MM | Data hub quality dashboard | [@data-owner] |
| KPI-03 *(Example)* | Operating cost per claim | USD 140 | USD 112 | YYYY-MM | Finance cost model | [@finance] |
| KPI-04 *(Example)* | Critical third-party services with tested exit plan | 1 of 6 | 6 of 6 | YYYY-MM | Third-party register | [@risk-owner] |
| [KPI-nn] | [KPI] | [Baseline] | [Target] | YYYY-MM | [Source] | [@owner] |

Track realisation after delivery in the benefits plan
(`project/benefits-realization-plan`); the business case itself belongs in
`business/business-case`.

## 8. Risks and mitigations

<!-- Guidance: Phase A risks are about the transformation as a whole: will the business adopt it, can it be funded, is the timeline credible. Record the risk before and after mitigation so the board sees the residual exposure it is accepting. Pitfall: listing technical risks that belong in a project RAID log. -->

| Risk ID | Risk | Likelihood | Impact | Mitigation | Residual | Owner |
|---|---|---|---|---|---|---|
| RSK-01 *(Example)* | Policy administration vendor cannot deliver APIs before contract renewal | Medium | High | Run an API proof of concept in month 3; prepare replatform option | Medium | [@lead-architect] |
| RSK-02 *(Example)* | Handlers resist automated decisions | Medium | Medium | Co-design triage rules with handlers; publish override statistics | Low | [@head-of-claims] |
| RSK-03 *(Example)* | Data quality in policy system C too poor to match | High | High | Profile data in Phase C; budget a cleansing work package | Medium | [@data-owner] |
| RSK-04 *(Example)* | Competing programmes take the same integration team | Medium | High | Reserve capacity through the portfolio board | Medium | [@sponsor] |
| [RSK-nn] | [Risk] | [H / M / L] | [H / M / L] | [Mitigation] | [H / M / L] | [@owner] |

Use the enterprise risk method (`compliance/risk-methodology`) for the
scales, and carry open items into the project RAID log
(`project/raid-log`).

## 9. Capability and readiness assessment

<!-- Guidance: Assess two things: the business capabilities that must change, and the enterprise's readiness to make the change (including the architecture team itself). Rate honestly; a low readiness score is a reason to change the plan, not to hide the score. Pitfall: scoring only technology maturity. -->

### 9.1 Business capabilities affected

| Capability | Current maturity (1 to 5) | Target maturity | Change needed |
|---|---|---|---|
| *Example:* Claims intake | 2 | 4 | Digital and partner channels, structured data at first contact |
| *Example:* Claims assessment | 3 | 4 | Rule-based triage, automated cover check |
| *Example:* Customer information management | 2 | 4 | Golden record, ownership, quality monitoring |
| *Example:* Partner management | 3 | 3 | Interface changes only |
| [Capability] | [1 to 5] | [1 to 5] | [Change] |

The enterprise capability model is maintained in the Business Capability
Map (`architecture/business-capability-map`); use the same capability names.

### 9.2 Transformation readiness

| Factor | Rating (1 to 5) | Evidence | Action if low |
|---|---|---|---|
| *Example:* Vision clarity and sponsor commitment | 4 | Sponsor chairs steering; budget ring-fenced | Not required |
| *Example:* Business ability to absorb change | 2 | Claims team also runs a regulatory remediation | Phase the rollout by claim type |
| *Example:* Delivery capacity and skills | 3 | Integration skills scarce | Partner for API work; train two engineers |
| *Example:* Data readiness | 2 | Duplicate rate above 15% in one source | Data quality work package early |
| *Example:* Funding certainty | 4 | Year 1 approved, year 2 indicative | Gate year 2 on KPI-01 progress |
| [Factor] | [1 to 5] | [Evidence] | [Action] |

### 9.3 Architecture capability for this engagement

| Aspect | Current state | Gap and action |
|---|---|---|
| *Example:* Architecture team | Lead architect plus one data architect | Add a part-time security architect |
| *Example:* Repository and tooling | Modelling tool in place; no claims domain models | Model baseline in the first four weeks |
| *Example:* Governance | Architecture Board meets monthly | Add an extra review at the end of Phase C |
| [Aspect] | [Current state] | [Action] |

## 10. Statement of Architecture Work

<!-- Guidance: The Statement of Architecture Work is the agreement between the sponsor and the architecture team on what will be produced, how, by whom, by when and how acceptance is judged. Write it so that a third party could tell whether it was fulfilled. Pitfall: acceptance criteria that cannot be tested ("architecture is fit for purpose"). -->

| Field | Value |
|---|---|
| Statement ID | [SAW-YYYY-NN] |
| Answers request | [RAW-YYYY-NN] |
| Engagement period | YYYY-MM-DD to YYYY-MM-DD |
| Approved budget for architecture work | [USD amount] |

### 10.1 Scope of the work

The work covers the scope in section 4 and the ADM phases listed here.
Phases G and H will run under the Architecture Board once implementation
starts.

| ADM phase | In this engagement | Main output |
|---|---|---|
| Phase A: Architecture Vision | Yes | This document |
| Phase B: Business Architecture | Yes | Business part of the Architecture Definition Document |
| Phase C: Information Systems Architectures | Yes (data and application) | Data and application parts of the Architecture Definition Document |
| Phase D: Technology Architecture | Yes | Technology part of the Architecture Definition Document |
| Phase E: Opportunities and Solutions | Yes | Work packages and Transition Architectures |
| Phase F: Migration Planning | Yes | Architecture Roadmap, Implementation and Migration Plan |
| Phase G: Implementation Governance | Hand-off | Architecture Contracts, compliance reviews |
| Phase H: Architecture Change Management | Hand-off | Change process under the board |
| Requirements Management | Continuous | Architecture Requirements Specification |

### 10.2 Approach and tailoring

[Describe how the ADM is tailored for this engagement: iterations, depth
per domain, techniques used and any agile cadence.] *Example:* two
iterations of Phases B to D (a two-week outline pass, then a six-week
detailed pass), business scenarios for claims journeys, gap analysis per
domain, and a fortnightly demo of models to the claims team.

### 10.3 Roles and responsibilities

| Role | Name | Responsibility | Time commitment |
|---|---|---|---|
| Sponsor | [@sponsor] | Owns the outcome; resolves business conflicts; signs acceptance | 2 hours per month |
| Lead architect | [@lead-architect] | Owns all deliverables and the plan | Full time |
| Business architect | [@name] | Phase B models and business scenarios | Full time, weeks 1 to 8 |
| Data architect | [@name] | Phase C data models and quality assessment | 50% |
| Application architect | [@name] | Phase C application models and portfolio impact | 50% |
| Technology architect | [@name] | Phase D platform and integration | 50%, weeks 5 to 12 |
| Security architect | [@name] | Security and privacy requirements across domains | 20% |
| Architecture Board | [Chair @name] | Reviews at the gates in section 10.4 | Scheduled reviews |

Use a RACI (`business/raci`) if more detail is needed.

### 10.4 Plan and milestones

```mermaid
gantt
  title Architecture engagement plan (Example)
  dateFormat YYYY-MM-DD
  section Vision
  Phase A vision and statement      :a1, 2026-09-14, 3w
  Board gate 1                      :milestone, m1, after a1, 0d
  section Definition
  Phases B to D outline pass        :b1, after a1, 2w
  Phases B to D detailed pass       :b2, after b1, 6w
  Board gate 2                      :milestone, m2, after b2, 0d
  section Planning
  Phases E and F roadmap            :e1, after b2, 4w
  Board gate 3 and hand-off         :milestone, m3, after e1, 0d
```

| Milestone | Deliverable | Planned date | Gate |
|---|---|---|---|
| M1 *(Example)* | Architecture Vision and this Statement approved | YYYY-MM-DD | Board gate 1 |
| M2 *(Example)* | Architecture Definition Document and Architecture Requirements Specification approved | YYYY-MM-DD | Board gate 2 |
| M3 *(Example)* | Architecture Roadmap and Implementation and Migration Plan approved | YYYY-MM-DD | Board gate 3 |
| [Mn] | [Deliverable] | YYYY-MM-DD | [Gate] |

### 10.5 Acceptance criteria

| ID | Criterion | Evidence |
|---|---|---|
| ACC-01 *(Example)* | Every concern in section 2.3 is addressed by at least one named view | Concern to view table in the Architecture Definition Document |
| ACC-02 *(Example)* | Every gap is assigned to a work package with an owner | Consolidated gaps table in the roadmap |
| ACC-03 *(Example)* | Each KPI in section 7.2 has an agreed baseline measurement | Signed baseline report |
| ACC-04 *(Example)* | Security and privacy architects sign off the target data architecture | Approval record |
| [ACC-nn] | [Criterion] | [Evidence] |

### 10.6 Change to this statement

Changes to scope, budget or dates of more than [10%] require the
sponsor's approval and a new version of this section. Smaller changes are
agreed by the lead architect and recorded in the revision history.

## 11. Communications plan

<!-- Guidance: Plan how each stakeholder group hears about the work, in which format and how often. Match the channel to the stakeholder's power and interest from section 2. Pitfall: one monthly status e-mail to everyone. -->

| Audience | Message | Channel | Frequency | Owner |
|---|---|---|---|---|
| *Example:* Sponsor and steering | Progress, decisions needed, risks | Steering meeting | Monthly | [@lead-architect] |
| *Example:* Claims team | Journey designs, demos, feedback | Show and tell | Fortnightly | [@business-architect] |
| *Example:* IT operations | Platform choices, run impact | Architecture review | At each gate | [@technology-architect] |
| *Example:* Whole organisation | Why the change, what it means for staff | Intranet article | Quarterly | [@communications] |
| [Audience] | [Message] | [Channel] | [Frequency] | [@owner] |

## 12. Decisions requested and next steps

<!-- Guidance: Tell the approvers exactly what they are being asked to decide today, and what happens next if they agree. Pitfall: asking for approval of "the vision" without naming the budget or scope consequences. -->

The Architecture Board and sponsor are asked to:

1. Approve the scope in section 4 and the principles emphasis in section 5.
2. Accept the KPIs in section 7.2 as the measures of success.
3. Accept the residual risks in section 8 or direct further mitigation.
4. Approve the Statement of Architecture Work in section 10, including
   the budget and the three board gates.

On approval, the team starts Phases B to D and records results in the
Architecture Definition Document. Significant decisions made along the way
are captured as architecture decision records (`architecture/adr-full`).

## 13. Glossary and references

<!-- Guidance: Define terms the sponsor may not know and list every source used. -->

### 13.1 Glossary

| Term | Meaning in this document |
|---|---|
| ADM | Architecture Development Method, the iterative method at the centre of the TOGAF Standard |
| Architecture Vision | Phase A deliverable that describes the intended outcome and value at a high level |
| Request for Architecture Work | The sponsor's formal request that starts an architecture engagement |
| Statement of Architecture Work | The agreement on scope, approach, plan and acceptance of the architecture work |
| Baseline | The architecture as it exists at the start of the engagement |
| Target | The architecture the enterprise intends to reach at the end of the time horizon |
| Capability | What the business does or can do, independent of who does it and how |
| [Term] | [Meaning] |

### 13.2 References

| ID | Reference | Version / date |
|---|---|---|
| REF-01 | The TOGAF Standard, 10th Edition (The Open Group), 2025 Update | June 2025 |
| REF-02 | Architecture Principles Catalogue (`architecture/architecture-principles`) | [x.y] |
| REF-03 | Business Capability Map (`architecture/business-capability-map`) | [x.y] |
| REF-04 | Architecture Definition Document (`architecture/architecture-definition-document`) | [x.y] |
| REF-05 | Architecture Roadmap and Transition Architectures (`architecture/architecture-roadmap-transition`) | [x.y] |
| REF-06 | Architecture Board Charter (`architecture/architecture-governance-charter`) | [x.y] |
| REF-07 | [Corporate strategy or business plan] | [x.y] |

## Standard and licence note

Structure aligned with The TOGAF Standard, 10th Edition (2025 Update),
published by The Open Group: Phase A of the Architecture Development
Method and its outputs (Architecture Vision, Statement of Architecture
Work, Communications Plan, Capability Assessment), answering a Request for
Architecture Work. Only phase and deliverable names are used; this template
is original text and reproduces no definitions, tables or other text from
the standard. TOGAF is a registered trademark of The Open Group. Check the
current edition and any technical corrigenda at opengroup.org and obtain
the standard for its full guidance. Template licence: MIT.