12.4 ADM Deliverables II: From Architecture Definition to Change
Key Takeaways
- The Architecture Definition Document is the deliverable container for core architectural artifacts, spanning all architecture domains and all relevant states.
- The Architecture Requirements Specification provides quantitative statements of what an implementation project must do to comply with the architecture.
- The Architecture Roadmap lists work packages on a timeline showing progression from the Baseline Architecture to the Target Architecture.
- The Implementation Governance Model, created in Phase F, plans how the Transition Architecture will be governed through implementation.
- A Change Request is used to request a dispensation or to initiate an architecture change when the original architecture proves unsuitable or insufficient.
12.4 ADM Deliverables II: From Architecture Definition to Change
This section covers the remaining nine of the sixteen deliverables in the Foundation syllabus — those created from Phase B onward and by Requirements Management. For each, learn its purpose, typical contents, and the phases that create and consume it.
Summary Table
| Deliverable | Created in | Consumed in |
|---|---|---|
| Architecture Definition Document | Draft in Phase A; developed in Phases B–D; updated in E; finalized in F | Phases E–H |
| Architecture Requirements Specification | Phases B–D; updated in E and F; maintained through Requirements Management | Phases E–H |
| Architecture Roadmap | Components in Phases B–D; initial complete version in Phase E; finalized in Phase F | Phases F–H |
| Implementation and Migration Plan | Draft in Phase E; completed in Phase F | Phase G |
| Implementation Governance Model | Phase F | Phase G |
| Architecture Contract | Phase G (signed); updated in Phase H if necessary | Phases G–H |
| Compliance Assessment | Phase G; updated in Phase H if necessary | Phase H |
| Change Request | Phase G (and Phase F lessons learned); handled in Phase H | Phase H; Requirements Management |
| Requirements Impact Assessment | Requirements Management | The ADM phases affected by changed requirements |
Architecture Definition Document (ADD)
Purpose: The deliverable container for the core architectural artifacts created during a project and for important related information. It spans all architecture domains (business, data, application, and technology) and examines all relevant states of the architecture (baseline, transition, and target). It is a companion to the Architecture Requirements Specification.
Typical contents: scope; goals, objectives, and constraints; Architecture Principles; Baseline Architecture; Architecture Models for each state (business, data, application, technology); rationale and justification for the architectural approach; mapping to the Architecture Repository; gap analysis; impact assessment; Transition Architecture.
Architecture Requirements Specification (ARS)
Purpose: Provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. It typically forms a major component of an implementation contract or a more detailed Architecture Definition.
Typical contents: success measures; architecture requirements; business service contracts; application service contracts; implementation guidelines; implementation specifications; implementation standards; interoperability requirements; IT Service Management requirements; constraints; assumptions.
Architecture Roadmap
Purpose: Lists the individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. It highlights individual work packages' potential business value at each stage and identifies Transition Architectures where needed.
Typical contents: work package portfolio (description, functional requirements, dependencies, relationship to opportunity, relationship to Architecture Definition Document and Architecture Requirements Specification, business value); implementation factor assessment and deduction matrix; consolidated gaps, solutions, and dependency matrix; Transition Architectures; implementation recommendations (criteria measures of effectiveness, risks and issues, solution building blocks).
Implementation and Migration Plan
Purpose: Provides a schedule of the projects that will realize the Target Architecture. It includes executable projects grouped into managed portfolios and programs, and makes clear the strategy for implementation and migration.
Typical contents: implementation and migration strategy (strategic implementation direction, approach, and sequencing); interactions with other management frameworks (methodology, scope of architecture work, relationships between frameworks); implementation plan and migration plan (projects, work package allocation, milestones and timing, work breakdown structure, resource requirements and costs).
Implementation Governance Model
Purpose: Once an architecture has been defined, it is necessary to plan how the Transition Architecture that implements the architecture will be governed through implementation. Where a governance process already exists, this model defines how architecture governance fits within it.
Typical contents: governance processes; governance organization structure; governance roles and responsibilities; governance checkpoints and success/failure criteria.
Architecture Contract
Purpose: Joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture, delivered through effective architecture governance (Section 11.3).
Typical contents of an Architecture Design and Development Contract: introduction and background; nature of the agreement; scope of the architecture; architecture and strategic principles and requirements; conformance requirements; architecture development and management process and roles; Target Architecture measures; defined phases of deliverables; prioritized joint workplan; time window(s); architecture delivery and business metrics.
Typical contents of a Business Users' Architecture Contract: introduction and background; nature of the agreement; scope; strategic requirements; conformance requirements; architecture adopters; time window; architecture business metrics; service architecture, including the Service-Level Agreement (SLA).
Compliance Assessment
Purpose: Once an architecture has been defined, it is necessary to govern implementation. Periodic compliance reviews of implementation projects provide a mechanism to review project progress and ensure that design and implementation are proceeding in line with the strategic and architectural objectives (Section 11.4).
Typical contents: overview of project progress and status; overview of project architecture and design; completed architecture checklists — for example hardware and operating system, software services and middleware, applications, information management, security, system management, system engineering, and methods and tools.
Change Request
Purpose: During implementation of an architecture, as more facts become known, it is possible that the original architecture definition and requirements are not suitable or not sufficient for a successful implementation. A Change Request is used to request a dispensation or to initiate an architecture change.
Typical contents: description of the proposed change; rationale for the proposed change; impact assessment of the proposed change (including reference to specific requirements, stakeholder priority of the requirements to date, phases to be revisited, phase to lead on requirements prioritization, results of phase investigations and revised priorities, recommendations on management of requirements); repository reference number.
Requirements Impact Assessment
Purpose: Throughout the ADM, new information is collected. As it is gathered, facts may come to light that invalidate existing aspects of the architecture. A Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes.
Typical contents: reference to specific requirements; stakeholder priority of the requirements to date; phases to be revisited; phase to lead on requirements prioritization; results of phase investigations and revised priorities; recommendations on management of requirements; repository reference number.
Telling Similar Deliverables Apart
| Pair | Key difference |
|---|---|
| ADD vs. ARS | The ADD contains the architecture itself across domains and states; the ARS states quantitatively what implementation projects must do to comply |
| Architecture Roadmap vs. Implementation and Migration Plan | The roadmap sequences work packages and Transition Architectures on a timeline; the plan schedules the executable projects, portfolios, and programs that deliver them |
| Implementation Governance Model vs. Architecture Contract | The model defines how implementation will be governed (processes, structure, roles, checkpoints); the contract is the agreement with those who deliver |
| Compliance Assessment vs. Change Request | The assessment reports whether a project conforms; the Change Request asks for a dispensation or an architecture change |
| Change Request vs. Requirements Impact Assessment | The Change Request proposes a change; the Requirements Impact Assessment evaluates what changed requirements mean for the architecture |
Common Exam Pitfalls
- Treating the ADD as a single-domain document. It spans all domains and all relevant states.
- Confusing the ARS with the ADD. The ARS contains quantitative statements of what implementation must do to comply.
- Placing the Implementation Governance Model in Phase G. It is created in Phase F and used in Phase G.
- Forgetting that a Change Request can request a dispensation. It can either request a dispensation or initiate an architecture change.
Which deliverable provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture?
What is the purpose of the Implementation Governance Model?
Which deliverable spans all architecture domains and examines all relevant states of the architecture: baseline, transition, and target?
During implementation, a team finds the architecture definition insufficient and asks for either a dispensation or a change to the architecture. Which deliverable do they use?
You've completed this section
Continue exploring other exams