2.3 Tailoring the ADM & Applying Iteration / Architecture Levels

2.3 Tailoring the ADM & Applying Iteration / Architecture Levels

Enterprise Architecture (EA) is never a rigid, one-size-fits-all endeavor. The TOGAF Standard explicitly recognizes that the Architecture Development Method (ADM) is a generic reference framework that must be adapted, customized, and tailored to align with an organization's unique operational context, business culture, scale, regulatory constraints, and existing management frameworks. Furthermore, applying the ADM effectively in a modern enterprise requires organizing work across structured iteration cycles and partitioning architectural scope into distinct Architecture Levels.

Mastering ADM tailoring, iteration dynamics, and architecture leveling is fundamental for enterprise architects seeking to deliver measurable business value without imposing excessive governance overhead.

---

Drivers and Rationale for ADM Tailoring

The generic ADM cycle provides a comprehensive, 10-phase framework (Preliminary Phase through Phase H, plus Requirements Management). However, executing every ADM artifact and stage-gate out of the box can lead to unnecessary bureaucracy. Tailoring is mandatory to ensure the architecture capability operates efficiently.

1. Organizational Scale and Complexity

• Small-to-Midsize Enterprises (SMEs): SMEs require a streamlined, lightweight ADM execution. Deliverables such as the Architecture Vision, Business Architecture, and Technology Architecture are often consolidated, and governance stage-gates are merged into existing management meetings to maintain agility and rapid decision-making.
• Multinational Conglomerates: Large, diversified enterprises require a multi-tiered ADM approach with formal governance boards across operating companies, explicit federated metamodels, and rigorous change management protocols.

2. Regulatory Mandates and Industry Standards

Organizations operating in highly regulated environments must tailor the ADM to embed mandatory compliance, privacy, and security controls into every phase:

• Banking and Finance (Basel III, PCI-DSS, SOX): Requires embedding quantitative risk analysis, fraud prevention models, and strict auditability metrics into Phase B (Business Architecture) and Phase C (Data Architecture).
• Healthcare (HIPAA, HITECH, GDPR): Requires integrating patient data protection controls, explicit data privacy impact assessments (DPIAs), and consent management building blocks into Phase C Data and Application Architecture.
• Defense and Government (NIST SP 800-53, CMMC, FedRAMP): Mandates integrating explicit cybersecurity frameworks and zero-trust architectural patterns into Phase D (Technology Architecture) and Phase G (Implementation Governance).

3. Framework Coexistence and Integration

The ADM does not exist in a vacuum; it must integrate seamlessly with complementary management frameworks:

• ITIL v4 (IT Service Management): Integrates Phase G (Implementation Governance) and Phase H (Architecture Change Management) with ITIL Service Design, Service Transition, Continual Improvement, and Operational Acceptance criteria.
• COBIT 2019 (IT Governance): Maps TOGAF Architecture Board governance structures directly to COBIT governance objectives, specifically Evaluated, Directed, and Monitored (EDM) controls and Aligned, Planned, and Organized (APO) processes.
• SAFe / Agile (Scaled Agile Framework): Adapts ADM iterations to feed Strategic Themes and Architecture Epics into Agile Release Trains (ARTs), establishing an "Architecture Runway" that supports continuous delivery sprint cycles without creating architectural debt.
• PMBOK / PRINCE2 (Project Portfolio Management): Aligns Phase E (Opportunities & Solutions) and Phase F (Migration Planning) deliverables—such as Work Packages, Architecture Roadmaps, and Transition Architectures—with enterprise Project Portfolio Management (PPM) stage-gates and capital budgeting cycles.

---

Practical Steps for Tailoring the ADM

Tailoring is formally initiated during the Preliminary Phase and refined throughout the ADM lifecycle. The enterprise architecture team follows three primary execution steps:

Step 1: Terminology Adaptation

To minimize organizational resistance, TOGAF terminology should be mapped to the enterprise's native business and technical vocabulary. For example, if an enterprise uses the term "Solution Blueprint" instead of "Architecture Definition Document", or "Technical Review Committee" instead of "Architecture Board", the ADM documentation should adopt these familiar terms.

Step 2: Enterprise Metamodel Customization

The standard TOGAF Enterprise Metamodel (called the Content Metamodel in TOGAF 9.2 — see Section 8.3) must be customized by adding, modifying, or suppressing entity types, attributes, and relationships to reflect enterprise priorities:

• Extensions: Adding specialized entities such as Cloud Service, API Contract, or Regulatory Control.
• Simplifications: Suppressing unused attributes in environments that require lightweight cataloging.

Step 3: Phase Input/Output & Deliverable Adjustments

Architects must determine which standard TOGAF deliverables are mandatory, optional, or combined for a given project context. For small projects, Phase B, C, and D outputs may be combined into a single "Target Architecture Specification", whereas major enterprise transformations require full, independent deliverable sets for each domain.

---

Deep Dive into the 4 ADM Iteration Cycles

