14.1 Tailoring the ADM: Enterprise Context, Process Weight, and Agile Integration

14.1 Tailoring the ADM: Enterprise Context, Process Weight, and Agile Integration

A central tenet of the TOGAF Standard is that the Architecture Development Method (ADM) is a generic, adaptable method. It is explicitly designed to be customized, specialized, and tailored to fit the specific operating environment, governance culture, and strategic imperatives of the enterprise. One of the most prevalent failure modes in real-world enterprise architecture—and a major focus of practitioner scenario evaluations on the OGEA-103 examination—is attempting to execute the ADM rigidly out of the box as a bureaucratic, heavyweight waterfall process.

Tailoring the ADM is not an optional afterthought; it is a mandatory activity formally initiated and governed during the Preliminary Phase. Practitioners must understand the critical environmental factors that dictate tailoring, how to calibrate process weight, how to integrate TOGAF with Agile and DevOps delivery cadences, and how to harmonize architecture work with established management frameworks such as ITIL and COBIT.

---

The Mandate for Tailoring the ADM

In the Preliminary Phase, the architecture team addresses a fundamental governance question: "How will we do architecture that fits this specific enterprise?" The standard specifies several primary drivers that necessitate tailoring:

1. Organizational Context and Enterprise Footprint: An enterprise rarely encompasses an entire Fortune 500 conglomerate under a single monolithic architecture. The architecture footprint must be scoped to specific business sectors, lines of business, or federated operating units.
2. Cultural Alignment and Decision-Making Norms: Organizations vary widely in their cultural tolerance for formal processes. A consensus-driven organization requires extensive stakeholder workshops and iterative socialization, whereas an engineering-centric digital startup demands concise, code-centric documentation and automated guardrails.
3. Regulatory, Statutory, and Compliance Baselines: Highly regulated industries (e.g., life sciences, commercial aviation, retail banking, defense) operate under non-negotiable legal frameworks (such as FDA 21 CFR Part 11, HIPAA, PCI-DSS, or Basel III/IV). In these environments, tailoring must introduce rigorous traceability matrices, formalized sign-off gates, and comprehensive compliance audit trails.
4. Existing Enterprise Frameworks and Methodologies: TOGAF does not exist in an operational vacuum. Enterprises frequently maintain established frameworks for portfolio management (e.g., PMI/PMBOK), IT service delivery (e.g., ITIL v4), enterprise governance (e.g., COBIT), and product development (e.g., SAFe, Scrum, Kanban). Tailoring maps TOGAF deliverables and phases directly into these existing lifecycles rather than establishing redundant parallel processes.
5. Architecture Maturity and Capability Level: A team operating at Architecture Capability Maturity Model (ACMM) Level 2 cannot successfully execute the dense metamodels and comprehensive cataloging expected at Level 4. Tailoring adapts the scope and sophistication of ADM artifacts to the current capability maturity of the organization.

Tailoring decisions are formally codified in the Tailored Architecture Framework, approved by the Architecture Board, and stored in the Architecture Repository during the Preliminary Phase.

---

Tailoring Dimensions Across Organizational Environments

The following matrix illustrates how key environmental factors alter the application of the ADM:

---

Calibrating Process Weight: Minimum Viable Architecture (MVA)

A critical competency tested at the practitioner level is the ability to adjust process weight. Excessive process weight creates architectural bureaucracy, alienates software engineering teams, and delays time-to-market. Insufficient process weight leads to architectural drift, unmanaged technical debt, security vulnerabilities, and fragmented customer experiences.

To achieve balance, mature practitioners apply the concept of Minimum Viable Architecture (MVA):

