2.1 The Architecture Development Method (ADM) Cycle & Requirements Management
Key Takeaways
- The Architecture Development Method (ADM) is a tested, iterative process for developing enterprise architectures that forms the core of the TOGAF Standard.
- The ADM consists of 10 distinct phases: the Preliminary Phase, Phases A through H, and the central, continuous Requirements Management phase.
- Requirements Management operates at the center of the ADM wheel, actively interfacing with every phase to store, evaluate, and update architectural requirements dynamically.
- The ADM is inherently iterative, supporting iteration across phases, within a single phase, between iterations, and across architecture scope levels.
- Requirements are never statically set at the beginning; rather, business, technical, and compliance requirements evolve continuously as architectures mature.
2.1 The Architecture Development Method (ADM) Cycle & Requirements Management
The Architecture Development Method (ADM) is the heart of the TOGAF Standard. Developed and refined through decades of contribution from enterprise architecture (EA) practitioners worldwide, the ADM provides a tested, repeatable, and adaptable process for developing architectures that meet the strategic and operational needs of an enterprise.
Rather than serving as a rigid, linear formula, the ADM is designed as a continuous, dynamic cycle of phases adaptable to organizational culture, project scale, and enterprise maturity.
Overview of the 10 ADM Phases
The TOGAF ADM consists of 10 distinct phases, organized in a circular "wheel" around a central, continuous Requirements Management core. Each phase has explicit objectives, inputs, steps, and deliverables.
1. Preliminary Phase: Framework & Capability Setup
The Preliminary Phase initializes the architecture environment. It answers the fundamental questions of where, why, who, and how enterprise architecture will be conducted. Key activities include defining the enterprise scope, identifying key stakeholders, establishing Architecture Principles, setting up the Architecture Board, and tailoring the ADM for the organization.
2. Phase A: Architecture Vision
Phase A initiates a specific architecture development cycle. Its primary objective is to define the scope, constraints, and strategic goals of the effort. Architects define high-level business goals, identify key stakeholders, assess organizational readiness for transformation, draft the initial Architecture Vision, and secure formal executive approval through the Statement of Architecture Work.
3. Phase B: Business Architecture
Business Architecture is the foundational domain phase. It describes how the enterprise operates to achieve its strategic goals. Phase B develops the Baseline Business Architecture and Target Business Architecture, covering business strategy, governance, organizational structures, business capabilities, value streams, and business processes. Gap analysis is performed to identify what must change.
4. Phase C: Information Systems Architectures
Phase C addresses the technical information assets supporting the business. It is divided into two distinct sub-domains:
- Data Architecture: Defines the enterprise's logical and physical data assets, data governance structures, data management models, and data migration strategies.
- Application Architecture: Defines the logical components of software applications, application services, system interfaces, and application interactions required to process data and support business capabilities.
5. Phase D: Technology Architecture
Phase D defines the technology infrastructure required to support the Information Systems and Business architectures. This includes hardware platforms, operating systems, cloud environments, networking infrastructure, middleware, security appliances, and technology standards. Architects map candidate technology components to application and data requirements while conducting gap analysis.
6. Phase E: Opportunities & Solutions
Phase E marks the shift from architecture definition to initial implementation planning. Architects evaluate the gaps identified across Phases B, C, and D, grouping them into logical work packages and candidate Solution Building Blocks (SBBs). Phase E outlines major implementation projects, assesses dependencies, and constructs an initial strategy for transitioning from the baseline to target states.
7. Phase F: Migration Planning
Phase F converts the initial strategy from Phase E into a detailed, actionable Implementation and Migration Plan. Working closely with business sponsors, portfolio managers, and project management offices (PMOs), architects conduct cost-benefit analyses, risk assessments, and resource availability evaluations to prioritize work packages and define formal Transition Architectures.
8. Phase G: Implementation Governance
Phase G ensures that implementation projects conform strictly to the target architecture. Architects establish Architecture Contracts with project implementation teams, conduct formal architecture compliance reviews, guide solution development, and manage architectural dispensations or change requests during construction.
9. Phase H: Architecture Change Management
Phase H establishes a continuous monitoring process to keep the architecture current and aligned with business strategy. It monitors changes in technology standards, business environment drivers, and regulatory frameworks. Phase H assesses whether proposed changes require minor maintenance updates or warrant initiating a new ADM cycle.
10. Requirements Management (Central Core)
Operating at the absolute center of the ADM wheel, Requirements Management is a continuous process that dynamically interfaces with every phase of the ADM. It ensures that business, technical, and operational requirements are captured, evaluated, stored, prioritized, and tracked across the complete architecture lifecycle.
Summary of ADM Phases & Core Objectives
| Phase | Phase Name | Primary Focus & Core Objectives | Key Deliverables |
|---|---|---|---|
| Prelim | Preliminary Phase | Prepare organization; establish scope, principles, and governance. | Organizational Model for EA, Architecture Principles, Tailored ADM |
| Phase A | Architecture Vision | Define project scope, strategic intent, and secure executive approval. | Statement of Architecture Work, Architecture Vision, Stakeholder Map |
| Phase B | Business Architecture | Model business capabilities, organization, value streams, and processes. | Business Architecture Description, Gap Analysis Results |
| Phase C | Information Systems | Model Data and Application architectures and integrations. | Data & Application Architecture Descriptions, Interoperability Matrix |
| Phase D | Technology Architecture | Model infrastructure, platform services, hardware, and networks. | Technology Architecture Description, Technology Standards Matrix |
| Phase E | Opportunities & Solutions | Group gaps into work packages; formulate initial migration strategy. | Consolidated Gap Analysis, Candidate Architecture Roadmap |
| Phase F | Migration Planning | Finalize detailed Implementation Plan and Transition Architectures. | Implementation and Migration Plan, Finalized Transition Architectures |
| Phase G | Implementation Gov | Oversee implementation projects; enforce architectural compliance. | Architecture Contracts, Compliance Assessments, Dispensations |
| Phase H | Change Management | Continuously monitor drivers; manage architecture change requests. | Architecture Change Requests, Updated Architecture Framework |
| Central | Requirements Mgmt | Dynamically capture, store, prioritize, and drive requirements. | Architecture Requirements Specification, Requirements Impact Assessment |
The Central Role of Requirements Management
Unlike traditional linear development models where requirements are gathered once at the beginning, TOGAF places Requirements Management at the center of the ADM cycle. Requirements are not static; they evolve as business goals shift, new technical constraints emerge, and stakeholder feedback is gathered.
Key Characteristics of Requirements Management in ADM:
- Continuous Operation: Requirements Management never stops. It runs concurrently with all ADM phases.
- Phase Interfacing: Every ADM phase writes to and reads from the Requirements Repository. For instance, Phase A identifies business requirements, Phase B-D refine technical requirements, Phase E evaluates implementation constraints, and Phase G validates requirement fulfillment.
- Change Impact Assessment: When a new requirement is submitted during Phase D or G, the Requirements Management process assesses its impact across all previously approved architecture models before allowing phase progression.
- Traceability: Maintains complete line-of-sight from high-level business goals to granular software services and technology infrastructure.
Iterative Execution of the ADM
The ADM wheel is intentionally designed to support iteration. Enterprise architectures cannot be delivered in a single monolithic effort. Architects apply iteration across multiple dimensions:
- Looping Back: Returning to earlier phases when downstream phases reveal new constraints (e.g., Phase D technology constraints requiring an adjustment to Phase B business processes).
- Phased Iteration: Running small ADM cycles for distinct business units or sub-domains while maintaining strategic alignment.
- Lifecycle Iteration: Continuously cycling through Phases A to H as the enterprise matures.
Which phase of the TOGAF ADM operates continuously at the center of the wheel, actively interfacing with all other phases?
During which ADM phase are gaps across business, data, application, and technology domains first consolidated into logical work packages and candidate Solution Building Blocks (SBBs)?
What is the primary objective of Phase H (Architecture Change Management) in the TOGAF ADM cycle?