TL;DR
Gap analysis compares baseline and target architecture to identify what must change. In TOGAF, it is used heavily in Phases B, C, and D, then reviewed and consolidated in later ADM phases.
What a gap is
A gap is a shortfall or difference between the baseline architecture and the target architecture.
It can be:
- accidental: something was missed
- deliberate: something is intentionally removed or replaced
- open: something is needed in the target state but does not exist yet
The purpose of gap analysis is to make these differences visible, decide what they mean, and turn the important ones into candidate Architecture Roadmap components.
Where gaps appear
Gaps can appear in any architecture domain.
| Domain | Typical gaps |
|---|---|
| Business | missing capabilities, process gaps, unclear roles, service gaps |
| Data | missing data, unavailable data, weak data relationships, poor data timing or quality |
| Application | applications created, changed, replaced, integrated, or retired |
| Technology | platforms, infrastructure, networks, or technology services created, changed, replaced, or retired |
Ignored stakeholder concerns are often the most serious source of gaps. If a concern is not represented in the target architecture, the architecture may look complete on paper while still failing the people who need to approve or use it.
Gap analysis matrix
A common TOGAF technique is to compare building blocks in a matrix.
Use Architecture Building Blocks when comparing architecture-level capability needs. Solution Building Blocks come later when implementation options are selected.
Basic setup:
- List target Architecture Building Blocks across the horizontal axis.
- List baseline Architecture Building Blocks down the vertical axis.
- Add a final New row.
- Add a final Eliminated column.
- Compare each baseline item against the target.
Example:
| Baseline \ Target | Video Conferencing Services | Enhanced Telephony Services | Mailing List Services | Eliminated |
|---|---|---|---|---|
| Video Conferencing Services | Included | |||
| Basic Telephony Services | Gap: enhance capability | |||
| Broadcast Services | Intentionally eliminated | |||
| Shared Screen Services | Unintentionally removed | |||
| New | Develop or procure | Develop or procure |
How to read it:
- Included: the building block exists in both baseline and target.
- Intentionally eliminated: the baseline building block is no longer needed in the target.
- Unintentionally removed: the target may be missing something by mistake; either correct the target or record the issue.
- Develop or procure: the target needs a building block that the baseline does not have.
- Gap: enhance capability: a baseline building block exists, but it does not meet target requirements.
Note
New building blocks usually need to be developed or procured. If you see “developed or produced” in older wording or course material, read it as developed or procured.
ABBs are not product choices
The matrix usually compares Architecture Building Blocks, not specific products.
For example:
- Video Conferencing Services is an Architecture Building Block. It describes the needed capability.
- Microsoft Teams, Zoom, or WebEx are possible Solution Building Blocks. They describe how the capability could be implemented.
This distinction matters because gap analysis first checks what capability is needed. Product selection comes later.
Value, constraints, and gaps
Gap analysis can also be supported by table-like views that compare architecture states or plans against:
- constraints
- value
- unresolved gaps
For example:
| View | Constraint position | Value position | Gap position |
|---|---|---|---|
| Baseline architecture | May satisfy constraints | May fail to deliver required value | Existing gaps remain |
| Implementation project | May fill gaps | May deliver near-term value | May violate constraints |
| Long-term roadmap | May deliver strategic value | May improve overall direction | Some gaps may remain open |
The point is not the table format itself. The point is to make trade-offs visible before stakeholders approve the path forward.
Where ADM uses gap analysis
Gap analysis appears throughout the ADM cycle.
| ADM phase | How gap analysis is used |
|---|---|
| Phase B: Business Architecture | Identify gaps between baseline and target Business Architecture |
| Phase C: Information Systems Architectures | Identify gaps between baseline and target Data/Application Architecture |
| Phase D: Technology Architecture | Identify gaps between baseline and target Technology Architecture |
| Phase E: Opportunities and Solutions | Review and consolidate gaps into solution options and roadmap work |
| Phase G: Implementation Governance | Compare implementation and operations against architecture expectations |
| Phase H: Architecture Change Management | Assess current and needed architecture capability |
In Phases B, C, and D, the pattern is especially direct:
- develop baseline architecture
- develop target architecture
- perform gap analysis
- define candidate Architecture Roadmap components to close the important gaps
Exam note
- A gap is a difference between baseline and target architecture that must be understood and handled.
- Gap analysis is central in Phases B, C, and D.
- The gap analysis matrix compares baseline and target building blocks.
- The New row shows building blocks that need to be developed or procured.
- The Eliminated column shows baseline building blocks removed from the target.
- Ignored stakeholder concerns can create critical architecture gaps.
- Gap analysis feeds candidate Architecture Roadmap components.