Statement of Architecture Work: [Architecture engagement name]
The Statement of Architecture Work is the agreement between the sponsor and the
architecture team on what an architecture engagement will produce, how, by whom, by
when, at what cost and how acceptance will be judged. In The TOGAF Standard, 10th
Edition (2025 release with Technical Corrigendum 1), it is an output of Phase A (Architecture Vision) of the
Architecture Development Method (ADM), answers a Request for Architecture Work and is
approved together with the Architecture Vision. This template covers background,
scope, objectives, roles, ADM tailoring, deliverables, plan, budget, governance,
risks, acceptance and change procedure, and sign-off. Replace every [bracketed]
value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [SAW-YYYY-NN] |
| Engagement | [Architecture engagement name] |
| Answers request | [RAW-YYYY-NN] |
| Accompanies vision | [AV-ENG-001] |
| ADM phase | Phase A: Architecture Vision |
| Architecture level | [Strategic / Segment / Capability] |
| Version | [0.1] |
| Status | [Draft / In review / Signed / Amended / Closed] |
| Owner (lead architect) | [@lead-architect] |
| Sponsor | [@sponsor] |
| Approvers / reviewers | [Sponsor, Architecture Board chair, finance partner] |
| Engagement period | YYYY-MM-DD to YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Repository location | [Architecture Repository path or ID] |
| Last updated | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Conditions | Date |
|---|
| Sponsor | [@sponsor] | [Signed / Signed with conditions / Rejected] | [Conditions] | YYYY-MM-DD |
| Architecture Board chair | [@chair] | [Decision] | [Conditions] | YYYY-MM-DD |
| Lead architect | [@lead-architect] | [Signed] | [Conditions] | YYYY-MM-DD |
| Finance partner | [@finance] | [Budget confirmed] | [Conditions] | YYYY-MM-DD |
| Business owner | [@business-owner] | [Resources confirmed] | [Conditions] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@lead-architect] | Scope, objectives and deliverables drafted from the vision |
| 0.5 | YYYY-MM-DD | [@lead-architect] | Example: Plan, budget and roles added; reviewed with sponsor and finance |
| 1.0 | YYYY-MM-DD | [@lead-architect] | Example: Signed at board gate 1 (outcome record ARB-2026-029) with condition C1 |
| 1.1 | YYYY-MM-DD | [@lead-architect] | Example: Change CHG-SAW-01 approved: data quality assessment extended by one week |
Contents
1. Statement summary
| Item | Commitment |
|---|
| What will be produced | Example: Architecture Vision, Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap with Transition Architectures, Implementation and Migration Plan, and draft Architecture Contracts for the first work packages |
| For which scope | Example: Retail motor and home claims and the customer domain, all EU markets, business to technology domains, target 24 months out |
| By when | Example: 15 weeks from kick-off on 2026-09-14, ending at board gate 3 on 2026-12-28 |
| At what cost | Example: USD 319,000 including 10% contingency (section 9) |
| Led by | [@lead-architect] |
| Accepted by | [@sponsor], after an Architecture Board review at each gate |
| Ends when | Example: All deliverables in section 7 are accepted under section 12 and handed to implementation governance |
2. Background and request reference
2.1 Request reference
| Field | Value |
|---|
| Request | [RAW-YYYY-NN], accepted on YYYY-MM-DD by [board outcome record] (Example: ARB-2026-024, accepted with changes) |
| Sponsor | [@sponsor] |
| Problem in one sentence | Example: Simple claims take 11 days to decide and customer records conflict across three policy systems and a CRM that loses support next year |
| Goals served | Example: BG-01 Faster claims decisions; BG-02 One trusted view of the customer; BG-03 Lower cost to serve; BG-04 Resilient outsourced services (vision section 3.2) |
| Intake conditions | Example: C1 customer domain ownership ruled in favour of this engagement; C2 expert release dates confirmed |
2.2 Differences from the request
| Request said | This statement says | Reason | Agreed by |
|---|
| Example: Retail and commercial claims | Retail motor and home claims only | Commercial claims run on a different platform; including it would add eight weeks | Board, intake |
| Example: Replace the legacy CRM | Decide the customer master; CRM future follows from it | Interviews show the pain is inconsistent data, not missing CRM features | Sponsor, Phase A |
| Example: Target and roadmap only | Also draft Architecture Contracts for WP-01 and WP-02 | The sponsor wants delivery to start without a gap after gate 3 | Sponsor, Phase A |
| [Request] | [Statement] | [Reason] | [Who] |
3. Scope of the architecture work
3.1 Scope dimensions
| Dimension | In scope | Out of scope |
|---|
| Enterprise breadth | Example: Retail motor and home claims, all EU markets; customer domain for all retail lines | Commercial lines, life products |
| Business capabilities | Example: Claims intake, assessment, settlement; customer information management; partner management at interface level | Underwriting, reinsurance, pricing |
| Architecture domains | Example: Business, data, application, technology, with security and privacy across all four | Physical facilities, organisation design below team level |
| Depth | Example: Capability and logical level for all domains; physical level only for integration and hosting | Detailed solution design, vendor selection |
| Time horizon | Example: Baseline as of YYYY-MM; target for YYYY-MM (24 months) with up to two Transition Architectures | Beyond 36 months |
| External parties | Example: Repair network and loss adjusters at interface level | Partner internal systems |
| [Dimension] | [In scope] | [Out of scope] |
3.2 Architecture partitioning and conformance
| Item | Value |
|---|
| Parent architecture | Example: Group strategic architecture SA-2026, which this segment must conform to |
| Neighbouring partitions | Example: Distribution segment (shares the customer domain; this engagement owns the customer data model) |
| Reference models used | Example: Group capability map v2.1, insurance data reference model in the repository |
| Standards base | Example: Approved technology standards list YYYY-Qn and the API design guidelines (architecture/api-design-guidelines) |
3.3 Questions the engagement will answer
The engagement ends with an evidence-based answer to each question below, taken from
section 6.1 of the request and refined in Phase A.
| Q ID | Question | Answered in |
|---|
| Q-01 (Example) | Replace, extend or buy the claims platform, and in which order relative to the customer data work? | Architecture Definition Document section 10; roadmap |
| Q-02 (Example) | Where does the master customer record live, and which systems change to use it? | Architecture Definition Document section 4 |
| Q-03 (Example) | Can the legacy CRM be retired before support ends? | Roadmap and Implementation and Migration Plan |
| Q-04 (Example) | What is the cost and sequence within USD 2.5 million? | Roadmap section on resource and cost estimates |
| [Q-nn] | [Question] | [Deliverable and section] |
4. Objectives and success measures
4.1 Objectives of the architecture work
| ID | Objective | Measure of success | Goal supported |
|---|
| OBJ-01 (Example) | Agree one target architecture for claims and customer data | Target approved at gate 2 with no unresolved stakeholder objection | BG-01, BG-02 |
| OBJ-02 (Example) | Give the capital committee a costed, sequenced plan | Roadmap with cost per work package within plus or minus 25% and named owners | BG-03 |
| OBJ-03 (Example) | Make delivery projects governable from day one | Architecture Requirements Specification with a verification method for every requirement; draft contracts for WP-01 and WP-02 | All |
| OBJ-04 (Example) | Settle the customer master question | Recorded decision with options and reasons in an ADR | BG-02 |
| [OBJ-nn] | [Objective] | [Measure] | [BG-nn] |
4.2 Business KPIs this work enables
The business KPIs (for example KPI-01 share of simple claims decided within 48 hours,
KPI-03 operating cost per claim) are defined with baselines and targets in section 7.2
of the Architecture Vision. The architecture work is responsible for making them
measurable (a baseline measurement method for each) and for tracing every work package
to at least one KPI; it is not responsible for reaching the targets, which depends on
delivery and adoption.
5. Roles, responsibilities and RACI
5.1 Roles
| Role | Name | Responsibility | Time commitment |
|---|
| Sponsor | [@sponsor] | Owns the outcome; resolves business conflicts; signs acceptance | 2 hours per month plus gates |
| Business owner | [@head-of-claims] | Provides experts; validates the business architecture | 2 hours per week |
| Lead architect | [@lead-architect] | Owns all deliverables, the plan and the budget of the work | Full time, weeks 1 to 15 |
| Business architect | [@business-architect] | Phase B models, business scenarios, capability assessment | Full time, weeks 1 to 8 |
| Data architect | [@data-architect] | Phase C data models, data quality assessment | 50%, weeks 1 to 15 |
| Application architect | [@application-architect] | Phase C application models and portfolio impact | 50%, weeks 1 to 15 |
| Technology architect | [@technology-architect] | Phase D platform, hosting and integration | 50%, weeks 5 to 12 |
| Security architect | [@security-architect] | Security and privacy requirements across domains | 20%, weeks 1 to 15 |
| Architecture Board | [Chair @chair] | Reviews at the three gates; rules on escalations | Scheduled gates |
5.2 RACI for deliverables
R = responsible, A = accountable, C = consulted, I = informed.
| Deliverable | Sponsor | Lead architect | Domain architects | Security architect | Business owner | Architecture Board |
|---|
| Architecture Vision | A | R | C | C | C | C |
| Statement of Architecture Work | A | R | C | I | C | C |
| Architecture Definition Document | I | A | R | C | C | C |
| Architecture Requirements Specification | I | A | R | R | C | C |
| Architecture Roadmap | C | A | R | C | C | C |
| Implementation and Migration Plan | C | A | R | I | C | C |
| Draft Architecture Contracts | I | A | R | C | I | C |
| Acceptance of each deliverable | A | R | I | I | C | C |
Each row has exactly one A. For larger teams, use the RACI template (business/raci).
6. Architecture approach and ADM tailoring
6.1 Phases covered
| ADM phase | Included | Depth and emphasis (Example) | Main output |
|---|
| Phase A: Architecture Vision | Yes | Full | Architecture Vision, this statement |
| Phase B: Business Architecture | Yes | Capability, value stream and process level for claims | Business part of the Architecture Definition Document |
| Phase C: Information Systems Architectures | Yes | Data in depth (customer master); applications at logical level | Data and application parts of the Architecture Definition Document |
| Phase D: Technology Architecture | Yes | Hosting and integration at physical level; rest logical | Technology part of the Architecture Definition Document |
| Phase E: Opportunities and Solutions | Yes | Work packages and Transition Architectures | Roadmap inputs |
| Phase F: Migration Planning | Yes | Costed sequence and value per increment | Architecture Roadmap, Implementation and Migration Plan |
| Phase G: Implementation Governance | Hand-off | Draft contracts for WP-01 and WP-02 only | Draft Architecture Contracts |
| Phase H: Architecture Change Management | Hand-off | Change process described, run by the board | Reference to the change request process |
| Requirements Management | Continuous | Requirement IDs, status and traceability from week 2 | Architecture Requirements Specification |
6.2 Iterations and cadence
[Describe the iterations and the working rhythm.] Example: Phases B to D run twice: an
outline pass of two weeks to agree the shape of the target with the sponsor, then a
detailed pass of six weeks. The team works in two-week cycles with a review of models
with the claims team at the end of each cycle. Phases E and F start in outline during
the detailed pass so that cost questions surface early.
6.3 Techniques and methods
| Technique | Used for | Owner |
|---|
| Example: Stakeholder interviews and concern mapping | Concerns to views (vision section 2.3) | Lead architect |
| Example: Business scenarios for three claim journeys | Phase B requirements and target process | Business architect |
| Example: Capability heat map | Where change effort goes | Business architect |
| Example: Data profiling of policy system extracts | Baseline data quality, matching feasibility | Data architect |
| Example: Gap analysis per domain | Gaps and candidate roadmap components | Domain architects |
| Example: Options analysis with ADRs | Customer master, claims platform, integration | Lead architect (architecture/adr-full) |
| Example: Quality attribute scenarios | Measurable non-functional requirements (requirements/quality-attributes) | Technology and security architects |
| Example: Dependency and value analysis | Sequencing of work packages | Lead architect |
| [Technique] | [Use] | [Owner] |
6.4 Tools, repository and notation
| Item | Choice |
|---|
| Modelling tool | [Tool and version] |
| Notation | Example: ArchiMate for models (version supported by the tool: 3.2 or 4); BPMN for processes; Mermaid stand-ins in documents |
| Repository | [Architecture Repository path]; all work products stored there with IDs |
| Document format | Example: Markdown in the repository, exported to PDF for gates |
6.5 Tailoring decisions
| Decision | Reason |
|---|
| Example: No separate Phase D iteration for end-user computing | Out of scope; no change to desktops |
| Example: Physical design only for integration and hosting | These drive cost and the residency constraint CNS-02 |
| Example: Draft contracts produced inside the engagement | Sponsor wants delivery to start right after gate 3 |
| [Decision] | [Reason] |
7. Deliverables and work products
7.1 Deliverables
| D ID | Deliverable | Content summary | Template | Owner | Gate | Acceptance criteria |
|---|
| D-01 (Example) | Architecture Vision | Stakeholders, goals, scope, baseline and target sketch, value, risks | architecture/togaf-architecture-vision | Lead architect | Gate 1 | ACC-01, ACC-03 |
| D-02 (Example) | Statement of Architecture Work | This document | architecture/statement-of-architecture-work | Lead architect | Gate 1 | ACC-10 |
| D-03 (Example) | Architecture Definition Document | Baseline, target and gaps for four domains; views per concern | architecture/architecture-definition-document | Lead architect | Gate 2 | ACC-01, ACC-04, ACC-05 |
| D-04 (Example) | Architecture Requirements Specification | Measurable requirements, interoperability, service contracts, standards | architecture/architecture-requirements-specification | Data architect | Gate 2 | ACC-04, ACC-06 |
| D-05 (Example) | Architecture Roadmap and Transition Architectures | Work packages, plateaus, value and cost per increment | architecture/architecture-roadmap-transition | Lead architect | Gate 3 | ACC-02, ACC-03, ACC-07, ACC-08 |
| D-06 (Example) | Implementation and Migration Plan | Delivery approach, decommissioning, delivery risks | Section 9 of D-05 | Application architect | Gate 3 | ACC-08 |
| D-07 (Example) | Draft Architecture Contracts for WP-01, WP-02 | Requirements, checkpoints and conformance terms | architecture/architecture-contract | Technology architect | Gate 3 | ACC-09 |
| D-08 (Example) | Decision records | One ADR for each significant choice | architecture/adr-full | Lead architect | Gates 2 and 3 | ACC-05 |
| [D-nn] | [Deliverable] | [Content] | [Template] | [@owner] | [Gate] | [ACC-nn] |
7.2 Working artefacts (not formally accepted)
Example: interview notes, data profiling results, model files in the repository,
workshop outputs, a running risk and issue log. They are kept in the repository for
audit and reuse but are not signed off.
7.3 Deliverable flow
The diagram shows which deliverables feed which, so reviewers can see the impact of a
late input on everything downstream.
8. Plan, schedule and gates
| Gate | Date (Example) | Deliverables reviewed | Decision taken | Decision owner |
|---|
| Gate 1 | 2026-10-05 | D-01, D-02 | Approve vision, sign this statement, release budget for Phases B to F | Sponsor with Architecture Board |
| Gate 2 | 2026-11-30 | D-03, D-04, ADRs so far | Approve the target architecture and requirements | Architecture Board |
| Gate 3 | 2026-12-28 | D-05, D-06, D-07 | Approve the roadmap; hand off to implementation governance | Sponsor with Architecture Board |
The example dates follow from a start on 2026-09-14 and the durations in the chart (3,
2, 6 and 4 weeks). Gate 3 falls in the holiday period; move it to the first board
meeting of January if quorum is at risk, and record the change under section 13.
8.1 Interim checkpoints
| Checkpoint | When | Purpose |
|---|
| Example: Outline target walkthrough | End of week 5 | Sponsor confirms the direction before the detailed pass |
| Example: Data matching feasibility result | End of week 7 | Go or no-go for the hub option in Q-02 |
| Example: Cost model review with finance | End of week 12 | Finance accepts estimating method before gate 3 |
| [Checkpoint] | [When] | [Purpose] |
9. Resources and budget
9.1 Effort
| Role | Allocation | Weeks | Person-weeks |
|---|
| Lead architect | 100% | 15 | 15.0 |
| Business architect | 100% | 8 | 8.0 |
| Data architect | 50% | 15 | 7.5 |
| Application architect | 50% | 15 | 7.5 |
| Technology architect | 50% | 8 | 4.0 |
| Security architect | 20% | 15 | 3.0 |
| Total architecture team | | | 45.0 |
9.2 Cost
| Cost item | Basis (Example) | Amount (Example) |
|---|
| Architecture team | 45.0 person-weeks at USD 6,000 blended rate | USD 270,000 |
| Workshops, tooling licences, data extracts | Quoted | USD 20,000 |
| Subtotal | | USD 290,000 |
| Contingency | 10% of subtotal, released by the sponsor | USD 29,000 |
| Total | | USD 319,000 |
The total sits inside the USD 320,000 approved in the request. Business expert time (two
senior handlers at two days per week for 10 weeks, a data steward at one day per week
for 10 weeks) is provided by the business owner and not charged to the engagement.
10. Governance, reporting and communication
10.1 Governance
| Forum | Role for this engagement | Frequency |
|---|
| Example: Claims transformation steering group | Business decisions, priority conflicts, sponsor escalations | Monthly |
| Example: Architecture Board | Gate reviews, rulings on principles and dispensations | At gates 1 to 3; ad hoc escalations |
| Example: Architecture team stand-up | Daily coordination | Daily |
| Example: Design authority for the claims domain | Technical choices below board level | Fortnightly |
The board's decision rights, quorum and review tiers are set in the Architecture Board
Charter (architecture/architecture-governance-charter).
10.2 Status reporting
| Report | Audience | Content | Frequency | Owner |
|---|
| Example: Status report | Sponsor, steering group | Progress per deliverable, budget burn, top risks, decisions needed | Fortnightly | Lead architect |
| Example: Gate pack | Architecture Board | Deliverables, open issues, compliance with principles | At each gate | Lead architect |
| Example: Show and tell | Claims team | Models and journeys for feedback | Fortnightly | Business architect |
| [Report] | [Audience] | [Content] | [Frequency] | [@owner] |
Use the status report template (business/status-report) for the fortnightly report.
The communications plan for wider audiences is in section 11 of the Architecture Vision.
10.3 Escalation path
- Working-level disagreement: lead architect and business owner resolve
within three working days.
- Unresolved, or affecting scope or budget: sponsor decides within five
working days.
- Conflict with a principle or standard: Architecture Board rules at the
next meeting, or by written procedure if a gate is at risk.
11. Risks, assumptions, dependencies and issues
11.1 Risks
| Risk ID | Risk | Likelihood | Impact | Response | Owner |
|---|
| SRK-01 (Example) | Claims experts pulled into the regulatory remediation | Medium | High | Fixed weekly slots agreed with the Head of Claims; escalate missed slots to the sponsor | [@lead-architect] |
| SRK-02 (Example) | Policy system C data extract delayed by the vendor | Medium | Medium | Request extract in week 1; use a sample to start profiling | [@data-architect] |
| SRK-03 (Example) | Distribution segment changes the customer model in parallel | Low | High | Joint model review every two weeks under condition C1 | [@data-architect] |
| SRK-04 (Example) | Cost estimates too uncertain for the capital committee | Medium | High | Finance review at week 12; ranges with stated confidence | [@lead-architect] |
| [SRK-nn] | [Risk] | [H / M / L] | [H / M / L] | [Response] | [@owner] |
11.2 Assumptions
| ID | Assumption | Impact if false | Owner |
|---|
| ASM-01 (Example) | The cloud landing zone is approved for confidential data | Phase D must add a hosting option; two extra weeks | [@platform-lead] |
| [ASM-nn] | [Assumption] | [Impact] | [@owner] |
11.3 Dependencies
| ID | Dependency | On whom | Needed by | Status |
|---|
| DEP-01 (Example) | Customer data extracts from three policy systems | Policy IT teams | Week 2 | [Open] |
| DEP-02 (Example) | Current run-cost figures for claims applications | IT finance | Week 6 | [Open] |
| DEP-03 (Example) | Ruling on customer domain ownership | Architecture Board | Gate 1 | [Closed: condition C1] |
| [DEP-nn] | [Dependency] | [Team] | [Week or date] | [Status] |
Open issues are tracked in the RAID log (project/raid-log).
12. Acceptance criteria and procedure
12.1 Acceptance criteria
| ID | Criterion | Evidence | Applies to |
|---|
| ACC-01 (Example) | Every concern in vision section 2.3 is addressed by at least one named view | Concern to view table in the Architecture Definition Document | D-01, D-03 |
| ACC-02 (Example) | Every gap is assigned to a work package with an owner | Consolidated gaps table in the roadmap | D-03, D-05 |
| ACC-03 (Example) | Each KPI in vision section 7.2 has an agreed baseline measurement | Signed baseline report | D-01, D-05 |
| ACC-04 (Example) | Security and privacy architects sign off the target data architecture | Approval record | D-03, D-04 |
| ACC-05 (Example) | Each of Q-01 to Q-04 has a recorded answer with options and reasons | ADRs and the relevant sections | D-03, D-08 |
| ACC-06 (Example) | Every requirement has an ID, a rationale, a verification method and a priority | Requirements tables; zero rows missing a field | D-04 |
| ACC-07 (Example) | Every work package traces to at least one goal and one KPI | Traceability matrix in the roadmap | D-05 |
| ACC-08 (Example) | Cost per work package is given with a range and confidence, reviewed by finance | Finance review record | D-05, D-06 |
| ACC-09 (Example) | Draft contracts name the requirements, checkpoints and dispensation route for WP-01 and WP-02 | Contract drafts | D-07 |
| ACC-10 (Example) | Scope, budget and plan are consistent with each other and with the request | Sections 3, 8 and 9 of this statement reconcile; finance confirms | D-02 |
| [ACC-nn] | [Criterion] | [Evidence] | [D-nn] |
12.2 Acceptance procedure
- The lead architect submits each deliverable with a short cover note that
lists the acceptance criteria and where the evidence is.
- Reviewers named in the RACI (section 5.2) have [ten] working days to
return comments. Silence is not acceptance; the lead architect chases on
day seven.
- Comments are classified as blocking (a criterion is not met) or
non-blocking (improvement). Only blocking comments prevent acceptance.
- The lead architect resolves blocking comments and resubmits within [five]
working days, or escalates under section 10.3.
- The sponsor records acceptance in the table in section 14.2, citing the
board outcome record for gated deliverables.
- Non-blocking comments are logged and either closed or carried into the
next version of the deliverable.
13. Change procedure
13.1 Thresholds
| Change | Approved by | Record |
|---|
| Within a deliverable's content, no effect on criteria, dates or cost | Lead architect | Deliverable revision history |
| Date of a non-gate checkpoint moves by up to two weeks | Lead architect, sponsor informed | Status report |
| Gate date moves, or cost changes by up to [10%] (within contingency) | Sponsor | Change record and new minor version of this statement |
| Scope dimension changes, deliverable added or removed, or cost beyond contingency | Sponsor and Architecture Board | Change record and new major version |
| Change to the target architecture after gate 2 | Architecture Board through Phase H | Architecture Change Request (architecture/architecture-change-request) |
13.2 Change record
| Change ID | Date | Requested by | Description | Impact (scope, date, cost) | Decision | Approved by |
|---|
| CHG-SAW-01 (Example) | YYYY-MM-DD | [@data-architect] | Extend data quality assessment by one week because policy system C has 40% more records than estimated | Detailed pass plus one week (data architect 50% plus business architect 100%: 1.5 person-weeks at USD 6,000 = USD 9,000 from contingency, leaving USD 20,000); gate 2 unchanged by overlapping Phase E outline | Approved | Sponsor |
| [CHG-SAW-nn] | YYYY-MM-DD | [@name] | [Description] | [Impact] | [Approved / Rejected] | [@approver] |
14. Sign-off
14.1 Agreement to this statement
By signing, the parties agree to the scope, plan, budget, roles, acceptance criteria and
change procedure in this document.
| Party | Name | Signature or approval record | Date |
|---|
| Sponsor | [@sponsor] | [Record] | YYYY-MM-DD |
| Lead architect | [@lead-architect] | [Record] | YYYY-MM-DD |
| Architecture Board chair | [@chair] | [Board outcome record] | YYYY-MM-DD |
| Business owner | [@business-owner] | [Record] | YYYY-MM-DD |
14.2 Acceptance of deliverables
| D ID | Version accepted | Accepted by | Board record | Date | Open non-blocking comments |
|---|
| D-01 | [1.0] | [@sponsor] | [ARB-YYYY-NNN] | YYYY-MM-DD | [Number] |
| D-02 | [1.0] | [@sponsor] | [ARB-YYYY-NNN] | YYYY-MM-DD | [Number] |
| D-03 | [x.y] | [@sponsor] | [ARB-YYYY-NNN] | YYYY-MM-DD | [Number] |
| D-04 | [x.y] | [@sponsor] | [ARB-YYYY-NNN] | YYYY-MM-DD | [Number] |
| D-05 | [x.y] | [@sponsor] | [ARB-YYYY-NNN] | YYYY-MM-DD | [Number] |
| [D-06 to D-08] | [x.y] | [@sponsor] | [ARB-YYYY-NNN] | YYYY-MM-DD | [Number] |
14.3 Engagement closure
When all deliverables are accepted, the lead architect closes the engagement: final
budget reported against section 9, lessons recorded (project/lessons-learned), work
products marked as approved in the repository, and the hand-off to implementation
governance confirmed with the Architecture Board. Contracts then follow the Architecture
Contract template (architecture/architecture-contract) and compliance reviews follow
the Architecture Compliance Assessment
(architecture/architecture-compliance-assessment).
15. Glossary and references
15.1 Glossary
| Term | Meaning in this document |
|---|
| ADM | Architecture Development Method, the iterative cycle of phases at the centre of the TOGAF Standard |
| Architecture Contract | An agreement with a delivery team on the architecture requirements it must meet and how conformance is checked |
| Deliverable | A work product the sponsor formally accepts against stated criteria |
| Gate | A scheduled review where the Architecture Board or sponsor decides whether the engagement may proceed |
| Tailoring | Deliberate adaptation of the method's phases, depth and techniques to one engagement |
| Transition Architecture | A stable, valuable intermediate state between baseline and target |
| Work package | A unit of change with one owner and one outcome, used to plan delivery |
| [Term] | [Meaning] |
15.2 References
| ID | Reference | Version / date |
|---|
| REF-01 | The TOGAF Standard, 10th Edition (The Open Group, catalogue C220), incorporating Technical Corrigendum 1 (U254, 15 May 2025) | 19 May 2025 |
| REF-02 | Request for Architecture Work (architecture/request-for-architecture-work) | [RAW-YYYY-NN] |
| REF-03 | Architecture Vision (architecture/togaf-architecture-vision) | [x.y] |
| REF-04 | Architecture Definition Document (architecture/architecture-definition-document) | [x.y] |
| REF-05 | Architecture Requirements Specification (architecture/architecture-requirements-specification) | [x.y] |
| REF-06 | Architecture Roadmap and Transition Architectures (architecture/architecture-roadmap-transition) | [x.y] |
| REF-07 | Architecture Board Charter (architecture/architecture-governance-charter) | [x.y] |
Standard and licence note
Structure aligned with The TOGAF Standard, 10th Edition (2025 release with Technical Corrigendum 1), published by The
Open Group: the Statement of Architecture Work produced in Phase A (Architecture Vision)
of the Architecture Development Method in answer to a Request for Architecture Work,
with references to the later phases and deliverables it plans. TOGAF and ArchiMate are
registered trademarks of The Open Group. This template uses only the names of phases and
deliverables; all text is original. It was written from general professional practice,
without reading, quoting, paraphrasing or summarising the text of the standard, and it
reproduces no definitions, tables or lists from it. The thresholds, RACI, budget method
and acceptance procedure are suggestions of this template, not requirements of the
standard. Check the current edition and any technical corrigenda at opengroup.org and
obtain the standard for its own guidance. Template licence: MIT.