Gap analysis in the business layer

C220 Part 3 of the TOGAF Standard describes gap analysis as an ADM technique that compares baseline and target architectures to identify what is missing, what changes, and what can be reused. The technique applies to all four architecture domains (business, data, application, technology), but this module focuses on how it works in the business layer specifically.

C220 Part 3 describes the gap analysis technique using a matrix approach. The rows represent elements of the baseline architecture. The columns represent elements of the target architecture. The intersections show whether each baseline element maps to a target element (retained, modified, or replaced) or whether a target element has no baseline equivalent (new) or a baseline element has no target equivalent (eliminated).

That matrix structure is the foundation, but the technique goes further. A useful gap analysis does not stop at identifying the differences. It classifies them, attaches consequences, maps dependencies, and suggests intervention types. The distinction between a descriptive gap analysis and a useful gap analysis is the difference between listing what has changed and explaining what to do about it.

Business-layer gap analysis proceeds through five steps. Each step adds a layer of analytical depth that transforms the comparison from a list of differences into a change logic.

Step 1: Identify the gaps

Compare the baseline business architecture (capabilities, services, organisation relationships, value-stream performance, footprint connections) against the target. For each element, determine whether it is retained unchanged, modified, replaced, new (exists only in the target), or eliminated (exists only in the baseline).

The identification step should cover all the artefacts produced in Stage 3, not just one view. A gap might appear as a missing capability on the capability map, as a broken handoff on the value stream, as a missing service in the catalogue, or as an accountability void on the organisation view. Cross-referencing gaps across views is essential because many gaps appear in multiple places.

Step 2: Classify each gap

Not every difference deserves the same attention. Classify each gap by type so that later prioritisation can be done systematically. The five categories that carry the most architectural weight in the business layer are described in Section 23.3 below.

Step 3: Attach consequence to each significant gap

For each gap that has been identified and classified, state what happens if the gap is not closed. The consequence statement is the forcing function that turns gap analysis into change logic. "The planning-data visibility gap means that connection offers continue to take 65 working days, which exceeds the regulatory expectation and damages the enterprise's reputation with Ofgem" is a consequence statement that can drive prioritisation. "Planning data is different in the target" is a description that cannot.

Consequence statements should be specific enough that a governance body can weigh them against each other. "This is important" is not a consequence. "Failure to close this gap within twelve months creates a regulatory non-compliance risk that could result in enforcement action" is a consequence that the Architecture Board can evaluate.

Step 4: Map dependencies between gaps

Many business gaps are entangled. Closing one gap may depend on closing another first. The planning-data visibility gap cannot be fully closed until the data-quality gap in as-built records is addressed, because the planning view depends on accurate asset data. Mapping these dependencies is essential for sequencing the roadmap.

Dependencies also reveal which gaps are foundational and which are dependent. A foundational gap blocks progress on multiple other gaps. A dependent gap can only be closed after its prerequisite is addressed. The architecture team should identify foundational gaps early because they determine the critical path of the transformation.

Step 5: Assign intervention types

Not every gap requires a system change. Business gaps point toward a mix of intervention types: business change (new processes, revised operating procedures), governance change (new decision structures, revised review cycles), information change (data authority clarification, quality improvement), organisational change (accountability redesign, role clarification), or system change (application integration, platform replacement).

If every gap in the log defaults to "implement a new system," the analysis has not examined root causes carefully enough. The London case demonstrates this clearly: three of four major gaps require governance, information, or organisational intervention. Only one requires technology as the primary intervention.

Not every difference between baseline and target deserves the same attention. Five categories of business gap carry the most architectural weight because they affect the enterprise's ability to deliver stakeholder outcomes.

1. Missing or underpowered capabilities. A capability that the target requires but that does not yet exist, or exists in a form too weak to support the required outcome. In the London case, network planning visibility exists but is fragmented across multiple systems. The target requires an integrated planning view. The gap is not "no capability" but "capability too weak." This distinction matters because the intervention for strengthening an existing capability is different from building a new one.

2. Weak ownership or broken accountability. A gap where the target requires clear accountability but the baseline has contested, duplicated, or absent ownership. In the London case, the data governance function has responsibility for information quality but no authority over the systems that generate the data. The gap is between responsibility and authority, and it cannot be closed by technology alone.

3. Value-stage friction. A gap where the target value stream requires smooth handoffs but the baseline has delays, rework, or information loss at transition points. The assess-to-study handoff in the London connections value stream is the clearest example: information is lost because teams use different systems, adding twelve to fifteen working days.

4. Misaligned goals, services, or measures. A gap where the target footprint requires alignment but the baseline has disconnections or unmeasured services. A service that exists but has no connected measure cannot be evaluated. A goal that exists but has no connected service cannot be delivered. These misalignments are structural gaps that the footprint view from Module 22 exposes.

5. Business dependencies that are not governed. A gap where the target requires a governed dependency but the baseline treats it as informal or invisible. In the London case, the planning-to-design dependency is critical for the connections outcome but is not formally governed. The design team depends on planning data, but there is no service-level agreement, no escalation path, and no governance mechanism for resolving delays.

Four pieces of information transform a gap entry from a descriptive observation into an actionable architecture input. Every significant gap in the log should carry all four.