Although the ADM is visually depicted as a sequential cycle of phases, real-world architecture execution is deeply iterative. TOGAF categorizes ADM iterations into four distinct iteration cycles:

+-----------------------------------------------------------------------+
|                 1. Architecture Capability Iterations                 |
|            (Preliminary Phase <---> Phase A: Architecture Vision)     |
+-----------------------------------------------------------------------+
                                   |
                                   v
+-----------------------------------------------------------------------+
|                2. Architecture Development Iterations                 |
|            (Phase B <---> Phase C <---> Phase D: Domains Deep-Dive)    |
+-----------------------------------------------------------------------+
                                   |
                                   v
+-----------------------------------------------------------------------+
|                 3. Transition Planning Iterations                     |
|           (Phase E: Opportunities <---> Phase F: Migration)           |
+-----------------------------------------------------------------------+
                                   |
                                   v
+-----------------------------------------------------------------------+
|                 4. Architecture Governance Iterations                 |
|            (Phase G: Governance <---> Phase H: Change Mgmt)           |
+-----------------------------------------------------------------------+

1. Architecture Capability Iterations: Spanning the Preliminary Phase and Phase A, these iterations support the creation and evolution of the required Architecture Capability — the initial mobilization of architecture activity, and the establishment or adjustment of the architecture approach, principles, scope, vision, and governance. A Change Request raised in Phase H can trigger a fresh Architecture Capability iteration, but Phase H is not itself part of this cycle.
2. Architecture Development Iterations: Spanning Phases B, C, and D, these iterations allow architects to cycle through — or integrate — the Business, Information Systems, and Technology Architecture phases so the architecture is considered as a whole. Discovering a technological constraint in Phase D may require looping back to adjust Phase B business processes or Phase C data entities. As the iterations converge on a target, they extend into Phases E and F so that implementability is tested while the architecture is still being finalized.
3. Transition Planning Iterations: Spanning Phases E and F, these iterations reconcile identified gaps with budget constraints, resource availability, and implementation risks. Architects iteratively structure work packages into realistic Transition Architectures ($TA_1, TA_2, \dots, TA_n$) to form an optimized Migration Roadmap.
4. Architecture Governance Iterations: Spanning Phases G and H, these iterations oversee actual solution deployment, conduct stage-gate compliance reviews, process formal architectural dispensations, and monitor external driver changes to trigger new ADM cycles.

---

Structured Breakdown of TOGAF Architecture Levels

To prevent architectural scope creep and manage operational complexity, TOGAF structures the Architecture Landscape into three hierarchical Architecture Levels. Each level addresses distinct stakeholder concerns, planning horizons, and scopes of detail.

Comprehensive Comparison of TOGAF Architecture Levels

---

Enterprise Partitioning Principles & Cross-Partition Governance

Enterprise Partitioning is the architectural discipline of dividing the overall enterprise landscape into distinct, manageable partitions. This allows autonomous teams to work concurrently on different segments of the architecture without causing conflict or monolithic bottlenecks.

Core Partitioning Principles

1. Autonomy: Each partition should have a clear scope, distinct ownership, and high internal cohesion. Architecture teams operating within a partition must have autonomy to make local architectural decisions within established strategic guardrails.
2. Low Coupling: Dependencies between partitions must be minimized and explicitly governed. Interactions between partitions must occur strictly through well-defined, standardized interfaces, APIs, and shared data models.
3. Hierarchy and Lineage (Alignment): Partitioned architectures must maintain vertical and horizontal alignment. Capability architectures must trace directly to Segment architectures, which in turn must support the overall Strategic Architecture vision.
4. Building Block Reuse: Enterprise-wide Architecture Building Blocks (ABBs)—such as centralized identity and access management (IAM), unified customer data platforms, and enterprise service buses—must be defined at Strategic or Segment levels and reused across all lower-level Capability architectures to eliminate redundant investment.
5. Cross-Partition Governance: The Architecture Board retains overarching responsibility for cross-partition alignment. It resolves inter-partition conflicts, manages shared building block repositories, and ensures that local partition autonomy does not compromise enterprise-wide interoperability.

---

Practical Exam Traps & Key Takeaways

• Exam Trap 1: Timing of ADM Tailoring: A common TOGAF exam question asks when ADM tailoring occurs. The correct answer is that initial tailoring must take place in the Preliminary Phase, before any architecture development work begins, though minor refinements occur in Phase H.
• Exam Trap 2: Conflating Architecture Levels with Enterprise Continuum Levels: Do not confuse Architecture Levels (Strategic, Segment, Capability) with the Enterprise Continuum levels (Foundation, Common Systems, Industry, Organization-Specific). Architecture Levels define granularity and planning horizons, whereas the Enterprise Continuum defines breadth of asset reusability.
• Exam Trap 3: Rigid ADM Execution: TOGAF never mandates completing Phase A through H in a strict linear sequence without back-tracking. Iteration across phases and domain loops is explicitly endorsed and expected.