4.2 Draft vs. Approved Deliverables & the Iterative ADM
Key Takeaways
- In the TOGAF ADM, draft documents are under development and have not undergone any formal review and approval process.
- Approved documents have been reviewed and approved, and only approved architecture should govern change.
- The TOGAF Standard, 10th Edition labels deliverable status as draft or approved instead of the 0.1 and 1.0 version numbers used in TOGAF 9.
- The ADM is iterative over the whole process, between phases, and within phases.
- The four iteration cycles are Architecture Capability, Architecture Development (Phases B–D), Transition Planning (Phases E–F), and Architecture Governance (Phases G–H).
4.2 Draft vs. Approved Deliverables & the Iterative ADM
Two Foundation learning outcomes are covered here: describe the difference between "draft" and "approved" deliverables, and explain the iterative approach of the ADM. Both reflect the same reality — architecture is refined in stages, and its outputs mature as stakeholders review and agree them.
Draft and Approved Deliverables
In the ADM:
- Draft — documents that are under development and have not undergone any formal review and approval process.
- Approved — documents that have been reviewed and approved by the appropriate stakeholders.
This matters because a deliverable is, by definition, contractually specified and formally reviewed, agreed, and signed off. Until that review and sign-off happens, a work product is only a draft and should not be treated as authoritative for governing change.
Edition note: TOGAF 9 editions labeled output status with version numbers (for example 0.1 for an early draft and 1.0 for an approved version). The 10th Edition uses the plain labels draft and approved, so answer exam questions using those words.
How Deliverables Mature Across the ADM
| Deliverable | Status as the ADM progresses |
|---|---|
| Statement of Architecture Work | Developed in Phase A and approved at the end of Phase A (the step "Develop Statement of Architecture Work; Secure Approval"); updated later if needed |
| Architecture Definition Document | Begins as a draft in Phase A with high-level baseline and target views; draft domain content is added in Phases B, C, and D; updated in Phase E and finalized in Phase F |
| Architecture Requirements Specification | Draft content is developed in Phases B–D and refined in Phases E and F |
| Architecture Roadmap | Candidate components come from Phases B–D; the initial complete version is created in Phase E; it is finalized in Phase F |
| Implementation and Migration Plan | A draft with the implementation and migration strategy is produced in Phase E; it is completed in Phase F |
Architecture States and Approval
The 10th Edition also discusses managing multiple architecture states:
- Candidate — what the EA team has developed but has not yet been approved for a status sufficient to govern change
- Current (Baseline) — the reference for all change
- Transition — partially realized targets between current and target
- Target — what stakeholders have approved
The draft/approved distinction and the candidate/target distinction make the same point: only approved architecture should govern change.
Why the ADM Is Iterative
The ADM is iterative over the whole process, between phases, and within phases. The reasons follow from the key points in Section 4.1:
- Scope is re-decided each time. Each iteration takes a fresh decision on breadth, level of detail, time period, and assets to re-use.
- Understanding improves. Validating results against expectations often reveals that earlier outputs need refinement.
- Domains affect each other. A technology constraint found in Phase D may require changes to application or business models.
- Value is delivered incrementally. Transition Architectures allow value to be realized in stages rather than all at once.
- Change never stops. Phase H feeds new requirements and new cycles back into the ADM.
The Four Iteration Cycles
Applying the ADM groups iteration into four cycles:
| Iteration cycle | Phases involved | What it supports |
|---|---|---|
| Architecture Capability iterations | Preliminary and Phase A | Creating and evolving the required Architecture Capability, including mobilizing architecture activity by establishing or adjusting approach, principles, scope, vision, and governance |
| Architecture Development iterations | Phases B, C, and D | Creating architecture content by cycling through, or integrating, the Business, Information Systems, and Technology Architecture phases |
| Transition Planning iterations | Phases E and F | Creating formal change roadmaps for a defined architecture |
| Architecture Governance iterations | Phases G and H | Governing change activity progressing toward a defined Target Architecture |
Requirements Management supports all four cycles.
Baseline First or Target First
Within Architecture Development iterations, TOGAF describes two approaches:
| Approach | How it works | When it helps |
|---|---|---|
| Baseline First | Assess the baseline landscape first to identify problem areas and improvement opportunities, then define the target | Most suitable when the baseline is complex, not clearly understood, or not agreed upon |
| Target First | Elaborate the target solution in detail first, then map it back to the baseline to identify change activity | Suitable when a target state is agreed at a high level and the enterprise wishes to transition effectively to the target model |
Scenario: Iterating Back
An insurer is in Phase D when architects discover the chosen hosting approach cannot meet data-residency rules for two countries. They iterate back to Phase C to adjust the application deployment model and to Phase B to confirm the affected business services, update the draft ADD, and record the changed requirement through Requirements Management. Only after stakeholder review is the revised architecture approved for use in Phase E planning.
Common Exam Pitfalls
- Using version numbers as the 10th Edition answer. The current terms are "draft" and "approved."
- Assuming "draft" means low quality. Draft simply means not yet formally reviewed and approved.
- Naming the wrong iteration cycle. Phases B–D form Architecture Development iterations; E–F are Transition Planning; G–H are Architecture Governance; Preliminary and A are Architecture Capability.
- Thinking iteration means restarting the whole ADM. Iteration can occur within a phase, between phases, or across cycles.
In the TOGAF ADM, what are documents that are still under development and have not undergone any formal review and approval process called?
Which iteration cycle involves cycling through or integrating Phases B, C, and D to create architecture content?
At which levels does the TOGAF Standard say the ADM is iterative?
An architecture team has developed a new target design that has not yet been approved for a status sufficient to govern change. How does the 10th Edition describe this architecture state?