Gap analysis is the step that turns a target architecture from a diagram into a plan. It answers one question precisely: what exists today, what needs to exist, and what has to change to get from one to the other.
Gap analysis compares a baseline architecture — what you have now — against a target architecture — what you have decided you need. Everything present in the target but missing from the baseline is a gap. Everything present in the baseline but absent from the target is also a gap, and it is the one people forget.
In TOGAF it appears in Phases B, C and D, once per architecture domain, and the consolidated result feeds the roadmap built in Phase E. But the technique does not belong to TOGAF and works perfectly well without it. What it does require is a baseline and a target that are both described at the same level of detail. Most gap analyses that go wrong fail here rather than in the analysis.
A gap analysis worth the name runs across all four architecture domains, because gaps in one create work in the others.
| Domain | What you compare | Typical gap |
|---|---|---|
| Business | Capabilities, value streams, processes, organisation | A capability the strategy assumes exists that nobody actually performs |
| Data | Data entities, ownership, flows, quality | A required data object that no system currently masters |
| Application | Applications, services, integrations | Two systems doing the same job, or none doing a needed one |
| Technology | Platforms, infrastructure, standards | Target capability that the current platform cannot support |
Business-domain gaps are usually assessed with a maturity model rather than a presence-or-absence test, because a capability is rarely simply missing — it exists and is not good enough. See the business capability maturity model for how that scoring works.
The classic technique is a matrix. Baseline building blocks down the left. Target building blocks across the top. An extra column labelled New and an extra row labelled Eliminated.
Work through it: where a baseline item carries forward into the target, mark the intersection Included. Where a target item has no baseline equivalent, mark the New column. Where a baseline item has no target equivalent, mark the Eliminated row.
When you have finished, the New column and the Eliminated row are your gap list. Everything else is continuity.
The matrix is tedious and that is the point. It forces you to make an explicit decision about every existing thing, which is exactly what informal gap analysis avoids. A workshop that lists what the target needs will produce a good list of new things and almost never produce the list of things to decommission.
Not every gap is a build. Sorting them by type changes the cost of the plan considerably.
The changed category is where most estimates go wrong. An application that appears in both baseline and target looks like continuity on a diagram while requiring a year of work underneath.
The target isn't specific enough to compare against. "Cloud-first" and "a single customer view" are directions, not target architectures. If the target cannot be decomposed into named building blocks, there is nothing to run a matrix against, and the exercise degrades into a list of complaints about the current estate.
Only additions get counted. A gap list of thirty new things and no eliminations is not a gap analysis, it is a wish list. It also produces an estate that only ever grows.
The baseline is aspirational. Baselines assembled from documentation rather than evidence describe the architecture people believe they have. Ask for the artefact, not the assurance. See building an application inventory for the underlying discipline.
Everything is a priority. A gap list without weighting is not decidable. Gaps need sizing and ranking against strategic importance before they are useful — a large gap on something peripheral outranks nothing.
The gap list is an input, not an output. Turning it into a plan takes three more steps.
Where the gaps concentrate in the application estate, a rationalisation lens is more useful than a pure gap list — see the TIME model. Where they concentrate in the business domain, the prioritisation logic in capability-based planning applies.
For a defined scope with an existing baseline, a gap analysis is days rather than weeks. If it is running into months, the problem is almost always an undefined target or a missing baseline — and both are separate pieces of work that should be recognised as such rather than absorbed silently into the gap exercise.
On presenting the result, the useful output is never the full matrix. It is the handful of gaps that are both large and strategically important, each with a recommendation attached. See presenting a capability assessment to the board.
The Business Capability Assessment Toolkit scores current against target maturity across 40 capabilities and generates the gap analysis, heatmaps and prioritisation automatically.
