8.3 Gap Analysis

8.3 Gap Analysis

Gap analysis appears twice in the Foundation syllabus: briefly explain gap analysis (Concepts) and explain the purpose of gap analysis (ADM Techniques). The glossary defines a gap as "a statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified."

---

Purpose of Gap Analysis

Gap analysis is widely used in the TOGAF ADM to validate an architecture that is being developed. The basic premise is to highlight a shortfall between the Baseline Architecture and the Target Architecture — that is, items that have been deliberately omitted, accidentally left out, or not yet defined.

A key step in validating an architecture is to consider what may have been forgotten. The architecture must support all of the essential information processing needs of the organization, so gap analysis protects against a target that looks elegant but silently drops something the business still needs.

---

Potential Sources of Gaps

---

The Gap Analysis Matrix: Suggested Steps

1. Draw up a matrix with all the Architecture Building Blocks of the Baseline on the vertical axis and all the ABBs of the Target on the horizontal axis.
2. Add a final row labeled "New" to the Baseline axis and a final column labeled "Eliminated" to the Target axis.
3. Where an ABB is available in both architectures, record "Included" at the intersecting cell.
4. Where a Baseline ABB is not in the Target, mark it in the "Eliminated" column. Check whether it was correctly eliminated or accidentally left out; an accidental omission is addressed by reinstating it in the next iteration of the design.
5. Where a Target ABB is not in the Baseline, mark it in the "New" row. This is a gap that must be filled, either by developing or procuring the building block.

When the exercise is complete, anything under "Eliminated" or "New" is a gap, which should either be explained as correctly eliminated, or marked as to be addressed by reinstating or developing/procuring the function.

Example Matrix

The example shows the three outcomes to look for: included (possibly enhanced) building blocks, eliminated building blocks (checked for intent), and new building blocks that create work.

---

Execution of Gap Analysis Across the ADM Lifecycle

Gap Analysis is not a one-time administrative chore; it is an iterative technique applied continuously across the architecture definition and transition planning phases of the ADM:

• Phase B (Business Architecture): Gap Analysis compares baseline business processes, organizational structures, business capabilities, and value streams against target business models. It highlights missing capabilities (e.g., lack of real-time digital customer onboarding) and retired manual workflows.
• Phase C (Data & Application Architectures): Gap Analysis evaluates data entities, logical schemas, canonical models, application components, and integration interfaces. In Data Architecture, it surfaces unmanaged data silos and missing governance controls. In Application Architecture, it highlights legacy software packages scheduled for decommissioning and modern microservices requiring deployment.
• Phase D (Technology Architecture): Gap Analysis contrasts baseline infrastructure platforms, compute clusters, cloud environments, and communication networks against target technology baselines. It identifies obsolete operating systems, end-of-life hardware, network bandwidth deficits, and missing zero-trust security perimeters.
• Phase E (Opportunities & Solutions): This phase represents the consolidation pivot. The isolated gap analyses performed individually across Phases B, C, and D are synthesized into a Consolidated Gap Analysis. In Phase E, architects evaluate cross-domain dependencies, group related gaps into cohesive Candidate Work Packages, and determine whether intermediate Transition Architectures are required to bridge the gap safely.

---

Resolving Gaps and Driving Work Packages in Phase E

Once gaps are categorized across all BDAT domains, the architect does not leave them as passive observations in a spreadsheet. In Phase E (Opportunities & Solutions), the gap analysis becomes the engine of implementation planning:

1. Formulating Work Packages: Each gap (or logical cluster of gaps) is assigned an explicit remediation vehicle. A newly required building block becomes a "Build or Procure" work package. An eliminated building block becomes a "Decommissioning and Data Archival" work package.
2. Selecting Solution Building Blocks (SBBs): Architecture Building Blocks (ABBs) in the gap analysis are mapped to candidate vendor products, custom software frameworks, or cloud services.
3. Determining Transition Architectures: If the collective delta between baseline and target involves high operational risk or massive capital expenditure, architects use the gap findings to design intermediate Transition Architectures (e.g., Transition Architecture 1: Core Decoupling; Transition Architecture 2: Dual-Run; Target Architecture: Full Cutover).

---

Common Exam Pitfalls

• Assuming gap analysis only finds new things. It also finds eliminated items and checks whether each was deliberate or accidental.
• Placing the axes wrongly. Baseline ABBs on the vertical axis with a "New" row; Target ABBs on the horizontal axis with an "Eliminated" column.
• Forgetting non-technical gaps. Business-domain gaps include people, processes, tools, information, measurement, financial, and facilities.
• Thinking gap analysis happens once. It is performed in each of Phases B, C, and D and consolidated in Phase E.