Roadmapping & Transition

## Baseline against target Gap analysis in enterprise architecture is a structured, layer-by-layer comparison between the **baseline architecture** (a description of what is actually running today) and the **target architecture** (the future-state vision the organization is working toward). Frameworks such as **TOGAF** split both descriptions into four layers, because a change at one layer (say, replacing a database engine) has knock-on implications at others (data migration, application connection strings, operational runbooks): | Layer | What it holds | |---|---| | Business | processes, organization, governance | | Data | entities, information flows, ownership | | Application | systems, services, integrations | | Technology | infrastructure, platforms, networks | ## Building blocks and the four buckets For each layer, the architect inventories the **architecture building blocks (ABBs)** — named, reusable components such as 'customer master data store' or 'payment authorization service' — present in the baseline and target descriptions, then classifies each block into one of four buckets: - **Retained** unchanged. - **Eliminated** — present in baseline, absent from target. - **New** — absent from baseline, present in target. - **Changed** — present in both but materially different, e.g., re-platformed or re-scoped. The result is a **gap matrix**, one row per building block, that becomes the raw input to the next step: each identified gap is translated into one or more **work packages** — discrete units of deliverable work with a description, rough size, dependency list, and eventually an owning team — which feed the roadmap-building phase. ## Why the discipline exists The reason this discipline exists rather than architects simply sketching an end-state and handing it to delivery teams is that 'vision to delivery' is where most transformation programs actually fail. A target architecture alone tells you where you're going but not what specifically has to change to get there, in what order, or how big that change is. Gap analysis forces that translation to happen explicitly and early, before budget and delivery commitments are made, and it does so in a form (a structured matrix, not prose) that both business and technical stakeholders can review and challenge. It also surfaces second-order gaps that a purely top-down vision exercise misses — for instance, a target application-layer change often implies a data-layer gap (a migration or a change-data-capture pipeline) that nobody thought to ask about until the layers are compared side by side. ## The central trade-off The central trade-off is **thoroughness versus speed and usefulness**. A full, four-layer gap analysis across a large enterprise portfolio can take months to produce and, done badly, becomes a heavyweight document that delivery teams never open — accurate in principle but disconnected from how the work actually gets sequenced. Go too coarse, and gaps are stated at a level ('modernize the payments platform') too vague to size or assign, silently pushing the real analysis downstream into delivery, where it surfaces as mid-sprint surprises instead of pre-commitment risk. Granularity has a similar tension: - **Very fine-grained gaps** are easy to size individually but hard to sequence and communicate. - **Coarse-grained gaps** are easy to communicate but hide sub-dependencies that blow past estimates. ## Failure modes in production programs In production programs, gap analysis fails in a few recognizable ways. 1. The most common is a **stale or inaccurate baseline** — nobody has kept the current-state inventory up to date, shadow-IT systems aren't captured, and the analysis ends up comparing the target to a fiction, so 'eliminated' systems turn out to still be carrying live traffic when decommission time comes. 2. A second is a **frozen target that itself goes stale** — a three-year architecture vision written once and never revisited means every subsequent gap analysis measures progress against an already-obsolete future. 3. A third is **orphaned gaps**: differences are identified and documented but never converted into resourced, owned work packages, so the gap analysis becomes shelfware that satisfies a governance checkpoint without changing what delivery teams actually build. 4. A fourth, more subtle failure is **treating every gap as a technology problem** when some are actually organizational or process gaps that no application or infrastructure change alone will close. ## A worked example Consider a retail bank migrating its core ledger off a mainframe COBOL/DB2 system toward an event-driven, cloud-native platform. - The **business-layer** gap analysis might show the target's real-time balance-update capability doesn't exist yet, so the batch end-of-day settlement process is deliberately retained as an interim capability. - The **data-layer** analysis surfaces that customer account data lives in a hierarchical DB2 schema with no equivalent in the target's relational event-sourced model, producing a work package to build a change-data-capture pipeline as a bridge rather than a one-shot cutover. - The **application-layer** analysis shows the monolithic COBOL transaction processor being eliminated in stages, replaced domain-by-domain (accounts, then payments, then cards). - The **technology-layer** analysis tracks mainframe capacity declining in step with cloud footprint growing. Each becomes a sized, owned work package with explicit dependencies — exactly the workflow that feeds the next phase of roadmap sequencing.