10.3 Core EA Techniques: Gap Analysis, Interoperability, Risk, Capability-Based Planning & Architecture Patterns

TOGAF Enterprise Architecture Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction to TOGAF & Enterprise Architecture Concepts

1.1 Overview of TOGAF Standard 10th Edition & Enterprise Architecture Concepts 1.2 The Structure of the TOGAF Standard (Easily Navigated Body of Knowledge) 1.3 Core Concepts: Enterprise, Architecture, Deliverables, Artifacts, and Building Blocks 1.4 TOGAF Certification Paths & the OGEA-101 Exam Plan

2 Chapter 2: ADM Foundation & Preliminary Phase

2.1 The Architecture Development Method (ADM) Cycle & Requirements Management 2.2 Preliminary Phase: Scope, Principles, and Architecture Capability Setup 2.3 Tailoring the ADM & Applying Iteration / Architecture Levels 2.4 Applying the ADM: The TOGAF Library, Purpose-Based Architecture Projects & the Digital Enterprise

3 Chapter 3: ADM Architecture Vision & Business Architecture

3.1 Phase A: Architecture Vision, Stakeholder Management & Value Proposition 3.2 Business Architecture Scope, Strategy & Capability Mapping 3.3 Phase B: Business Architecture Inputs, Steps, Outputs & Artifacts 3.4 Business Scenarios & Value Stream Modeling

4 Chapter 4: ADM Information Systems Architectures (Phase C)

4.1 Information Systems Architectures Overview & Phase C Strategy 4.2 Phase C Data Architecture: Principles, Data Models & Governance 4.3 Phase C Application Architecture: Logical Components, Services & Interfaces 4.4 Data and Application Integration, Migration & Interoperability

5 Chapter 5: ADM Technology Architecture & Solution Realization (Phases D, E, F)

5.1 Phase D: Technology Architecture, Platform Services & Infrastructure 5.2 Phase E: Opportunities and Solutions & Initial Implementation Strategy 5.3 Phase F: Migration Planning, Roadmap Development & Portfolio Prioritization 5.4 Transition Architectures & Implementation Dependencies

6 Chapter 6: ADM Governance, Change & Requirements Management (Phases G, H)

6.1 Phase G: Implementation Governance & Architecture Compliance 6.2 Phase H: Architecture Change Management & Driver Monitoring 6.3 Requirements Management: Central Flow, Impact Analysis & Traceability 6.4 Architecture Contracts, Dispensations & Compliance Reviews

7 Chapter 7: BDAT Architecture Domains Deep-Dive

7.1 Business Architecture Domain: Functions, Processes & Value Streams 7.2 Data Architecture Domain: Data Entities, Storage & Data Management 7.3 Application Architecture Domain: Application Services, Systems & Integration Patterns 7.4 Technology Architecture Domain: Hardware, Software, Cloud & Network Platforms

8 Chapter 8: Architecture Content — Content Framework, Enterprise Metamodel & Artifacts

8.1 Architecture Content Framework Overview & Deliverables vs Artifacts vs Building Blocks 8.2 Architecture Building Blocks (ABBs) vs Solution Building Blocks (SBBs) 8.3 The Enterprise Metamodel: Core Concepts, Entities & Attributes 8.4 Architecture Catalogs, Matrices & Diagrams (Visual Representation) 8.5 Stakeholders, Concerns, Architecture Views & Viewpoints

9 Chapter 9: Architecture Governance, Capability & Maturity

9.1 Architecture Governance Framework & The Role of the Architecture Board 9.2 Establishing an Architecture Capability & Organizational Structure 9.3 Architecture Skills Framework, Roles & Competency Levels 9.4 Architecture Maturity Models & Capability Assessments

10 Chapter 10: Enterprise Continuum, Reference Models & Key Techniques

10.1 Enterprise Continuum, Architecture Repository & Landscape Partitioning 10.2 Technical Reference Model (TRM) & Integrated Information Infrastructure Reference Model (III-RM) 10.3 Core EA Techniques: Gap Analysis, Interoperability, Risk, Capability-Based Planning & Architecture Patterns

10.3 Core EA Techniques: Gap Analysis, Interoperability, Risk, Capability-Based Planning & Architecture Patterns

