# Request for Architecture Work: [Request title]

> A Request for Architecture Work is the formal ask from a sponsor that
> starts an architecture engagement. In The TOGAF Standard, 10th Edition
> (2025 release with Technical Corrigendum 1), it is the trigger for a cycle of the Architecture
> Development Method (ADM), usually raised after the Preliminary Phase has
> set up the architecture capability and before Phase A (Architecture
> Vision) begins. This template captures the sponsor, the problem, the
> goals and drivers, constraints, budget, timeline, stakeholders and
> expected outputs, then records the intake assessment and the decision of
> the architecture function. Replace every `[bracketed]` value and every
> row marked *Example*.

<!--
Guidance: How to use this template
- The sponsor (or a business analyst on the sponsor's behalf) fills
  sections 1 to 11. The architecture function fills section 12 (intake
  assessment and decision) and section 13 (next steps).
- Keep it short and factual. A request describes the problem and the
  outcome wanted; it should not prescribe a solution. If the sponsor
  already has a product in mind, record it as a stated preference in
  section 3.3, not as the scope.
- A complete request takes one to three hours to write. If the sponsor
  cannot answer sections 3, 4 and 8, the request is not ready for intake;
  run a short discovery conversation first
  (`requirements/discovery-workshop-plan`).
- An accepted request is answered by an Architecture Vision
  (`architecture/togaf-architecture-vision`) and a Statement of
  Architecture Work (`architecture/statement-of-architecture-work`).
- The worked example follows one fictional insurer whose claims and
  customer data programme runs through the whole TOGAF template set, so
  IDs (RAW, DRV, BG, CNS) line up across the documents.
-->

## Document control

<!-- Guidance: Give the request a unique ID that every later deliverable will cite. Record who raised it and who in the architecture function owns the intake. Pitfall: requests that arrive by e-mail and never get an ID, so nobody can later show why the engagement started. -->

| Field | Value |
|---|---|
| Document ID | [RAW-YYYY-NN] |
| Request title | [Request title] |
| Version | [0.1] |
| Status | [Draft / Submitted / In assessment / Accepted / Accepted with changes / Deferred / Merged / Declined / Withdrawn] |
| Sponsor | [@sponsor, title, business unit] |
| Requester (author) | [@requester] |
| Intake owner (architecture function) | [@chief-architect or delegate] |
| Approvers / reviewers | [Sponsor, Architecture Board chair, portfolio office] |
| Date submitted | YYYY-MM-DD |
| Decision required by | 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 (submits) | [@sponsor] | [Submitted] | [None] | YYYY-MM-DD |
| Business unit finance partner | [@finance] | [Funding confirmed / Indicative only] | [Conditions] | YYYY-MM-DD |
| Intake owner | [@chief-architect] | [Recommendation] | [Conditions] | YYYY-MM-DD |
| Architecture Board chair | [@chair] | [Accepted / Deferred / Merged / Declined] | [Conditions] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@requester] | First draft of problem, goals and constraints |
| 0.2 | YYYY-MM-DD | [@requester] | *Example:* Budget envelope and timeline confirmed with finance; stakeholders added |
| 1.0 | YYYY-MM-DD | [@chief-architect] | *Example:* Accepted with changes by the Architecture Board (outcome record ARB-2026-024); scope narrowed to retail lines |

## Contents

