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