1. Why the gap matters to the enterprise outcome or stakeholder concern. This connects the gap to the footprint view. A gap that cannot explain why it matters is not yet understood well enough to prioritise.
2. What consequence appears if the gap is not addressed within a specified timeframe. This is the forcing function that turns gap analysis into change logic. The consequence should be specific enough that a governance body can weigh it against competing priorities.
3. Which dependencies or other capabilities, services, or gaps are involved. Many business gaps are entangled. Closing the planning-visibility gap depends on closing the data-quality gap first. Mapping dependencies is essential for sequencing.
4. What sort of intervention the gap points toward. Not every gap requires a system change. The intervention type should name the primary change category: business change, governance change, information change, organisational change, or system change. Naming the intervention type prevents the roadmap from defaulting to technology solutions for business problems.

A gap log where every entry has all four attributes is a planning tool. A gap log where entries have only the first attribute (or none) is a comparison table. The difference determines whether the gap analysis can support the Phase E and Phase F work that follows.

The business gap log is not an end in itself. It is the bridge from Stage 3 into the rest of the course. When the gap log is strong, it provides four specific inputs to later phases.

Traceability for information architecture (Phase C). Data authority questions can be traced back to business gaps that identified information quality as a root cause. When the Phase C team asks "why does this data domain need a single authoritative source?", the answer traces to a business gap that showed planning data fragmentation causing handoff delays. Without that traceability, data architecture decisions feel arbitrary.

Justification for application boundaries (Phase C). Application architecture decisions can be tested against the business gaps they help close. An application boundary that splits planning and design data into separate systems would worsen the assess-to-study gap. The gap log provides the business-layer evidence for keeping that data together.

Prioritisation for technology architecture (Phase D). Technology investments can be sequenced based on which business gaps create the most leverage. If the planning-visibility gap is foundational (blocking three other gaps), the technology that supports planning integration moves up the priority list. Without the gap dependency map, technology investment priorities are based on technical debt rather than business impact.

Work-package definition for migration planning (Phase E and Phase F). The gap log feeds directly into work packages and transition architecture. Each gap with its consequence, dependency, and intervention type becomes a candidate work package. The dependency map determines sequencing. The consequence statements determine urgency.

In London Grid Distribution, business-layer gaps appear where current planning, handoff, publication, and accountability arrangements cannot support the required service and governance outcomes. The London gap log demonstrates how the five-step method works on a real transformation problem.

Gap 1: Planning-data visibility

Baseline: Planning data is fragmented across GIS, DMS, and spreadsheet-based tools. Engineers assemble capacity views manually for each connection assessment. Target: Integrated planning view with a single trusted source for capacity data, accessible to both planning and design teams. Why it matters: Every connection assessment depends on accurate capacity data. Fragmented data causes incorrect offers, rework, and regulatory scrutiny. Consequence if not closed: Connection offers continue to take 65 working days on average, exceeding regulatory expectations. Ofgem scrutiny increases. Customer complaints escalate. Dependencies: Depends on Gap 3 (data quality in as-built records) because the planning view is only as good as the asset data that feeds it. Intervention type: Information architecture change (data authority clarification, single-source-of-truth design) supported by application integration.

Gap 2: Accountability clarity

Baseline: Contested ownership at handoff points. The planning team, the design team, and the data governance function all claim partial responsibility but none owns the handoff outcome. Target: Each handoff has a named owner accountable for the quality and timeliness of the output. Why it matters: Contested ownership causes rework, blame assignment, and slow escalation. Consequence if not closed: Even with improved planning data, the handoff will remain slow because nobody is accountable for ensuring the output reaches the next team in usable form. Dependencies: Independent of other gaps. Can be addressed in parallel. Intervention type: Governance change (accountability redesign, handoff ownership assignment) and organisational interface redesign.

Gap 3: Publication quality

Baseline: LTDS publication relies on manual data transcription from governance decisions to publication datasets. Error rate is estimated at 15%. Target: Automated data pipeline from governance-approved decisions to LTDS publication with validation checks. Why it matters: LTDS accuracy is a licence condition. Inaccurate publication creates regulatory non-compliance risk and undermines industry trust in the enterprise's data. Consequence if not closed: Regulatory enforcement action becomes increasingly likely. Third parties (generators, local authorities) lose confidence in capacity data, creating planning failures beyond the enterprise. Dependencies: Partially depends on Gap 1 (planning-data visibility) because publication accuracy requires accurate upstream data. Intervention type: Data governance strengthening and system-of-record clarification, supported by technology automation.

Gap 4: Governance confidence

Baseline: The governance review operates on a fixed monthly cycle. Decisions wait for the next scheduled Architecture Board meeting regardless of urgency. Evidence is assembled manually. Target: Continuous evidence-based governance with urgent decisions reviewed within five working days. Evidence automatically assembled from trusted data sources. Why it matters: Fixed-cycle governance introduces avoidable delays and prevents the enterprise from responding to urgent situations. Consequence if not closed: Governance continues to add latency to the connections journey. The enterprise cannot demonstrate responsive decision-making to the regulator. Dependencies: Partially depends on Gap 1 (planning-data visibility) and Gap 3 (publication quality) because evidence-based governance requires trusted data. Intervention type: Governance process redesign with supporting architecture tooling.

The dependency map

The London gap log reveals that Gap 1 (planning-data visibility) is foundational. It blocks or constrains Gap 3 (publication quality) and Gap 4 (governance confidence). Gap 2 (accountability clarity) is independent and can proceed in parallel. This dependency structure means the roadmap should prioritise Gap 1 and Gap 2 in the first transition state, with Gap 3 and Gap 4 following once the planning-data foundation is in place.

The London gap analysis is particularly instructive because the gaps span business, information, and governance domains. Very few of them can be closed by technology alone, which is why the gap log must name the intervention type accurately. A roadmap that treats all four gaps as technology projects would miss the governance and organisational changes that are prerequisites for the technology to succeed.