What is the ADM?
The Architecture Development Method (ADM) is the core of TOGAF. It's an iterative, step-by-step approach to developing and managing enterprise architecture. Think of it as a roadmap for transforming your organization's architecture from current state to target state.
The ADM Cycle Overview
The ADM consists of a Preliminary Phase plus eight main phases arranged in a cycle:
- Preliminary Phase: Framework and Principles
- Phase A: Architecture Vision
- Phase B: Business Architecture
- Phase C: Information Systems Architecture
- Phase D: Technology Architecture
- Phase E: Opportunities and Solutions
- Phase F: Migration Planning
- Phase G: Implementation Governance
- Phase H: Architecture Change Management
- Requirements Management: Continuous process at center
Phase-by-Phase Breakdown
Preliminary Phase: Framework and Principles
Purpose: Prepare the organization for TOGAF architecture projects.
Key Activities:
- Define the architecture framework to be used
- Establish the architecture team
- Define architecture principles
- Tailor TOGAF for your organization
- Set up governance structures
Outputs:
| Output | Description | |--------|-------------| | Architecture Principles | Guiding rules for architecture decisions | | Tailored Architecture Framework | TOGAF customized for your org | | Architecture Repository | Initial structure for storing artifacts | | Request for Architecture Work | May be triggered here |
Real-World Tip: Don't skip this phase! Many architecture initiatives fail because organizations jump straight to visioning without establishing principles and governance.
Phase A: Architecture Vision
Purpose: Develop a high-level vision of the capabilities and business value to be delivered.
Key Activities:
- Establish the architecture project
- Identify stakeholders and concerns
- Create the Architecture Vision
- Obtain approval for Statement of Architecture Work
Outputs:
| Output | Description | |--------|-------------| | Statement of Architecture Work | Approved scope, approach, schedule | | Architecture Vision | High-level summary of changes | | Stakeholder Map | Who cares about this architecture | | Business Scenarios | Validated business requirements |
Exam Tip: Phase A produces the Architecture Vision document - this defines "what we're trying to achieve" at a high level before diving into details.
Phase B: Business Architecture
Purpose: Develop the Target Business Architecture describing how the enterprise needs to operate.
Key Activities:
- Develop baseline business architecture
- Develop target business architecture
- Perform gap analysis
- Define roadmap components
- Resolve impacts across the architecture landscape
Key Artifacts:
- Organization structure
- Business processes
- Business functions
- Business roles
- Business services
Real-World Application: This is where you map out business capabilities, processes, and organizational structures. Use business capability modeling to identify what the business does, not how IT supports it.
Phase C: Information Systems Architecture
Purpose: Develop Target Data and Application Architectures.
Two Sub-Phases:
- Data Architecture - How data is organized, stored, and accessed
- Application Architecture - Application components and their interactions
Data Architecture Artifacts:
- Data entity/component catalog
- Data lifecycle diagrams
- Data security and privacy requirements
Application Architecture Artifacts:
- Application portfolio catalog
- Application communication diagram
- Application migration diagram
Exam Tip: Phase C can be done as two sequential sub-phases (Data then Application) or in parallel, depending on organizational needs.
Phase D: Technology Architecture
Purpose: Develop the Target Technology Architecture that will form the basis for implementation.
Key Activities:
- Identify technology building blocks
- Define platform services
- Create architecture definition document
- Perform gap analysis
Technology Components:
| Layer | Examples | |-------|----------| | Infrastructure | Servers, storage, networking | | Platform | Containers, VMs, cloud services | | Middleware | Message queues, API gateways | | Security | Identity, encryption, firewalls | | Management | Monitoring, logging, automation |
Phase E: Opportunities and Solutions
Purpose: Perform initial implementation planning and identify delivery vehicles.
Key Activities:
- Determine business constraints for implementation
- Review and consolidate gap analysis results
- Create the Architecture Roadmap
- Identify transition architectures
Important Concept - Transition Architectures:
Current State → Transition 1 → Transition 2 → Target State (Today → Year 1 → Year 2 → Year 3)
Real-World Tip: Few organizations can jump from current to target state in one leap. Transition architectures define intermediate states that deliver incremental value.
Phase F: Migration Planning
Purpose: Develop detailed Implementation and Migration Plan.
Key Activities:
- Finalize the Architecture Roadmap
- Ensure plan coordination with enterprise approach
- Assign business value to work packages
- Prioritize projects
Output: A prioritized, sequenced roadmap of projects to implement the target architecture.
Prioritization Factors:
- Business value delivered
- Risk mitigation
- Dependencies between projects
- Resource availability
- Quick wins vs. long-term investments
Phase G: Implementation Governance
Purpose: Provide architectural oversight of implementation.
Key Activities:
- Confirm scope and priorities with implementation teams
- Identify deployment resources
- Guide development of solutions
- Perform architecture compliance reviews
Governance Activities:
| Activity | Purpose | |----------|---------| | Architecture Reviews | Ensure designs align with target architecture | | Compliance Assessments | Check implementations meet standards | | Dispensation Handling | Process exceptions and waivers | | Risk Management | Identify and mitigate architecture risks |
Phase H: Architecture Change Management
Purpose: Ensure the architecture responds to changes in the business environment.
Key Activities:
- Monitor technology and business changes
- Assess proposed changes against architecture
- Manage architecture governance
- Activate the ADM cycle for new requirements
Change Drivers:
- Technology changes (new platforms, sunset products)
- Business changes (mergers, new markets)
- Strategic changes (new business model)
- External changes (regulations, competition)
Requirements Management (Continuous)
Purpose: Manage architecture requirements throughout the ADM cycle.
This is not a phase but a continuous process that runs alongside all phases.
Key Activities:
- Identify and document requirements
- Baseline requirements
- Monitor baseline requirements
- Address changes to requirements
ADM Iterations and Adaptations
Types of ADM Cycles
| Cycle Type | Purpose | Duration | |------------|---------|----------| | Initial | First-time architecture development | 6-18 months | | Architecture Development | Major changes to baseline | 6-12 months | | Transition Planning | Detailed planning iteration | 3-6 months | | Architecture Governance | Oversight and refinement | Continuous |
Adapting the ADM
TOGAF explicitly states the ADM should be adapted:
Iteration Options:
- Sequential: Complete each phase before the next
- Parallel: Run phases B, C, D concurrently
- Incremental: Detailed work in iterations within a phase
- Agile: Combine with Agile methods for faster delivery
Exam Tips
Key Concepts to Know:
- Phase purposes - What each phase is trying to achieve
- Phase inputs/outputs - Key artifacts produced
- Order of phases - Preliminary → A → B → C → D → E → F → G → H
- Requirements Management is continuous, not a phase
- Iteration - ADM is iterative, not strictly waterfall
Common exam questions test:
- "Which phase produces the Architecture Vision?" → Phase A
- "Which phase addresses gap analysis?" → All domain phases (B, C, D)
- "Where is the Implementation Plan finalized?" → Phase F
- "What runs continuously throughout the ADM?" → Requirements Management
Key Takeaway
The ADM is TOGAF's core method. It's iterative, adaptable, and stakeholder-driven. Success with the ADM requires understanding that it's a framework to be tailored, not a rigid methodology to follow blindly. Real-world architects adapt the ADM to their organizational context while maintaining its fundamental principles of stakeholder engagement, artifact development, and iterative refinement.