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

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:

1. Gap Analysis: Matrix-based delta analysis between Baseline and Target states.
2. Interoperability Requirements Assessment: Evaluating cross-system operational capabilities.
3. Business Transformation Readiness & Risk Management: Identifying and mitigating implementation risks.
4. 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:

1. Intentionally Eliminated: Present in the Baseline Architecture but deliberately removed in the Target Architecture (e.g., decommissioning a legacy mainframe payment engine).
2. 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.
3. 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).
4. 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:

---

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

1. 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.
2. 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).
3. 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.
4. 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):

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 logged in the Governance Log.

---

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

1. Capability Gap Assessment: Evaluate current capability performance against strategic business targets to identify capability gaps.
2. Defining Capability Increments: Group related architectural work packages (from Gap Analysis) to deliver discrete capability improvements at specific transition milestones.
3. 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.

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.