# Architecture Definition Document: [Architecture engagement name]

> Architecture Definition Document for one engagement, covering the
> Business, Data, Application and Technology Architecture domains
> developed in Phases B, C and D of the Architecture Development Method in
> The TOGAF Standard, 10th Edition (2025 Update). For each domain it
> records the baseline, the target, a gap analysis and the candidate
> roadmap components, then summarises the Architecture Requirements
> Specification, interoperability, risks and traceability. Views use
> Mermaid stand-ins and can name ArchiMate viewpoints. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Start from the approved Architecture Vision
  (`architecture/togaf-architecture-vision`): reuse its stakeholder,
  concern, driver (DRV), goal (BG) and constraint (CNS) IDs.
- Work domain by domain in the same pattern: baseline, target, gaps,
  candidate roadmap components, views. Keep baseline and target at the
  same level of detail, otherwise the gaps are meaningless.
- Every gap gets an ID (GAP-B, GAP-D, GAP-A, GAP-T) and becomes an input to
  the consolidated gaps table in the roadmap
  (`architecture/architecture-roadmap-transition`).
- Mermaid diagrams are stand-ins for models held in the repository. Where
  you model in ArchiMate, name the viewpoint and link the model.
- For a single solution rather than an enterprise segment, the Solution
  Architecture Document (`architecture/solution-architecture`) is lighter.
-->

## Document control

<!-- Guidance: Identify the document as an ADM deliverable, the vision it elaborates and the iteration it reflects. Re-baseline it at each Architecture Board gate. -->

| Field | Value |
|---|---|
| Document ID | [ADD-ENG-001] |
| Engagement | [Architecture engagement name] |
| ADM phases | Phase B, Phase C, Phase D |
| Architecture Vision | [AV-ENG-001, version] |
| Statement of Architecture Work | [SAW-YYYY-NN] |
| Iteration | [Outline / Detailed] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner (lead architect) | [@lead-architect] |
| Approvers / reviewers | [Architecture Board, domain architects, security, data protection] |
| Classification | [Internal / Confidential] |
| Model repository | [Tool and model location] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Conditions | Date |
|---|---|---|---|---|
| Architecture Board chair | [@chair] | [Approved / Approved with conditions / Rejected] | [Conditions] | YYYY-MM-DD |
| Business architect | [@name] | [Decision] | [Conditions] | YYYY-MM-DD |
| Data architect | [@name] | [Decision] | [Conditions] | YYYY-MM-DD |
| Security architect | [@name] | [Decision] | [Conditions] | YYYY-MM-DD |
| Data protection officer | [@name] | [Decision] | [Conditions] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Outline pass: baselines and first target sketch for all four domains |
| 0.6 | YYYY-MM-DD | [@name] | *Example:* Detailed pass: gap matrices, requirements summary, traceability |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved at board gate 2 with condition C2 on data residency |

## Contents