1. [Request summary](#1-request-summary)
2. [Sponsor and requesting organisation](#2-sponsor-and-requesting-organisation)
3. [Problem, opportunity and mission alignment](#3-problem-opportunity-and-mission-alignment)
4. [Business goals and drivers](#4-business-goals-and-drivers)
5. [Constraints and assumptions](#5-constraints-and-assumptions)
6. [Requested scope](#6-requested-scope)
7. [Stakeholders](#7-stakeholders)
8. [Budget, resources and timeline](#8-budget-resources-and-timeline)
9. [Existing architecture and related work](#9-existing-architecture-and-related-work)
10. [Expected outputs and success](#10-expected-outputs-and-success)
11. [Risks and urgency](#11-risks-and-urgency)
12. [Intake assessment and decision](#12-intake-assessment-and-decision)
13. [Next steps and hand-off](#13-next-steps-and-hand-off)
14. [Glossary and references](#14-glossary-and-references)

## 1. Request summary

<!-- Guidance: Write this section last, in five sentences or fewer, so that a board member who reads nothing else understands what is asked and why now. Questions to answer: what problem, for whom, what outcome, by when, with what money. Pitfall: a summary that names a product ("we need a new CRM") instead of an outcome. -->

| Field | Value |
|---|---|
| Request ID | [RAW-YYYY-NN] |
| One-line ask | *Example:* Define a target architecture and roadmap that lets the retail claims business decide simple claims within 48 hours and hold one trusted record per customer |
| Type of request | [New capability / Transformation / Rationalisation / Regulatory response / Technology refresh / Merger or divestment / Other] |
| Architecture level expected | [Strategic / Segment / Capability / Solution] |
| Requested start | YYYY-MM-DD |
| Requested end of architecture work | YYYY-MM-DD |
| Budget envelope for the resulting change | *Example:* Up to USD 2.5 million capital over two financial years |
| Budget for the architecture work itself | *Example:* Up to USD 320,000 from the claims transformation cost centre |

*Example summary:* Retail claims customers wait 11 days on average for a
decision, while competitors settle simple claims in under two days.
Customer details are held in three policy systems and a legacy CRM that
loses vendor support next year, so handlers re-key data and decisions are
made on conflicting records. The Chief Operating Officer asks the
architecture function to define a target architecture and a funded
roadmap within four months, so that the programme can start delivery in
the next financial year inside a USD 2.5 million capital envelope.

## 2. Sponsor and requesting organisation

<!-- Guidance: Name the person who owns the outcome and can make trade-offs, not only the person who wrote the request. The sponsor must have authority over the budget and over the business areas that will change. Pitfall: a sponsor two levels below the people whose processes change, who then cannot resolve conflicts. -->

| Field | Value |
|---|---|
| Sponsor name and title | *Example:* [@coo], Chief Operating Officer |
| Business unit | *Example:* Retail Insurance Operations |
| Sponsor's authority | *Example:* Budget holder for claims operations; chairs the claims transformation steering group |
| Business owner (day to day) | *Example:* [@head-of-claims], Head of Claims |
| Requester and contact | [@requester, e-mail or chat handle] |
| Funding source | *Example:* Claims transformation cost centre CC-4410 (architecture work); capital plan line CAP-27-12 (delivery) |
| Portfolio or programme link | *Example:* Strategic theme "Customer first" in the three-year plan |

### 2.1 Sponsor commitments

By submitting this request the sponsor agrees to:

1. Attend the Phase A kick-off and each Architecture Board gate where the
   engagement is reviewed.
2. Nominate business subject-matter experts and release them for the time
   stated in section 8.2.
3. Make scope and priority decisions within five working days when the
   lead architect escalates them.
4. Accept or reject the resulting Statement of Architecture Work and the
   final deliverables in writing.

Strike any commitment the sponsor cannot make and explain why in a note
under this list; the intake assessment in section 12 will weigh it.

## 3. Problem, opportunity and mission alignment

<!-- Guidance: Describe the situation in business terms, with evidence. Explain how the request supports the enterprise mission, strategy or a named plan. Questions to answer: what hurts today, who feels it, how do we know, and what happens if nothing is done. Pitfall: describing symptoms in the IT estate without saying why the business cares. -->

### 3.1 Problem or opportunity statement

[Describe the problem or opportunity in two or three paragraphs. Quote
measurements where you have them and say where they come from.]

*Example:* The retail claims operation handles about 140,000 motor and
home claims a year. Average time to a decision is 11 days; customer
research shows that most policyholders expect a decision on a simple claim
within two days. Handlers use five systems per claim and re-key customer
details between them, which causes about one claim in twelve to be
reopened because of wrong contact or bank details.

The legacy CRM that holds the customer contact history reaches the end of
vendor support in [month YYYY]. The three policy systems each keep their
own customer records, synchronised by nightly files, so there is no single
answer to "who is this customer and what cover do they hold".

### 3.2 Alignment with mission and strategy

| Strategy element | How this request supports it | Source |
|---|---|---|
| *Example:* Mission: "Help customers recover quickly after a loss" | Faster decisions on simple claims are the most visible proof of the mission | Corporate mission statement |
| *Example:* Three-year plan theme "Customer first" | One trusted customer view is a stated prerequisite of the theme | Strategic plan YYYY to YYYY, section 4 |
| *Example:* Cost programme target of 15% lower operating cost | Less re-keying and fewer reopened claims lower cost per claim | Finance plan YYYY |
| [Strategy element] | [Contribution] | [Document and section] |

### 3.3 Stated preferences and prior ideas

Record any solution ideas the sponsor already holds, so that Phase A can
test them openly instead of discovering them late.

*Example:* The Head of Claims has seen a demonstration of a cloud claims
package and would like it assessed. The IT department has a draft proposal
to replace the legacy CRM like for like. Neither is a decision; both will
be considered as options in Phase E.

### 3.4 Consequence of doing nothing

*Example:* Decision times stay above competitors and complaint volumes
keep rising by an estimated 8% a year; the legacy CRM runs unsupported
after [month YYYY], which the risk function rates as a high operational
risk; and the cost programme target is missed by the claims operation.

## 4. Business goals and drivers

<!-- Guidance: Drivers are the forces pushing for change; goals are what the enterprise wants to reach in response. Give each a short ID so that the Architecture Vision can reuse it. Make goals measurable where possible, but do not invent targets: if the number is not known yet, say so and let Phase A set it. Pitfall: goals that are really solutions ("implement a data hub"). -->

### 4.1 Drivers

| ID | Driver | Type | Evidence |
|---|---|---|---|
| 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 / Environmental] | [Evidence] |

### 4.2 Goals

| ID | Goal | Indicative measure | Target known? | Driver |
|---|---|---|---|---|
| BG-01 *(Example)* | Faster claims decisions | Share of simple claims decided within 48 hours | Direction only; Phase A to set the target | DRV-01 |
| BG-02 *(Example)* | One trusted view of the customer | Customers with one golden record across policy lines | Direction only | DRV-01, DRV-03 |
| BG-03 *(Example)* | Lower cost to serve | Operating cost per claim | Yes: 20% lower than the YYYY baseline | DRV-04 |
| BG-04 *(Example)* | Resilient outsourced services | Critical third-party services with tested exit plans | Yes: all of them | DRV-02 |
| [BG-nn] | [Goal] | [Measure] | [Yes / Direction only] | [DRV-nn] |

## 5. Constraints and assumptions

<!-- Guidance: A constraint is something the architecture cannot change; an assumption is something believed true that must be checked. Record both with their source, because Phase A will rely on them when it sets scope. Questions to answer: what money, dates, contracts, laws, platforms or policies limit the options? Pitfall: hiding a political constraint ("the policy system stays") as an unstated assumption. -->

### 5.1 Constraints

| ID | Constraint | Type | Source |
|---|---|---|---|
| CNS-01 *(Example)* | Capital for the resulting change is capped at USD 2.5 million | Financial | Capital plan line CAP-27-12 |
| CNS-02 *(Example)* | Customer personal data must remain in the EU | Legal | Group data protection policy |
| CNS-03 *(Example)* | Policy administration contract renews on YYYY-MM-DD | Contractual | Vendor contract schedule |
| CNS-04 *(Example)* | No cut-overs during the year-end claims peak | Operational | Claims operations calendar |
| [CNS-nn] | [Constraint] | [Financial / Legal / Contractual / Operational / Technical / Organisational] | [Source] |

### 5.2 Assumptions

| ID | Assumption | Owner | Check by |
|---|---|---|---|
| ASM-01 *(Example)* | The existing cloud landing zone is approved for confidential data | [@platform-lead] | YYYY-MM-DD |
| ASM-02 *(Example)* | Claims subject-matter experts can be released two days per week during Phase B | [@head-of-claims] | YYYY-MM-DD |
| [ASM-nn] | [Assumption] | [@owner] | YYYY-MM-DD |

### 5.3 Principles and policies that apply

List enterprise principles and policies the requester already knows will
shape the answer. The full catalogue is maintained in the Architecture
Principles Catalogue (`architecture/architecture-principles`).

*Example:* BP-02 Reuse before buy before build; DP-01 Data has one
accountable owner and one master source; TP-01 Prefer managed services on
approved platforms; the group outsourcing policy for critical services.

## 6. Requested scope

<!-- Guidance: State the scope the sponsor has in mind across breadth, depth, time and architecture domains. Phase A will confirm or change it, so this is a starting position, not a commitment. Say clearly what the sponsor does not want covered. Pitfall: "the whole enterprise" as breadth, which no engagement can finish. -->

| Dimension | Requested in scope | Requested out of scope | Notes |
|---|---|---|---|
| Enterprise breadth | *Example:* Retail and commercial claims, all EU markets | Life products | Intake may narrow this |
| Business capabilities | *Example:* Claims intake, assessment, settlement; customer management | Underwriting, reinsurance | |
| Architecture domains | *Example:* Business, data, application, technology | Physical facilities | |
| Depth | *Example:* Enough to fund and plan projects | Detailed solution design | |
| Time horizon | *Example:* Target state 24 months from approval | Beyond 36 months | |
| External parties | *Example:* Repair network and loss adjusters at interface level | Partner internal systems | |
| [Dimension] | [In scope] | [Out of scope] | [Notes] |

### 6.1 Questions the sponsor needs answered

List the decisions the sponsor must be able to make at the end of the
architecture work. These become the backbone of the Statement of
Architecture Work.

1. *Example:* Should the claims platform be replaced, extended or bought
   as a service, and in what order relative to the customer data work?
2. *Example:* Where should the master customer record live, and which
   systems must change to use it?
3. *Example:* Can the legacy CRM be retired before its support ends, and
   what does that require?
4. *Example:* What is the realistic cost and sequence of the change within
   the capital envelope?
5. [Question]

## 7. Stakeholders

<!-- Guidance: Name the people and groups who will be affected, must approve, or hold knowledge the architects need. This is an initial list; Phase A builds the full stakeholder map. Pitfall: forgetting assurance functions (security, privacy, risk, audit) until the first board gate. -->

| ID | Stakeholder | Interest in the request | Expected involvement |
|---|---|---|---|
| SH-01 *(Example)* | Chief Operating Officer | Sponsor; owns claims cycle time and cost | Steering, approvals |
| SH-02 *(Example)* | Head of Claims | Business owner; staff and process impact | Weekly working sessions |
| SH-03 *(Example)* | Chief Information Security Officer | Data protection and third-party risk | Review at each gate |
| SH-04 *(Example)* | Data Protection Officer | Lawful basis, retention, data subject rights | Privacy checkpoints |
| SH-05 *(Example)* | Head of IT Operations | Supportability, run cost, skills | Architecture reviews |
| SH-06 *(Example)* | Claims handlers | Daily users of the change | User research and demos |
| [SH-nn] | [Stakeholder] | [Interest] | [Involvement] |

Use the stakeholder register (`project/stakeholder-register`) when the
list grows beyond a dozen entries.

## 8. Budget, resources and timeline

<!-- Guidance: Separate the money for the architecture work from the money for the change it will plan. Say whether each figure is approved or indicative. Give a requested end date and the business event that drives it. Pitfall: a deadline with no reason, which makes it impossible to judge whether scope or date should give way. -->

### 8.1 Funding

| Item | Amount | Status | Source |
|---|---|---|---|
| Architecture work (Phases A to F) | *Example:* Up to USD 320,000 | Approved | Cost centre CC-4410 |
| Resulting change (delivery) | *Example:* Up to USD 2.5 million capital | Indicative; final approval after the roadmap | Capital plan line CAP-27-12 |
| Contingency for the architecture work | *Example:* About 10%, included in the USD 320,000 and released by the sponsor | Approved | Cost centre CC-4410 |
| [Item] | [Amount] | [Approved / Indicative] | [Source] |

### 8.2 People the business will provide

| Role | Person or team | Time available | Period |
|---|---|---|---|
| *Example:* Claims process experts | Two senior handlers | Two days per week each | Weeks 1 to 10 |
| *Example:* Finance analyst | Claims finance team | Half a day per week | Weeks 1 to 15 |
| *Example:* Data steward for customer data | Customer operations | One day per week | Weeks 3 to 12 |
| [Role] | [Name or team] | [Time] | [Period] |

### 8.3 Timeline

| Milestone | Requested date | Driving event |
|---|---|---|
| Architecture work starts | *Example:* YYYY-MM-DD | Budget available from the new quarter |
| Target architecture and roadmap ready for investment decision | *Example:* YYYY-MM-DD | Capital committee meets on this date |
| Legacy CRM retired | *Example:* YYYY-MM-DD | End of vendor support |
| [Milestone] | YYYY-MM-DD | [Event] |

## 9. Existing architecture and related work

<!-- Guidance: Point to what already exists so the engagement does not rediscover it: current models, prior studies, reference architectures, live projects and decisions already taken. Questions to answer: what does the repository already hold for this area, and which other initiatives touch the same systems or people? Pitfall: two engagements modelling the same customer domain in parallel without knowing about each other. -->

| Item | Type | Location | Relevance |
|---|---|---|---|
| *Example:* Group strategic architecture SA-2026 | Strategic architecture | [Repository path] | This work must conform to it |
| *Example:* Claims capability map, version 2.1 | Business architecture | [Repository path] | Starting point for Phase B (`architecture/business-capability-map`) |
| *Example:* Customer data study (YYYY) | Prior study | [Link] | Profiling of duplicate records in policy systems |
| *Example:* Distribution segment architecture engagement | Parallel engagement | [Link] | Shares the customer domain; agree ownership early |
| *Example:* Cloud landing zone design | Platform | [Link] | Target hosting option (`architecture/landing-zone-design`) |
| [Item] | [Type] | [Location] | [Relevance] |

### 9.1 Decisions already taken

Record decisions that the engagement must treat as fixed, with their
reference. *Example:* the group has decided that all new customer-facing
services run on the approved cloud platform (decision record ADR-004). If
the sponsor wants any of these reopened, say so here so the board can
decide whether that is in scope.

## 10. Expected outputs and success

<!-- Guidance: Say what the sponsor expects to receive and how they will judge the work a success. Outputs are documents and decisions; success is what changes in the business because of them. Pitfall: expecting delivery outputs (a working portal) from an architecture engagement that only plans the change. -->

### 10.1 Expected outputs

| Output | Purpose for the sponsor | Expected by |
|---|---|---|
| *Example:* Architecture Vision and Statement of Architecture Work | Agree direction, scope, plan and acceptance | Week 3 |
| *Example:* Architecture Definition Document | Baseline, target and gaps per domain | Week 11 |
| *Example:* Architecture Requirements Specification | Measurable requirements for delivery projects | Week 11 |
| *Example:* Architecture Roadmap with Transition Architectures | Sequence, cost and value per increment | Week 15 |
| *Example:* Investment paper input | Figures for the capital committee | Week 15 |
| [Output] | [Purpose] | [Week or date] |

### 10.2 What success looks like

*Example:* The capital committee can approve the first two work packages
with confidence in cost and sequence; the claims, data and IT leaders
agree on where the customer master lives; and the legacy CRM retirement
has a dated plan that the risk function accepts.

## 11. Risks and urgency

<!-- Guidance: Give the intake team what it needs to prioritise: how urgent the request is, what makes it hard, and what could stop the architecture work itself. Keep project delivery risks for later; these are risks to the engagement. Pitfall: marking everything urgent, which teaches the board to ignore urgency. -->

### 11.1 Urgency

| Factor | Rating | Reason |
|---|---|---|
| Regulatory or legal deadline | *Example:* Medium | Supervisory review of outsourcing planned for next year |
| Contract or support deadline | *Example:* High | Legacy CRM support ends and policy contract renews within 18 months |
| Financial impact of delay | *Example:* Medium | Cost target slips by one year for each year of delay |
| Customer or reputational impact | *Example:* High | Complaint volumes rising |
| [Factor] | [High / Medium / Low] | [Reason] |

### 11.2 Known risks to the architecture work

| ID | Risk | Likelihood | Impact | Suggested response |
|---|---|---|---|---|
| RRK-01 *(Example)* | Business experts unavailable during the regulatory remediation | Medium | High | Agree release dates with the Head of Claims before Phase A |
| RRK-02 *(Example)* | Ownership of the customer domain disputed with the distribution segment | High | Medium | Board to rule on ownership at intake |
| RRK-03 *(Example)* | Data needed for the baseline is held by a vendor and slow to obtain | Medium | Medium | Request data extracts in week 1 |
| [RRK-nn] | [Risk] | [H / M / L] | [H / M / L] | [Response] |

## 12. Intake assessment and decision

<!-- Guidance: The architecture function completes this section. Assess the request against fixed criteria so that decisions are consistent and explainable, then record one of the standard outcomes with its reasons. Pitfall: accepting every request because declining feels unhelpful; a clear "defer" or "merge" protects the engagements already under way. -->

### 12.1 Completeness check

| Check | Result | Comment |
|---|---|---|
| Sponsor with budget authority named and committed | [Yes / No] | |
| Problem stated with evidence | [Yes / No] | |
| Goals and drivers listed with IDs | [Yes / No] | |
| Constraints and their sources recorded | [Yes / No] | |
| Funding for the architecture work approved | [Yes / No] | |
| Business people and their time identified | [Yes / No] | |
| Related work and prior decisions listed | [Yes / No] | |
| Questions the sponsor needs answered listed | [Yes / No] | |

A request with two or more "No" answers is returned to the requester
before scoring.

### 12.2 Assessment criteria and score

Score each criterion from 1 (low) to 5 (high). The criteria, weights and
bands are set in section 5.4 of the Architecture Board charter
(`architecture/architecture-governance-charter`), with a description of
what a top score looks like for each; do not change them per request.

| Criterion | Weight *(Example)* | Score | Weighted | Evidence |
|---|---|---|---|---|
| Strategic alignment | 25% | *Example:* 5 | 1.25 | Section 3.2 |
| Business value at stake | 20% | *Example:* 4 | 0.80 | Sections 3.1, 4.2 |
| Urgency | 15% | *Example:* 4 | 0.60 | Section 11.1 |
| Architecture significance (cross-domain, cross-unit, long life) | 20% | *Example:* 5 | 1.00 | Sections 6, 9 |
| Readiness (sponsor, funding, people) | 20% | *Example:* 3 | 0.60 | Sections 2, 8 |
| **Total** | 100% | | **4.25 of 5** | |

*Example interpretation:* a total of 4.0 or more is a candidate for a full
engagement; 2.5 to 3.9 suggests a lighter engagement or a solution-level
review; below 2.5 is usually declined or handled outside the architecture
function. These are the bands in charter section 5.4; change them there,
not here.

### 12.3 Decision outcomes

| Outcome | Use when | What happens next |
|---|---|---|
| Accept | Complete, significant and ready | Lead architect assigned; Phase A starts |
| Accept with changes | Worth doing but scope, timing or level must change | Changes recorded in section 12.4; requester confirms |
| Merge | Overlaps an engagement already under way | Request folded into that engagement's scope through its change procedure |
| Defer | Worth doing but capacity or readiness is missing now | New intake date set; conditions to meet listed |
| Redirect | Does not need enterprise or segment architecture | Routed to a solution architecture review (`architecture/architecture-review-request`) or to the project |
| Decline | Not aligned or not justified | Reasons given in writing to the sponsor |

### 12.4 Decision record

| Field | Value |
|---|---|
| Decision | *Example:* Accept with changes |
| Decided by | *Example:* Architecture Board, outcome record ARB-2026-024 |
| Decision date | YYYY-MM-DD |
| Changes to the request | *Example:* Breadth narrowed to retail motor and home claims; commercial claims to follow as a separate request after the target is approved |
| Conditions | *Example:* C1: the board rules that the customer domain model is owned by this engagement and reused by the distribution segment. C2: the Head of Claims confirms expert release dates before kick-off |
| Assigned lead architect | [@lead-architect] |
| Architecture capability used | *Example:* Enterprise architecture team, claims and customer domain |
| Reasons | *Example:* Score 4.25; high strategic alignment and a hard support deadline; readiness lowered by the parallel regulatory remediation |

```mermaid
flowchart LR
  S["Request submitted"] --> C{"Complete?"}
  C -->|No| R["Returned to requester"]
  R --> S
  C -->|Yes| A["Scored against criteria"]
  A --> B{"Board decision"}
  B -->|Accept or accept with changes| V["Phase A: Architecture Vision<br/>and Statement of Architecture Work"]
  B -->|Merge| M["Change to existing engagement"]
  B -->|Defer| D["Re-submit at new intake date"]
  B -->|Redirect| P["Solution review or project"]
  B -->|Decline| X["Written reasons to sponsor"]
```

## 13. Next steps and hand-off

<!-- Guidance: Turn an accepted request into a running engagement within days, not weeks. List the first actions, owners and dates, and the documents that will answer this request. Pitfall: an accepted request that waits a month for a lead architect while the sponsor's urgency fades. -->

| Step | Owner | Due | Output |
|---|---|---|---|
| 1. Confirm the lead architect and core team | [@chief-architect] | *Example:* Decision date plus 5 working days | Named team |
| 2. Meet the sponsor to confirm changes and conditions | [@lead-architect] | Decision date plus 10 working days | Confirmed scope position |
| 3. Hold the Phase A kick-off with key stakeholders | [@lead-architect] | YYYY-MM-DD | Stakeholder map, concerns |
| 4. Draft the Architecture Vision | [@lead-architect] | YYYY-MM-DD | `architecture/togaf-architecture-vision` |
| 5. Draft and agree the Statement of Architecture Work | [@lead-architect] | YYYY-MM-DD | `architecture/statement-of-architecture-work` |
| 6. Register the engagement in the architecture portfolio | [@ea-office] | YYYY-MM-DD | Portfolio entry |
| [Step] | [@owner] | YYYY-MM-DD | [Output] |

Each later deliverable cites this request ID in its Document control so
that the chain from request to vision, statement of work, definition and
roadmap can be followed in the repository. If the scope changes
materially after acceptance, raise an Architecture Change Request
(`architecture/architecture-change-request`) rather than editing this
request.

### 13.1 Intake checklist for the architecture function

- [ ] Request ID allocated and stored in the repository
- [ ] Overlap with running engagements checked in the portfolio
- [ ] Applicable principles, standards and reference architectures listed
- [ ] Decision recorded with reasons and conditions
- [ ] Sponsor informed in writing within two working days of the decision
- [ ] Lead architect named, or a deferral date set

## 14. Glossary and references

<!-- Guidance: Define terms a business sponsor may not know and list the documents the request relies on. -->

### 14.1 Glossary

| Term | Meaning in this document |
|---|---|
| ADM | Architecture Development Method, the iterative cycle of phases at the centre of the TOGAF Standard |
| Architecture engagement | A bounded piece of architecture work with its own sponsor, scope, plan and deliverables |
| Architecture Board | The governance body that decides on architecture work, compliance and exceptions |
| Intake | The assessment of a new request before any architecture work is committed |
| Preliminary Phase | The ADM phase that prepares the organisation's architecture capability, principles and governance |
| Sponsor | The accountable executive who funds the work and accepts its results |
| Statement of Architecture Work | The agreement that sets scope, approach, plan and acceptance for an accepted request |
| [Term] | [Meaning] |

### 14.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 | Architecture Vision (`architecture/togaf-architecture-vision`) | [x.y] |
| REF-03 | Statement of Architecture Work (`architecture/statement-of-architecture-work`) | [x.y] |
| REF-04 | Architecture Board Charter (`architecture/architecture-governance-charter`) | [x.y] |
| REF-05 | Architecture Principles Catalogue (`architecture/architecture-principles`) | [x.y] |
| REF-06 | Business case for the resulting change (`business/business-case`) | [x.y] |
| REF-07 | [Corporate strategy or business plan] | [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 Request for Architecture Work that
triggers a cycle of the Architecture Development Method, following the
Preliminary Phase and leading into Phase A. 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 intake criteria, weights and
decision outcomes 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.