Key takeaways
- The ADM graphic shows information flow, not a mandatory sequence.
- Reading it as a waterfall is the most common misinterpretation.
- Deliverables are born early and grow: ADD from A, roadmap from B to D.
- Phase F finalizes; Phases G and H govern and evolve.
- A Request for Architecture Work from H can start a new cycle.
A flow diagram, not a waterfall
The practitioners’ guide presents the ADM as a logical method that groups related steps to clarify how activities relate and how information circulates. The iconic graphic is a stylized path: it shows the essential information passing from one phase to another, not the order in which activities must follow each other.
The classic mistake is to read it as a waterfall model. The standard is explicit: the ADM imposes neither a phase sequence nor a waterfall approach. It is better seen as a reference model of what must be done to deliver solutions in an architected way. A late finding can therefore send work back to an earlier phase, and Requirements Management feeds every phase continuously.
Who creates what: key deliverables by phase
The Study Guide associates each phase with the deliverables typically created, used, or enriched there. Here is a condensed reading.
- Preliminary: Architecture Principles; Business Principles, Goals, and Drivers; Request for Architecture Work
- Phase A: Statement of Architecture Work, Architecture Vision, Communications Plan, Capability Assessment, first version of the Architecture Definition Document
- Phases B, C, D: enriched Architecture Definition Document, Architecture Requirements Specification, candidate Architecture Roadmap components
- Phase E: Architecture Definition Document with transitions, Architecture Roadmap, initial Implementation and Migration Plan, Implementation Governance Model
- Phase F: finalized Architecture Roadmap, Implementation and Migration Plan, and Implementation Governance Model
- Phases G and H: Implementation Governance Model, Architecture Contracts, Change Requests, Compliance Assessments; in H, Request for Architecture Work and Requirements Impact Assessment
- Requirements Management: Architecture Requirements Specification and Requirements Impact Assessment
Four threads to follow
Rather than memorizing a table, follow a few deliverables that run through the cycle. They show how information accumulates and then transforms.
- Architecture Definition Document: created in A, enriched in B to D, extended with transitions in E, finalized in F, updated after implementation
- Architecture Roadmap: candidate components in B to D, first complete version in E, finalized in F
- Implementation and Migration Plan: initial in E, detailed in F, applied under governance in G
- Change Request: raised in G or from the context, assessed in H, possibly leading to a new Request for Architecture Work that restarts Phase A
TERMS TO KNOW
The terms, in context.
- Information flow
- The movement of deliverables and knowledge between phases, depicted by the ADM graphic.
- Architecture Definition Document
- A qualitative deliverable covering all domains and the Baseline, Transition, and Target states.
- Request for Architecture Work
- A request that triggers a cycle; issued from the Preliminary Phase or Phase H.
- Change Request
- A request to modify the architecture, handled in Phases G and H.
- Capability Assessment
- An assessment of baseline and target capabilities; carried out in A and updated in E.