TL;DR
The Request for Architecture Work is the formal trigger to start an ADM cycle. It is a high-level sponsor request that tells the architecture team what problem to address, under what constraints, and with what expected outcomes.
Where this fits in ADM
This deliverable sits at the handoff between setup and execution:
- Preliminary Phase prepares capability and governance
- Request for Architecture Work starts a specific architecture engagement
- Phase A uses it to shape Architecture Vision and the Statement of Architecture Work
flowchart LR P["Preliminary Phase"] -->|"produces"| RAW["Request for Architecture Work"] RAW -->|"triggers"| A["Phase A: Architecture Vision"] A -->|"produces"| SAW["Statement of Architecture Work"]
What it is
The Request for Architecture Work is a sponsor-to-architecture-team request — essentially the “official start signal” for architecture work.
Keep it high-level and decision-oriented, not detailed design.
Typical contents
In practice, it usually covers:
- purpose of the request
- business imperative and mission context
- goals, strategic direction, and expected outcomes
- key constraints (budget, timeline, policy, risk limits)
- scope context (business system, IT system, architecture context)
- organization context (sponsor, stakeholders, resources, ownership)
Some TOGAF templates present this in sections such as:
- Purpose
- Request
- Business Imperative
- Key Constraints
- Additional Information
How it is used
Phase A uses the Request for Architecture Work to:
- establish the architecture project
- align stakeholders and concerns
- frame scope and constraints
- prepare the Statement of Architecture Work
It can also stay relevant as a reference input in later phases when scope, assumptions, or priorities come up for review.
Where it can come from
Common triggers include:
- planning/mandate from Preliminary outputs
- approved architecture change requests
- terms of reference linked to migration planning decisions
Practical quality checklist
Before accepting the request into Phase A, check:
- sponsor and decision authority are clear
- business drivers and outcomes are specific enough
- constraints are explicit (time, budget, compliance, resources)
- initial scope boundary is clear enough to proceed
- no hidden contradiction with approved architecture principles
Common mistakes
- writing solution detail too early
- vague business imperative (“modernize” without measurable outcomes)
- missing constraint clarity
- no named sponsor/owner
Exam note
- It is the formal trigger that starts architecture work for an engagement.
- It is high-level and sponsor-driven.
- It is a key early input to Phase A Architecture Vision.