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.

Document control

Approvals

Revision history

Contents

1. Request summary
2. Sponsor and requesting organisation
3. Problem, opportunity and mission alignment
4. Business goals and drivers
5. Constraints and assumptions
6. Requested scope
7. Stakeholders
8. Budget, resources and timeline
9. Existing architecture and related work
10. Expected outputs and success
11. Risks and urgency
12. Intake assessment and decision
13. Next steps and hand-off
14. Glossary and references

1. Request summary

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

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

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

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

4.1 Drivers

4.2 Goals

5. Constraints and assumptions

5.1 Constraints

5.2 Assumptions

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

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

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

8. Budget, resources and timeline

8.1 Funding

8.2 People the business will provide

8.3 Timeline

9. Existing architecture and related work

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

10.1 Expected outputs

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

11.1 Urgency

11.2 Known risks to the architecture work

12. Intake assessment and decision

12.1 Completeness check

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.

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

12.4 Decision record

13. Next steps and hand-off

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

14.1 Glossary

14.2 References

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.