1. [Introduction](#1-introduction)
2. [Drivers, principles and concerns](#2-drivers-principles-and-concerns)
3. [Business Architecture](#3-business-architecture)
4. [Data Architecture](#4-data-architecture)
5. [Application Architecture](#5-application-architecture)
6. [Technology Architecture](#6-technology-architecture)
7. [Cross-domain views](#7-cross-domain-views)
8. [Interoperability](#8-interoperability)
9. [Architecture Requirements Specification summary](#9-architecture-requirements-specification-summary)
10. [Options, trade-offs and risks](#10-options-trade-offs-and-risks)
11. [Traceability](#11-traceability)
12. [Candidate roadmap components](#12-candidate-roadmap-components)
13. [Glossary and references](#13-glossary-and-references)

## 1. Introduction

<!-- Guidance: Say what this document covers, which vision it elaborates and how readers should use it. Pitfall: repeating the vision; summarise and link instead. -->

### 1.1 Purpose

This document defines the baseline and target architectures for
[engagement] across the four architecture domains, the gaps between them
and the requirements that implementation projects must meet. It is the
basis for the Architecture Roadmap, for Architecture Contracts with
delivery teams, and for compliance reviews by the Architecture Board.

### 1.2 Scope recap

[One paragraph restating breadth, depth and time horizon from the vision.]
*Example:* retail motor and home claims and the customer domain, at
capability and logical application level, baseline as of YYYY-MM and
target for YYYY-MM.

### 1.3 Conventions

| Item | Convention |
|---|---|
| Gap IDs | GAP-B-nn (business), GAP-D-nn (data), GAP-A-nn (application), GAP-T-nn (technology) |
| Requirement IDs | ARS-BUS-nn, ARS-DAT-nn, ARS-APP-nn, ARS-TEC-nn, ARS-INT-nn |
| Candidate roadmap component IDs | CRC-nn |
| Gap types | Retained, Enhanced, Replaced, New, Eliminated |
| Diagrams | Mermaid stand-ins; authoritative models in [repository] |

## 2. Drivers, principles and concerns

<!-- Guidance: Pull forward only what this document must satisfy: the goals and drivers it serves, the principles that constrain it and the concerns each view answers. Pitfall: concerns with no view; every concern needs a home in sections 3 to 7. -->

| Item | Reference | Where addressed |
|---|---|---|
| *Example:* BG-01 Faster claims decisions | Vision section 3.2 | Sections 3.2, 5.2 |
| *Example:* BG-02 One trusted view of the customer | Vision section 3.2 | Sections 4.2, 5.2 |
| *Example:* BG-03 Lower cost to serve | Vision section 3.2 | Sections 5.3, 6.2 |
| *Example:* DP-01 One owner and one master source | Architecture principles | Section 4.2 |
| *Example:* AP-01 Integrate through published interfaces | Architecture principles | Sections 5.2, 8 |
| *Example:* CON-02 Where is customer personal data and who sees it | Vision section 2.3 | View V-D2 |
| [Goal, principle or concern] | [Source] | [Section or view] |

### 2.1 Views and viewpoints

| View ID | View | Viewpoint (ArchiMate name where used) | Concerns | Stakeholders |
|---|---|---|---|---|
| V-B1 *(Example)* | Claims value stream | Value Stream viewpoint | CON-01 | SH-01, SH-02 |
| V-B2 *(Example)* | Claims capability heat map | Capability Map viewpoint | CON-01, CON-03 | SH-01 |
| V-D1 *(Example)* | Core information structure | Information Structure viewpoint | CON-02 | SH-04 |
| V-D2 *(Example)* | Customer data location and ownership | Custom (data location) | CON-02 | SH-03, SH-04 |
| V-A1 *(Example)* | Target application cooperation | Application Cooperation viewpoint | CON-04 | SH-05, SH-06 |
| V-T1 *(Example)* | Platform and deployment | Technology Usage viewpoint | CON-03 | SH-05 |
| V-X1 *(Example)* | Layered overview | Layered viewpoint | All | SH-01, Board |
| [V-nn] | [View] | [Viewpoint] | [CON-nn] | [SH-nn] |

ArchiMate viewpoint names above follow the example viewpoints of the
ArchiMate Specification; check which version your tool supports (3.2 or
4) because names and element sets changed between them.

## 3. Business Architecture

<!-- Guidance: Phase B. Describe how the business works today and how it should work: capabilities, value streams, processes, organisation, roles and business services. Stay technology-neutral. Pitfall: describing screens or systems here; that is section 5. -->

### 3.1 Baseline Business Architecture

*Example:* claims are handled by a central team of 120 handlers organised
by product line. Intake is by phone and e-mail. Cover is checked manually
in one of three policy systems. Every claim, regardless of value, passes
through the same five-step process with two manual approvals.

| Element | Type | Owner | Observation |
|---|---|---|---|
| *Example:* Claims intake | Capability | Head of Claims | Phone and e-mail only; no structured data at first contact |
| *Example:* Claims assessment | Capability | Head of Claims | Manual cover check; same path for all claim sizes |
| *Example:* Product-line claims teams | Organisation unit | Head of Claims | Handlers cannot work across product lines |
| *Example:* Payment approval | Process | Finance | Two manual approvals regardless of amount |
| [Element] | [Capability / Value stream / Process / Organisation / Role / Service] | [@owner] | [Observation] |

### 3.2 Target Business Architecture

*Example:* simple claims (below a value threshold, no injury, cover
confirmed) follow a straight-through path decided by rules; complex claims
go to cross-product teams. Partners submit claims directly. Payment
approval depends on amount and risk score.

```mermaid
flowchart LR
  S1["Notify loss"] --> S2["Register claim"] --> S3["Triage"]
  S3 -->|simple| S4a["Automated decision"]
  S3 -->|complex| S4b["Handler assessment"]
  S4a --> S5["Settle and pay"]
  S4b --> S5
  S5 --> S6["Close and learn"]
```

View V-B1 (claims value stream, stand-in). Model the authoritative version
in the repository and keep the stage names identical to the capability
map (`architecture/business-capability-map`).

### 3.3 Business gap analysis

| Gap ID | Baseline element | Target element | Gap type | Description |
|---|---|---|---|---|
| GAP-B-01 *(Example)* | Single claims path | Triage with simple and complex paths | Replaced | New triage rules and decision authority for automated settlement |
| GAP-B-02 *(Example)* | Product-line teams | Cross-product complex-claims teams | Replaced | Organisation change; new skills matrix and training |
| GAP-B-03 *(Example)* | None | Partner claim submission | New | Partner agreements and service levels |
| GAP-B-04 *(Example)* | Two manual approvals | Risk-based approval | Enhanced | Delegated authority matrix updated |
| GAP-B-05 *(Example)* | Monthly paper reporting | Daily claims dashboard | Replaced | Management information from the new platform |
| [GAP-B-nn] | [Baseline] | [Target] | [Gap type] | [Description] |

### 3.4 Business candidate roadmap components

| CRC ID | Component | Closes gaps |
|---|---|---|
| CRC-01 *(Example)* | Claims triage rules and decision authority | GAP-B-01, GAP-B-04 |
| CRC-02 *(Example)* | Claims organisation redesign and training | GAP-B-02 |
| CRC-03 *(Example)* | Partner onboarding programme | GAP-B-03 |

## 4. Data Architecture

<!-- Guidance: Phase C, data part. Describe the main data entities, their owners, masters, quality and lifecycle, and where personal data lives. Pitfall: physical table designs; keep to logical entities and ownership. -->

### 4.1 Baseline Data Architecture

| Data entity | Master today | Copies | Owner | Quality issue |
|---|---|---|---|---|
| *Example:* Customer | None (three policy systems and CRM each hold one) | 4 | Unclear | 15% duplicates in system C |
| *Example:* Policy | Policy systems A, B, C | 1 each | Product owners | Inconsistent cover codes |
| *Example:* Claim | Claims system | Finance copy | Head of Claims | Free-text loss descriptions |
| *Example:* Payment | Finance system | None | Finance | Reliable |
| [Entity] | [Master] | [Count] | [@owner] | [Issue] |

### 4.2 Target Data Architecture

```mermaid
erDiagram
  CUSTOMER ||--o{ POLICY : holds
  POLICY ||--o{ CLAIM : covers
  CLAIM ||--o{ PAYMENT : settles
  CUSTOMER ||--o{ CONSENT : gives
  CLAIM ||--o{ DOCUMENT : evidences
  PARTNER ||--o{ CLAIM : submits
```

View V-D1 (core information structure, stand-in). *Example:* the customer
data hub is the master for customer identity and contact data; policy
administration remains master for policy; the claims platform is master
for claim, document and triage outcome.

| Data entity | Target master | Owner | Classification | Retention | Location |
|---|---|---|---|---|---|
| *Example:* Customer | Customer data hub | Head of Customer | Confidential (personal) | Policy end plus [n] years | EU region |
| *Example:* Claim | Claims platform | Head of Claims | Confidential (may include health data) | Claim close plus [n] years | EU region |
| *Example:* Document | Claims platform document store | Head of Claims | Confidential | As claim | EU region |
| [Entity] | [Master] | [@owner] | [Class] | [Rule] | [Region] |

Record full definitions in the data dictionary
(`architecture/data-dictionary`); keep this section at entity level.

### 4.3 Data gap analysis

| Gap ID | Baseline element | Target element | Gap type | Description |
|---|---|---|---|---|
| GAP-D-01 *(Example)* | Four customer stores, no master | Customer data hub as master | Replaced | Matching, merge and stewardship process |
| GAP-D-02 *(Example)* | Free-text loss data | Structured loss data model | Enhanced | Structured capture at intake |
| GAP-D-03 *(Example)* | No consent record | Consent entity in the hub | New | Consent capture and audit trail |
| GAP-D-04 *(Example)* | CRM customer store | None | Eliminated | Archive and decommission after migration |
| [GAP-D-nn] | [Baseline] | [Target] | [Gap type] | [Description] |

### 4.4 Data candidate roadmap components

| CRC ID | Component | Closes gaps |
|---|---|---|
| CRC-04 *(Example)* | Customer data hub with matching and stewardship | GAP-D-01, GAP-D-03 |
| CRC-05 *(Example)* | Data quality remediation for policy system C | GAP-D-01 |
| CRC-06 *(Example)* | Structured loss data model | GAP-D-02 |

## 5. Application Architecture

<!-- Guidance: Phase C, application part. Describe the application components, their responsibilities and how they cooperate. Name each application's fate in the target (keep, change, replace, retire). Pitfall: drawing products before agreeing responsibilities. -->

### 5.1 Baseline Application Architecture

| Application | Responsibility | Users | Integration style | Health |
|---|---|---|---|---|
| *Example:* Claims system | Claim registration and workflow | Handlers | Nightly files | Aging, supported |
| *Example:* Policy systems A, B, C | Policy administration | Underwriting, handlers | Screens, files | A and B supported; C end of life |
| *Example:* Legacy CRM | Customer contact history | Service desk | Nightly files | Vendor support ends YYYY-MM |
| *Example:* Finance system | Payments and ledger | Finance | Files | Healthy |
| [Application] | [Responsibility] | [Users] | [Style] | [Health] |

Portfolio-wide assessments of these applications live in the application
portfolio rationalization (`architecture/application-portfolio-rationalization`).

### 5.2 Target Application Architecture

```mermaid
flowchart LR
  PORTAL["Digital claims portal"] --> GW["API gateway"]
  WS["Handler workspace"] --> GW
  PARTNER["Partner channel"] --> GW
  GW --> CLM["Claims platform"]
  GW --> CDH["Customer data hub"]
  CLM --> RULES["Triage rules service"]
  CLM -->|payment request| FIN["Finance system"]
  CDH <-->|events| PAS["Policy administration"]
  CLM -->|events| BUS[["Event streaming"]]
  BUS --> MI["Claims dashboard"]
```

View V-A1 (target application cooperation, stand-in).

### 5.3 Application gap analysis

| Gap ID | Baseline element | Target element | Gap type | Description |
|---|---|---|---|---|
| GAP-A-01 *(Example)* | Claims system | Claims platform with triage rules | Replaced | New platform; workflow and rules configured |
| GAP-A-02 *(Example)* | None | Digital claims portal and partner channel | New | Customer and partner self-service |
| GAP-A-03 *(Example)* | Five handler screens | Handler workspace | New | Single workspace over APIs |
| GAP-A-04 *(Example)* | Legacy CRM | None | Eliminated | Functions absorbed by hub and workspace |
| GAP-A-05 *(Example)* | Policy system C | Policy administration (consolidated) | Replaced | Migrate policies to the consolidated system |
| [GAP-A-nn] | [Baseline] | [Target] | [Gap type] | [Description] |

### 5.4 Application candidate roadmap components

| CRC ID | Component | Closes gaps |
|---|---|---|
| CRC-07 *(Example)* | Claims platform and triage rules service, with claims dashboard | GAP-A-01, GAP-B-05 |
| CRC-08 *(Example)* | Portal, partner channel and handler workspace | GAP-A-02, GAP-A-03 |
| CRC-09 *(Example)* | Policy system C consolidation | GAP-A-05 |
| CRC-10 *(Example)* | Legacy CRM decommissioning | GAP-A-04, GAP-D-04 |

## 6. Technology Architecture

<!-- Guidance: Phase D. Describe the platforms, hosting, networks, integration infrastructure and operational services that the applications need. Tie every platform choice to a requirement or principle. Pitfall: listing products without saying which requirement they meet. -->

### 6.1 Baseline Technology Architecture

| Platform | Use | Hosting | Status |
|---|---|---|---|
| *Example:* On-premises virtualisation | Claims and policy systems | Own data centre | Lease ends YYYY-MM |
| *Example:* Managed file transfer | All integration | Own data centre | Single instance, no failover |
| *Example:* Cloud landing zone | Two analytics workloads | Public cloud, EU region | Approved for confidential data |
| [Platform] | [Use] | [Hosting] | [Status] |

### 6.2 Target Technology Architecture

```mermaid
flowchart TB
  subgraph CLOUD["Managed cloud, EU region"]
    GW["API gateway"]
    K8S["Container platform"]
    EVT[["Event streaming service"]]
    DB[("Managed databases")]
    OBS["Observability stack"]
  end
  subgraph DC["Own data centre (until exit)"]
    PAS["Policy administration"]
    FIN["Finance system"]
  end
  GW --> K8S
  K8S --> DB
  K8S --> EVT
  EVT <-->|private link| PAS
  K8S -->|private link| FIN
  K8S --> OBS
```

View V-T1 (platform and deployment, stand-in). Detailed landing zone and
network design belong in the infrastructure design
(`architecture/infrastructure-design`).

### 6.3 Technology gap analysis

| Gap ID | Baseline element | Target element | Gap type | Description |
|---|---|---|---|---|
| GAP-T-01 *(Example)* | Managed file transfer | API gateway and event streaming | Replaced | New integration platform; files retired per interface |
| GAP-T-02 *(Example)* | On-premises virtualisation for claims | Container platform in cloud | Replaced | Hosting move for claims and hub |
| GAP-T-03 *(Example)* | None | Private connectivity cloud to data centre | New | Network links with redundancy |
| GAP-T-04 *(Example)* | Per-system logging | Central observability | Enhanced | Shared logs, metrics and traces |
| [GAP-T-nn] | [Baseline] | [Target] | [Gap type] | [Description] |

### 6.4 Technology candidate roadmap components

| CRC ID | Component | Closes gaps |
|---|---|---|
| CRC-11 *(Example)* | Integration platform (gateway and events) | GAP-T-01 |
| CRC-12 *(Example)* | Cloud hosting and connectivity for claims domain | GAP-T-02, GAP-T-03 |
| CRC-13 *(Example)* | Observability onboarding | GAP-T-04 |

## 7. Cross-domain views

<!-- Guidance: Show how the domains fit together in one picture for executives and the board, and check that every target element in one domain is supported by the one below. Pitfall: a layered view that introduces elements not present in the domain sections. -->

```mermaid
flowchart TB
  subgraph BUS["Business"]
    C1["Claims intake"]
    C2["Claims assessment"]
    C3["Customer information management"]
  end
  subgraph APP["Application"]
    A1["Portal and partner channel"]
    A2["Claims platform and triage"]
    A3["Customer data hub"]
  end
  subgraph TEC["Technology"]
    T1["API gateway"]
    T2["Container platform"]
    T3["Event streaming"]
  end
  C1 --> A1
  C2 --> A2
  C3 --> A3
  A1 --> T1
  A2 --> T2
  A3 --> T2
  A2 --> T3
  A3 --> T3
```

View V-X1 (layered overview, stand-in for the Layered viewpoint).

### 7.1 Consistency checks

| Check | Result | Note |
|---|---|---|
| Every target capability is supported by at least one application | [Pass / Fail] | [Note] |
| Every target application has a hosting platform | [Pass / Fail] | [Note] |
| Every data entity has one master application | [Pass / Fail] | [Note] |
| Every eliminated element has a decommissioning component | [Pass / Fail] | [Note] |
| Every concern in section 2 is answered by a view | [Pass / Fail] | [Note] |

## 8. Interoperability

<!-- Guidance: Describe how information and services are exchanged inside the scope and with partners: styles, standards, contracts and ownership. Pitfall: agreeing the pipe (API gateway) and forgetting the meaning of the data on it. -->

| Interface ID | From | To | Style | Data | Contract standard | Owner |
|---|---|---|---|---|---|---|
| IF-01 *(Example)* | Portal | Claims platform | Synchronous REST | Claim registration | OpenAPI contract | [@claims-team] |
| IF-02 *(Example)* | Claims platform | Event streaming | Asynchronous events | Claim state changes | AsyncAPI contract, schema registry | [@claims-team] |
| IF-03 *(Example)* | Policy administration | Customer data hub | Events plus nightly reconciliation | Customer and policy changes | Canonical customer schema | [@data-owner] |
| IF-04 *(Example)* | Partner | API gateway | REST with mutual TLS | Claim submission | Partner API terms | [@partner-manager] |
| [IF-nn] | [From] | [To] | [Style] | [Data] | [Standard] | [@owner] |

Specify each interface in detail with the REST, event or interface
control templates (`architecture/rest-api-specification`,
`architecture/event-api-specification`,
`architecture/interface-control-document`).

## 9. Architecture Requirements Specification summary

<!-- Guidance: Summarise the requirements that implementation must meet to realise this architecture: measurable success criteria, architecture requirements per domain, interoperability requirements, constraints and assumptions. Hold the full specification separately if it is long. Pitfall: copying project functional requirements; these are architecture-level requirements. -->

| Req ID | Domain | Requirement | Rationale | Verification | Priority |
|---|---|---|---|---|---|
| ARS-BUS-01 *(Example)* | Business | Simple claims must be decidable without human touch when triage rules pass | BG-01 | Process test with sample claims | Must |
| ARS-DAT-01 *(Example)* | Data | Each customer has exactly one golden identifier used by all target applications | BG-02, DP-01 | Data quality report | Must |
| ARS-DAT-02 *(Example)* | Data | Customer and claim data stored and processed only in EU regions | CNS-02 | Configuration review | Must |
| ARS-APP-01 *(Example)* | Application | Target applications expose functions only through published APIs | AP-01 | Architecture compliance review | Must |
| ARS-TEC-01 *(Example)* | Technology | Claims platform recovers within 4 hours with at most 15 minutes of data loss | BG-04 | Recovery test | Must |
| ARS-INT-01 *(Example)* | Interoperability | All events carry the golden customer ID and a schema version | BG-02 | Contract test | Should |
| [ARS-xxx-nn] | [Domain] | [Requirement] | [BG / DRV / principle] | [Method] | [Must / Should / Could] |

Quality attribute scenarios can be detailed with the quality attributes
template (`requirements/quality-attributes`) and evaluated with an ATAM
(`architecture/atam-evaluation`). Keep requirement status in the
requirements traceability matrix (`requirements/traceability-matrix`).

## 10. Options, trade-offs and risks

<!-- Guidance: Record the main alternatives considered per domain, why the target was chosen and the architecture risks that remain. Each significant choice should have an ADR. Pitfall: presenting only the chosen option, which makes the board suspect the others were never examined. -->

### 10.1 Options considered

| Decision area | Options | Chosen | Reason | ADR |
|---|---|---|---|---|
| *Example:* Customer master | Hub; master in policy system A; registry only | Hub | Only option independent of policy system replacement | ADR-012 |
| *Example:* Claims platform | Extend current; buy package; build | Buy package | Rules and workflow are not differentiating (BP-02) | ADR-013 |
| *Example:* Integration | Extend file transfer; API gateway and events | Gateway and events | Meets AP-01 and real-time triage | ADR-014 |
| [Area] | [Options] | [Chosen] | [Reason] | [ADR-nnn] |

### 10.2 Architecture risks

| Risk ID | Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| ARK-01 *(Example)* | Matching accuracy below 95% delays hub adoption | Medium | High | Pilot matching on system C data first | [@data-architect] |
| ARK-02 *(Example)* | Package rules engine cannot express partner-specific rules | Low | Medium | Proof of concept before contract | [@application-architect] |
| ARK-03 *(Example)* | Private link latency affects triage response time | Medium | Medium | Cache policy cover data in the hub | [@technology-architect] |
| [ARK-nn] | [Risk] | [H / M / L] | [H / M / L] | [Mitigation] | [@owner] |

## 11. Traceability

<!-- Guidance: Prove that every goal is served by gaps and components, and that every component serves a goal. Rows with no goal are candidates for removal; goals with no rows are unfunded promises. Pitfall: building the matrix at the end instead of maintaining it while designing. -->

| Goal / driver | Principles | Gaps | Requirements | Candidate components | Views |
|---|---|---|---|---|---|
| BG-01 *(Example)* | BP-02, AP-01 | GAP-B-01, GAP-B-04, GAP-B-05, GAP-A-01, GAP-A-02 | ARS-BUS-01, ARS-APP-01 | CRC-01, CRC-07, CRC-08 | V-B1, V-A1 |
| BG-02 *(Example)* | DP-01 | GAP-D-01, GAP-D-03, GAP-A-04 | ARS-DAT-01, ARS-INT-01 | CRC-04, CRC-05, CRC-10 | V-D1, V-D2 |
| BG-03 *(Example)* | TP-01 | GAP-B-02, GAP-T-02, GAP-A-04 | ARS-TEC-01 | CRC-02, CRC-10, CRC-12 | V-T1 |
| BG-04 *(Example)* | TP-01, SP-01 | GAP-T-01, GAP-T-03 | ARS-TEC-01 | CRC-11, CRC-12 | V-T1 |
| CNS-02 *(Example)* | SP-01 | GAP-T-02 | ARS-DAT-02 | CRC-12 | V-D2 |
| [BG / DRV / CNS] | [Principles] | [Gaps] | [Requirements] | [Components] | [Views] |

## 12. Candidate roadmap components

<!-- Guidance: Consolidate the components from each domain into one list for Phase E. Give a rough size and any known dependency so the roadmap team can group them into work packages. Pitfall: sequencing here; leave timing to the roadmap. -->

| CRC ID | Component | Domains | Gaps closed | Rough size | Known dependencies |
|---|---|---|---|---|---|
| CRC-01 *(Example)* | Triage rules and decision authority | Business | GAP-B-01, GAP-B-04 | M | CRC-07 |
| CRC-02 *(Example)* | Organisation redesign and training | Business | GAP-B-02 | M | CRC-07 |
| CRC-03 *(Example)* | Partner onboarding | Business | GAP-B-03 | S | CRC-08, CRC-11 |
| CRC-04 *(Example)* | Customer data hub | Data | GAP-D-01, GAP-D-03 | L | CRC-11, CRC-12 |
| CRC-05 *(Example)* | Data quality remediation | Data | GAP-D-01 | M | None |
| CRC-06 *(Example)* | Structured loss data model | Data | GAP-D-02 | S | CRC-07 |
| CRC-07 *(Example)* | Claims platform, triage service and dashboard | Application, Business | GAP-A-01, GAP-B-05 | L | CRC-11, CRC-12 |
| CRC-08 *(Example)* | Portal, partner channel, workspace | Application | GAP-A-02, GAP-A-03 | M | CRC-07, CRC-04 |
| CRC-09 *(Example)* | Policy system C consolidation | Application | GAP-A-05 | L | CRC-04 |
| CRC-10 *(Example)* | Legacy CRM decommissioning | Application, Data | GAP-A-04, GAP-D-04 | S | CRC-04, CRC-08 |
| CRC-11 *(Example)* | Integration platform | Technology | GAP-T-01 | M | CRC-12 |
| CRC-12 *(Example)* | Cloud hosting and connectivity | Technology | GAP-T-02, GAP-T-03 | M | None |
| CRC-13 *(Example)* | Observability onboarding | Technology | GAP-T-04 | S | CRC-12 |
| [CRC-nn] | [Component] | [Domains] | [Gaps] | [S / M / L] | [CRC-nn] |

The roadmap (`architecture/architecture-roadmap-transition`) groups these
components into work packages and Transition Architectures.

## 13. Glossary and references

<!-- Guidance: Define the method terms and list the sources and models this document relies on. -->

### 13.1 Glossary

| Term | Meaning in this document |
|---|---|
| Baseline architecture | The architecture in place at the start of the engagement |
| Target architecture | The architecture intended at the end of the time horizon |
| Gap | A difference between baseline and target that must be closed by change |
| Building block | A reusable package of capability or function that the architecture is composed of |
| Candidate roadmap component | A unit of change proposed by a domain architecture, before grouping into work packages |
| View | A representation of the architecture that addresses specific stakeholder concerns |
| Viewpoint | The conventions used to build and read one kind of view |
| [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 | ArchiMate Specification (The Open Group), version used by your modelling tool: 3.2 (2022) or 4 (April 2026) | [Version] |
| REF-03 | Architecture Vision (`architecture/togaf-architecture-vision`) | [x.y] |
| REF-04 | Architecture Principles Catalogue (`architecture/architecture-principles`) | [x.y] |
| REF-05 | Reference architecture for the domain (`architecture/reference-architecture`) | [x.y] |
| REF-06 | Architecture description conventions (`architecture/architecture-description-42010`) | [x.y] |
| REF-07 | Architecture decision records (`architecture/adr-full`) | [Location] |

## Standard and licence note

Structure aligned with The TOGAF Standard, 10th Edition (2025 Update),
published by The Open Group: Phases B (Business Architecture), C
(Information Systems Architectures) and D (Technology Architecture) of the
Architecture Development Method, the Architecture Definition Document and
the Architecture Requirements Specification, with gap analysis per domain.
Viewpoint names refer to the example viewpoints of the ArchiMate
Specification. Only phase, deliverable and viewpoint names are used; this
template is original text and reproduces no definitions, tables or other
text from either standard. TOGAF and ArchiMate are registered trademarks of
The Open Group. Check the current editions at opengroup.org and obtain the
standards for their full guidance. Template licence: MIT.