Technology gap analysis, constraints, and trade-offs

A technology gap is not simply the absence of a named product. It is a missing or weak technology capability, property, or control that prevents the target architecture from working as intended. Product choice may appear later, but the architectural gap should be described in enterprise terms first.

A gap described as "we lack a container orchestration platform" tells the Architecture Board nothing about what the enterprise cannot do. A gap described as "we lack the ability to deploy, scale, and recover application services independently across three availability zones" tells the board what capability is missing and why it matters.

C220 Part 2 defines gap analysis as a technique for comparing the baseline and target to identify what needs to change. The technique uses a matrix with baseline components on one axis and target components on the other. Components that appear in the baseline but not the target are candidates for retirement. Components that appear in the target but not the baseline are gaps. Components that appear in both may need modification.

The matrix is a useful structure, but it needs interpretation. A gap that appears on the matrix must be enriched with consequence (what happens if it persists), constraints (what limits the options for closing it), and priority (how urgently it needs to be addressed relative to other gaps). Without that enrichment, the matrix is just a comparison table, not architecture reasoning.

G249 provides guidance on recording architecture decisions in a structured, reviewable format. An Architecture Decision Record (ADR) captures the context, options, reasoning, and outcome of a significant architecture choice. The G249 framework is directly relevant to gap analysis because every significant gap requires a decision about how to close it.

A well-structured ADR contains the following elements:

1. Title. A short, descriptive name for the decision.
2. Status. Whether the decision is proposed, accepted, deprecated, or superseded.
3. Context. The enterprise situation that makes this decision necessary. This should reference the gap, the upstream architecture decisions that created the gap, and the business consequences of leaving it unaddressed.
4. Decision. The chosen option and a clear statement of what the enterprise will do.
5. Options considered. The alternatives that were evaluated, including the constraints that made some options unrealistic.
6. Consequences. The expected outcomes of the decision, including both benefits and accepted downsides. Every option has weaknesses. The ADR should state them honestly.
7. Rationale. The reasoning that led to this choice over the alternatives. This should reference architecture principles, stakeholder concerns, constraints, and enterprise priorities.

The ADR discipline prevents the most common governance failure: a decision that nobody can explain six months later. When the Architecture Board reviews a gap closure decision, the ADR provides the reasoning. When a new architect joins the team, the ADR set provides the decision history. When conditions change and a decision needs to be revisited, the ADR shows what was known at the time and what trade-offs were accepted.

A target architecture that ignores constraints is not a target. It is a wish list. Constraints reshape what a sensible option can be, and the architecture must account for them explicitly. Four categories of constraint are most important.

Operational constraints. Existing support models, specialist estate realities, or operational risk limits may rule out otherwise attractive options. In London, the OT support team has specific skills and processes that an entirely new platform would require retraining. That is an operational constraint that affects the realistic timeline for platform migration.

Regulatory and assurance constraints. Evidence, security, or publication expectations may require capabilities the simplest option does not deliver. In London, the LTDS publication obligation requires an audit trail that some lightweight data pipelines cannot provide.

Skills and operating capability. A technically elegant choice can still be a bad architecture decision if the enterprise cannot run it safely and reliably. In London, a cutting-edge stream-processing platform might be the ideal technical solution for telemetry, but if nobody in the operations team has the skills to manage it, the platform is a liability rather than an asset.

Time and migration pressure. A target may be valid in principle but unrealistic in the near term because the transition burden is too high. In London, replacing the entire telecom infrastructure might resolve the carrier-concentration risk, but the migration complexity and cost may mean the enterprise needs to accept the risk for one to two years while a staged migration is executed.

Gap analysis goes wrong in predictable ways. Recognising the patterns helps the architecture team avoid them.

The shopping list. Gaps are described as products the enterprise does not own. The analysis reads like a procurement request rather than an architecture argument. The test: remove all product names. If nothing coherent remains, the gap analysis is product-led rather than capability-led.

The complaint about legacy. Gaps focus on what is old rather than what is insufficient. Age is not an architecture argument. A twenty-year-old system that meets the enterprise's resilience, interoperability, and governance needs is not a gap. A two-year-old system that cannot support the target architecture is.

The vague aspiration. Gaps are described in language so general that no option could be evaluated against them. "Better resilience" is not a gap statement. "The inability to recover publication services within four hours after a telecoms outage" is.

The missing consequence. Gaps are listed without explaining what happens if they persist. Without consequence, the enterprise cannot prioritise. Every gap should carry a consequence statement: "If this gap persists, the enterprise cannot [specific business outcome]."

The missing constraint. Options are listed without acknowledging what makes some of them unrealistic. Without constraints, the gap analysis suggests that any option is equally available, which is almost never true.

Gap analysis in Stage 5 should prepare the enterprise for the roadmap and migration planning that comes in Stage 6 ( Phase E and Phase F). Each significant gap should carry enough information to support sequencing decisions.

The Architecture Board needs to know: which gaps are prerequisites for other changes; which gaps carry the highest consequence if they persist; which gaps are constrained by skills, budget, or operational risk in ways that affect timing; and which gaps can be addressed in parallel without creating dependency conflicts.

If the gap analysis does not carry this information, the Stage 6 roadmap will either invent it from scratch or ignore it entirely. Neither outcome is good architecture practice. The connection between gap analysis and roadmap logic is one of the most important hand-offs in the ADM.

In London, the gap analysis should show that the OT/IT network separation must precede the publication pipeline build (because the pipeline depends on the separated network). The telecom resilience programme can run in parallel with the publication pipeline because they address different dependencies. The connections reform workflow depends on the API gateway and workflow engine being in place. These sequencing dependencies are the bridge between Stage 5 gap analysis and Stage 6 roadmap planning.

The London case uses technology gap analysis for resilience, interoperability, publication support, telecom visibility, and operational dependency control.

Example gap: publication pipeline independence. Gap statement: the enterprise cannot publish LTDS data within regulatory timescales if the OT data store is unavailable. Consequence: regulatory non-compliance and reputational damage. Constraints: the publication pipeline must have read access to analytical data without depending on OT system availability; the separation must not compromise data integrity. Trade-off: a fully replicated data store provides the best availability but doubles storage cost; an event-driven copy with eventual consistency provides adequate availability at lower cost but introduces a short data-freshness delay. ADR decision: event-driven copy with four-hour consistency window, reviewed at next architecture cycle.

Example gap: telecom carrier diversification. Gap statement: the enterprise has a single telecom carrier dependency across SCADA telemetry, smart-meter collection, and fault reporting. Consequence: a carrier outage degrades all three capabilities simultaneously. Constraints: carrier diversification requires physical infrastructure changes and contract renegotiation (12 to 18 months); the OT network cannot be disrupted during migration. Trade-off: full diversification is the strongest position but requires 18 months of parallel running; a local fallback for critical SCADA paths provides faster risk reduction at lower cost. ADR decision: implement local SCADA fallback within six months; pursue full diversification over 18 months as a staged programme.

• London trade-offs should be recorded in enterprise language first. A trade-off between resilience and migration speed is an enterprise discussion.
• A good Stage 5 gap view prepares the learner for roadmap logic in Stage 6. Each London gap should carry consequence, dependency, and constraint information.
• The G249 ADR framework provides the structure for recording gap closure decisions so they survive governance review and team turnover.
• The LTDS publication obligation creates hard gaps: if the technology cannot support timely, accurate, auditable publication, the gap is regulatory, not just operational.