• What is MVA?: The smallest set of architectural decisions, principles, patterns, and guardrails necessary to guide implementation teams toward a coherent, secure, and evolvable solution without constraining unnecessary tactical design choices.
• Focus on High-Impact Decisions: MVA prioritizes decisions that are difficult, expensive, or impossible to reverse later (such as database storage paradigms, integration topology, security authentication protocols, and core data schemas) while deferring low-impact implementation decisions to delivery teams.
• Lean Documentation: Rather than drafting 150-page Architecture Definition Documents for every initiative, the architecture practice defines standardized, concise templates. Major technical decisions are captured in Architecture Decision Records (ADRs)—one-to-two-page documents recording Context, Decision, Rationale, and Consequences.

---

TOGAF's Own Agile Guidance

TOGAF's Introduction and Core Concepts explains that enterprise agility is broader than agile software development. The framework responds to the need for timely change through partitions, which break the work into multiple architecture initiatives, levels, which develop architecture at different granularity, and iteration. Detailed guidance is in the Series Guides Enabling Enterprise Agility and Applying the TOGAF ADM Using Agile Sprints, and in the related Open Agile Architecture Standard. The practices below, including runway, dual-track delivery, and architecture in the Definition of Done, are common ways to put that guidance into effect. They come from agile frameworks such as SAFe rather than from the TOGAF text.

---

Integrating TOGAF with Agile, Scrum, and Scaled Agile (SAFe)

In modern enterprises, software development and operational delivery are predominantly executed using Agile frameworks. Candidates often encounter exam scenarios depicting friction between enterprise architects and agile delivery teams. Successful integration requires understanding how TOGAF and Agile complement each other through the balance of Intentional Architecture and Emergent Design.

Intentional Architecture vs. Emergent Design

• Emergent Design: Agile development teams champion emergent design—allowing the optimal software design and component structure to emerge organically through user story delivery, sprint retrospectives, and continuous refactoring. While emergent design works exceptionally well for local component logic, it cannot resolve cross-system data integrity, enterprise security baselines, regulatory compliance, or multi-platform integration.
• Intentional Architecture: Enterprise architecture provides intentional architecture—the structured set of purposeful, forward-looking architectural choices that guide the enterprise toward its strategic destination. It establishes the foundational platforms, non-functional requirements (NFRs), canonical data models, and enterprise security guardrails.
• The Synthesis: Intentional architecture provides the conceptual boundaries and guardrails, while emergent design operates within those boundaries to deliver responsive, user-centric features.

The Architectural Runway

In Scaled Agile frameworks (such as SAFe), enterprise and solution architects build and maintain the Architectural Runway. The runway consists of the existing code, infrastructure components, shared services, and technical platforms necessary to implement near-term business features without excessive redesign and delays:

• Building Runway Ahead of Sprints: Architects execute ADM cycles (particularly Phases B, C, and D) 1 to 2 Program Increments (PIs) ahead of development teams, developing Architecture Enabler Epics and foundational platforms.
• Consuming the Runway: Agile teams consume the runway during regular development sprints, deploying business features rapidly because the security identity provider, database clusters, and API gateways are already architected and operational.
• Runway Depletion Risk: If architects fail to maintain the runway, agile teams hit "architectural walls," forcing them to either halt feature delivery to build infrastructure or implement local tactical hacks that accumulate massive technical debt.

Dual-Track Agile Integration

To align ADM cadence with agile execution, organizations implement Dual-Track Agile:

1. Discovery / Architecture Track: Enterprise and domain architects work closely with Product Management, cycling through Phases A through E to explore business problems, model capabilities, evaluate vendor solutions (ABBs to SBBs), and establish architecture runway enablers.
2. Delivery / Engineering Track: Scrum and Kanban teams build, test, and release working software in two-week iterations, pulling architectural enablers from the product backlog into delivery sprints.

Governance at Agile Velocity

Architecture governance must not depend on scheduling monthly, synchronous committee meetings to review agile pull requests. Tailoring governance for agile velocity involves:

• Architecture Definition of Done (DoD): Embedding architectural criteria (e.g., "API registered in catalog," "Zero critical security vulnerabilities," "Complies with canonical customer data schema") directly into the agile team's Definition of Done.
• Automated Policy-as-Code: Enforcing architectural rules through CI/CD pipelines (e.g., SonarQube quality gates, Open Policy Agent security rules, and Terraform linting for cloud infrastructure).
• Embedded Architecture Roles: Solution architects serve as active members of Agile Release Trains (ARTs), participating in sprint planning and backlog refinement rather than acting as distant external auditors.

