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.
Document control
| 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
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
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
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
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
| 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
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
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.
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.
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
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
| 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
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
| 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
| 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
| 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
The Architecture Board and sponsor are asked to:
- Approve the scope in section 4 and the principles emphasis in section 5.
- Accept the KPIs in section 7.2 as the measures of success.
- Accept the residual risks in section 8 or direct further mitigation.
- 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
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.