Key Takeaways Explain This Topic AI

Gap Analysis compares Baseline and Target Architectures in a matrix — Baseline Building Blocks on the rows, Target Building Blocks on the columns — to identify items intentionally eliminated, unintentionally omitted, new, or retained.

Interoperability Assessment classifies system interaction across four maturity levels (Non-existent, Unstructured, Structured, Integrated) and distinguishes between syntactic and semantic interoperability.

TOGAF classifies risk on named scales — Effect (Catastrophic, Critical, Marginal, Negligible) against Frequency (Frequent, Likely, Occasional, Seldom, Unlikely) — yielding Extremely High, High, Moderate, or Low corporate risk impact.

TOGAF distinguishes the Initial Level of Risk (before mitigation) from the Residual Level of Risk (after mitigation), and records both across the five risk activities: classification, identification, initial assessment, mitigation and residual assessment, and monitoring.

Architecture Patterns put building blocks into context — building blocks are what you use, patterns tell you how, when, and why — and TOGAF specifies ten pattern elements from Name and Problem through to Known Uses.

Last updated: November 2026

10.3 Core EA Techniques: Gap Analysis, Interoperability, Risk & Capability-Based Planning

The TOGAF Architecture Development Method (ADM) provides a step-by-step process for architecture development. However, executing ADM phases effectively requires specialized analytical tools and architectural techniques. Four core techniques are indispensable across ADM cycles:

Gap Analysis: Matrix-based delta analysis between Baseline and Target states.

Interoperability Requirements Assessment: Evaluating cross-system operational capabilities.

Business Transformation Readiness & Risk Management: Identifying and mitigating implementation risks.

Capability-Based Planning: Structuring architecture roadmaps around measurable business outcome increments.

1. Gap Analysis Technique

Gap Analysis is a fundamental architectural technique applied throughout ADM Phase B (Business), Phase C (Data & Application), Phase D (Technology), and Phase E (Opportunities & Solutions). Its purpose is to highlight differences between the Baseline Architecture (current state) and the Target Architecture (future state).

The Gap Analysis Matrix

Gap Analysis is executed using a structured matrix where:

Rows list all Baseline Architecture Building Blocks (ABBs).

Columns list all Target Architecture Building Blocks (ABBs).

Cells record whether building blocks match, require modification, or represent gaps. +---------------------------------------------------------------------------------------------------+

| GAP ANALYSIS MATRIX LAYOUT |
| |
| Target ABB 1 Target ABB 2 Target ABB (Eliminated) |
| (Existing Customer DB) (New Cloud Payment API) |
| |
| Baseline ABB 1 RETAINED - - |
| (On-Prem Customer DB) (Upgraded v2.0) |
| |
| Baseline ABB 2 - - INTENTIONALLY |
| (Legacy Mainframe Pay) ELIMINATED |
| |
| Baseline (New / Target) - NEW / TARGET-ONLY - |
| (Required Work Package) |
+---------------------------------------------------------------------------------------------------+
The Four Gap Categories

During matrix analysis, every potential item falls into one of four distinct categories:

Intentionally Eliminated: Present in the Baseline Architecture but deliberately removed in the Target Architecture (e.g., decommissioning a legacy mainframe payment engine).

Unintentionally Omitted: Present in the Baseline Architecture but accidentally missing from the Target Architecture. Identifying unintentionally omitted items is critical to prevent unexpected business capability loss or service disruption during transition.

New / Target-Only: Absent in the Baseline Architecture and introduced in the Target Architecture to fulfill new functional or non-functional requirements (e.g., adding an API Gateway or Real-Time Analytics service).

Retained / Unchanged: Present in both Baseline and Target Architectures with minor or no modifications.

Practical Value of Gap Analysis

The identified gaps directly form the raw input for Work Packages in Phase E (Opportunities & Solutions). Work packages are subsequently grouped into projects and sequenced into Transition Architectures within Phase F (Migration Planning).

2. Interoperability Requirements Assessment

Interoperability is defined by TOGAF as the ability of two or more systems, units, or operational components to exchange information and use the services exchanged to operate effectively together.