---

Harmonizing TOGAF with ITIL and COBIT

Enterprise architecture does not replace operational management and governance frameworks; it provides the structural blueprints that make them effective:

TOGAF and ITIL (IT Service Management)

• Strategic Alignment: Phase B (Business Architecture) models the business services and customer value streams that ITIL operationalizes into the IT Service Catalog.
• Service Design & Transition: Phases C and D define the application and technology architectures that feed ITIL Service Design. Transition planning in Phases E and F directly informs ITIL Change Enablement and Release Management.
• Configuration Management Database (CMDB): Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs) documented in the TOGAF Architecture Repository establish the baseline configuration models for the ITIL CMDB.

TOGAF and COBIT (Governance of Enterprise IT)

• Governance Hierarchy: COBIT establishes overarching governance objectives, internal control frameworks, and audit mechanisms for enterprise information and technology.
• Executing COBIT Controls: TOGAF Architecture Governance (Phase G and Architecture Boards) provides the practical operational processes that satisfy COBIT governance practices (such as APO01 Manage the I&T Management Framework and APO03 Manage Enterprise Architecture).

---

Practitioner Exam Scenario: FinTech Platform Modernization

Scenario: Apex Global Payments, a high-volume payment processor subject to strict PCI-DSS and banking regulations, initiates an enterprise modernization effort to transition its legacy core transaction processing system into a cloud-native microservices architecture. The engineering organization utilizes SAFe across 12 Agile Release Trains (ARTs).

The delivery leads argue that TOGAF is an obsolete waterfall methodology that will stifle innovation, demanding that the architecture team be disbanded and all decisions delegated to individual scrum teams. Concurrently, the internal audit committee warns that any ungoverned technical drift will result in regulatory fines and suspension of banking licenses.

Practitioner Adjudication & Tailoring Strategy:

• Rejection of Extremes: The Lead Enterprise Architect rejects both the rigid waterfall approach (which would stall delivery) and the pure emergent design approach (which would cause regulatory disaster and architectural fragmentation).
• Tailored Preliminary Phase Plan: The architect tailors the ADM to establish an integrated governance model:
  1. Intentional Runway Creation: The EA team operates one Program Increment (PI) ahead, defining the enterprise microservices security architecture, event mesh, and canonical payment schemas as Enabler Epics.
  2. Automated Governance: PCI-DSS compliance requirements and architectural standards are converted into automated CI/CD policy-as-code guardrails. Pull requests that violate encryption baselines or schema models are blocked automatically in the build pipeline.
  3. Lightweight ADR Workflow: Delivery teams are empowered to make local design choices, documenting decisions via lightweight Architecture Decision Records (ADRs) stored in Git and reviewed asynchronously by domain architects within a 48-hour SLA.
• Outcome: The enterprise passes external banking audits with zero non-compliance findings while sustaining high feature release velocity across all 12 ARTs.

---

Common Exam Traps & Pitfalls

• Trap 1: Assuming Tailoring is Optional or Postponable: Any exam answer suggesting that an enterprise should execute the standard ADM "by the book" without tailoring, or postponing tailoring until Phase B or C, is incorrect. Tailoring is a foundational obligation of the Preliminary Phase.
• Trap 2: Believing Agile Replaces Enterprise Architecture: Watch for distracter options claiming that modern agile enterprises do not need TOGAF or intentional architecture. Emergent design alone cannot govern cross-system integrations, data models, or enterprise compliance.
• Trap 3: Imposing Synchronous Phase Gates on Agile Sprints: Proposing that agile teams must pause development sprints to await formal monthly Architecture Board deliverable approvals represents an anti-pattern. Architecture governance in agile environments must be lightweight, continuous, and automated.