During Phase B, C, and D, architects must define explicit interoperability requirements to ensure seamless system interaction across enterprise boundaries.

Syntactic vs. Semantic Interoperability

Interoperability must be established across two distinct layers:

Syntactic Interoperability: Technical format compatibility. Systems can parse the data structure, protocols, and message syntax (e.g., valid JSON schemas, REST over HTTPS, XML message formats).

Semantic Interoperability: Meaning and context compatibility. Systems share a common business vocabulary and interpretation of the data (e.g., both systems define Customer_ID and Order_Total using identical business rules and currency representations).

The Four Interoperability Maturity Levels

TOGAF categorizes organizational and technical interoperability into four levels:

Level Interoperability Level Operational Description Technical Characteristics

Level 1 Non-Existent Isolated application silos; zero direct interaction. Data manually re-entered across systems via paper or phone calls.

Level 2 Unstructured Ad-hoc data sharing across business units. Manual file exports (CSV, PDF), unstructured email attachments, custom batch scripts.

Level 3 Structured Formal automated data exchange following standard formats. Database replication, structured REST/SOAP APIs, fixed XML/JSON message schemas.

Level 4 Integrated Real-time, seamless enterprise-wide process integration. Event-driven architecture, shared Enterprise Service Bus (ESB), unified master data models (MDM).

3. Business Transformation Readiness & Risk Management

Architecture changes inevitably introduce operational, technical, financial, and organizational risks. TOGAF integrates Risk Management throughout the ADM to ensure architectural proposals are feasible and safe.

The Risk Management Lifecycle across ADM Phases Phase A: Architecture Vision --> Phases B-D: Architecture Domains --> Phases E-F: Planning --> Phase G: Implementation

Initial Risk Assessment - Domain-Specific Risk ID - Mitigation Strategies - Residual Risk Monitoring
Transformation Readiness - Technical Risk Analysis - Transition Architecture Risk - Compliance Governance

Phase A (Architecture Vision): Conduct initial Business Transformation Readiness Assessment . Identify macro-level risks such as lack of executive sponsorship, organizational culture resistance, or insufficient resource capacity.

Phases B through D (Domain Architectures): Identify specific technical and functional risks within Business, Data, Application, and Technology domains (e.g., data loss during cloud migration, legacy API throughput bottlenecks).

Phase E & F (Opportunities & Migration Planning): Formulate explicit risk mitigation strategies for each identified risk. Calculate residual risk (the remaining risk after controls are applied). Incorporate risk mitigation projects into Transition Architectures.

Phase G (Implementation Governance): Monitor real-world implementation activities against the risk register, ensuring residual risk limits are not breached.

TOGAF's Risk Classification Scheme

TOGAF does not use a generic "probability x impact" grid; it specifies named scales, and exam questions use its vocabulary. Risk is classified on two axes:

Effect (severity if the risk materializes): Catastrophic, Critical, Marginal, Negligible
Frequency (likelihood of occurrence): Frequent, Likely, Occasional, Seldom, Unlikely

Combining the two yields the corporate risk impact — Extremely High (E), High (H), Moderate (M), or Low (L) :

Effect \ Frequency Frequent Likely Occasional Seldom Unlikely
Catastrophic E E H H M
Critical E H H M L
Marginal H M M L L
Negligible M L L L L

Two terms sit on top of this scheme and are frequently tested:

Initial Level of Risk: the risk categorization before any mitigating action is determined or implemented.

Residual Level of Risk: the risk categorization after mitigating actions have been implemented.

The full technique runs as five activities: Risk Classification, Risk Identification, Initial Risk Assessment, Risk Mitigation and Residual Risk Assessment, and Risk Monitoring . Both the initial and residual assessments are recorded, because the difference between them is the evidence that a mitigation was worth its cost. Note also that TOGAF treats its own guidance as a fallback: practitioners are encouraged to use their organization's corporate risk management methodology and extend it with this scheme, using TOGAF's approach as best practice only where no corporate method exists.

Simplified View: Probability vs. Impact

Expressed in everyday project language, the same scheme reduces to:

Critical / High Risk: High Probability + High Impact. Requires immediate architectural redesign or formal mitigation before proceeding.

Medium Risk: Moderate Probability / Impact. Requires active monitoring and contingent risk response plans.

Low Risk: Low Probability + Low Impact. Accepted and recorded in the Governance Repository.

4. Capability-Based Planning

Modern enterprises manage strategic change using Capability-Based Planning —an architectural technique that focuses business investments on delivering specific operational business capabilities rather than isolated IT systems.

What is a Business Capability?

Definition: A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome. Capabilities represent what a business does, independent of how , where , or by whom it is executed.

Examples of business capabilities include Customer Onboarding , Credit Risk Scoring , Automated Fraud Detection , and Global Inventory Fulfillment .

Capability Increments and Architecture Roadmaps

Instead of attempting a massive "big bang" transformation, Capability-Based Planning structures the architecture roadmap into manageable Capability Increments : Baseline Capabilities (2026) --> Capability Increment 1 (Phase E/F) --> Capability Increment 2 (Phase E/F) --> Target Capabilities (2028)

- Manual Fraud Review - Semi-Automated Rules Engine - AI-Powered Real-Time Scoring - Fully Automated Real-Time Risk

- 48-Hour SLA - 4-Hour SLA - Sub-Second SLA - Instant SLA

Capability Gap Assessment: Evaluate current capability performance against strategic business targets to identify capability gaps.

Defining Capability Increments: Group related architectural work packages (from Gap Analysis) to deliver discrete capability improvements at specific transition milestones.

Mapping to Transition Architectures: Each Capability Increment aligns directly to a Transition Architecture in Phase E and F, ensuring business stakeholders receive measurable business value incrementally.

5. Architecture Patterns

Architecture Patterns are the fifth ADM technique in this group, and the one candidates most often skip. TOGAF defines a pattern, borrowing Fowler's phrasing, as "an idea that has been useful in one practical context and will probably be useful in others."

The relationship to building blocks is the examinable point:

Building blocks are what you use; patterns tell you how you use them — when, why, and what trade-offs you accept in doing so.

Patterns help an architect identify combinations of Architecture Building Blocks and Solution Building Blocks that have already been proven to work.

Content of a Pattern

TOGAF specifies ten elements. The first six carry the argument; the last four supply the evidence.

Element What it records

Name A meaningful, memorable single word or short phrase.

Problem The intent in applying the pattern — the goals to be reached within the stated context and forces.

Context The pre-conditions under which the pattern applies; the initial state before it is applied.

Forces The relevant constraints and how they interact or conflict, including the trade-offs that must be made.

Solution How to achieve the goals — static structure, dynamic behavior, and implementation guidance, in text and graphics.

Resulting Context The post-conditions after application, including which forces were resolved and which were not .

Examples Sample applications illustrating each of the other elements.

Rationale Justification of the pattern as a whole or of its individual components.

Related Patterns Predecessor, successor, alternative, and co-dependent patterns.

Known Uses Applications in existing systems, evidencing that the solution really is proven.

Pattern, Design Pattern, or Idiom?

TOGAF adopts a three-level distinction, and questions test the boundaries:

Architecture Pattern: expresses a fundamental structural organization or schema for software systems — a set of predefined subsystems, their responsibilities, and rules for organizing the relationships between them.

Design Pattern: a scheme for refining the subsystems or components of a system, or the relationships between them.

Idiom: a low-level pattern specific to a programming language , describing how to implement an aspect of a component using that language's features.

How Patterns Connect to the Rest of TOGAF

Patterns and the Architecture Continuum: patterns are reusable assets, so an enterprise should hold them in the Continuum and Architecture Repository rather than rediscovering them per project.

Patterns and Views: patterns help in designing the models behind architecture views and in composing views from them.

Patterns and Business Scenarios: relevant patterns are often first spotted during business scenario work (Section 3.4).

Read the standard's own caveat. TOGAF describes architecture patterns as an area still in its infancy, introduced to flag them to the community as an emerging resource and as a placeholder, rather than as a fully integrated part of the framework. It points at external catalogs — the US Treasury Architecture Development Guidance (TADG) patterns and IBM's Patterns for e-Business — as examples rather than defining a TOGAF pattern catalog of its own. An answer claiming TOGAF ships a mandatory catalog of named architecture patterns is wrong.