Opportunities and solutions

The earlier stages explain the problem, the business shape, the information landscape, and the technology posture. Phase E exists because the enterprise still has to decide how those findings turn into coherent change. It is the point where architecture starts shaping implementable solution paths without surrendering control to delivery habit or procurement gravity.

Phase E sits at a critical boundary. Before it, the enterprise has been analysing and describing. After it, the enterprise will be sequencing and delivering. Phase E is the bridge, and the quality of that bridge determines whether the architecture actually influences what gets built or quietly gets filed away while delivery teams make their own grouping decisions.

That is why Phase E is not just a creativity phase. It is disciplined grouping work. The method asks which architecture building blocks belong together as one meaningful opportunity and which combinations would create a weak or incoherent path. The standard is clear: the grouping should be driven by architectural logic, not by vendor availability, team structure, or calendar convenience.

C220 Part 1 sets three objectives for Phase E. These objectives are not optional recommendations. They describe what Phase E must accomplish for the ADM cycle to remain coherent. Understanding each objective is essential because it prevents teams from treating Phase E as an unstructured brainstorming exercise.

Objective 1: Generate the initial complete version of the Architecture Roadmap

Phase E is where the Architecture Roadmap first takes shape as a complete view, based on the gap analysis and the candidate roadmap components from Phases B, C, and D. Earlier phases may have sketched fragments, but Phase E assembles them into a roadmap that covers all four domains and shows how the enterprise intends to move from baseline to target. The word "initial" is important. The roadmap will be refined in Phase F during migration planning, but Phase E is responsible for producing the first version that is complete enough to test.

Objective 2: Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value

Not every transformation can be delivered in one step. Phase E must assess whether the enterprise needs transition architectures and determine how many intermediate states the transformation requires. This assessment should be based on risk, dependency complexity, organisational absorption capacity, and the number of domains affected simultaneously. If the answer is that one direct move is possible, that conclusion should be explicit and justified.

When incremental delivery is required, Phase E designs the transition states. Each transition architecture must deliver recognisable business value in its own right, not merely represent a halfway point on the route to the target. This prevents the common failure of treating transition states as arbitrary release boundaries. A transition architecture that delivers no standalone value is likely to lose executive support before the next state is reached.

Objective 3: Define the overall Solution Building Blocks to finalise the Target Architecture

Phase E is where the architecture moves from describing the capability the enterprise needs, expressed as architecture building blocks, to identifying what will actually provide that capability, expressed as Solution Building Blocks. The Solution Building Blocks finalise the Target Architecture by showing how each required capability will be realised: build it internally, buy a commercial or open-source product, or reuse an existing asset. This is the objective that connects the architecture views to deliverable reality without handing the boundaries over to a vendor conversation. Note the distinction: choosing the build, buy, or reuse category for a capability is architecture work; choosing which named vendor fulfils a "buy" decision is the procurement activity Section 44.5 rules out of scope.

Steps, not objectives: work packages and transition activities

Two Phase E activities are often misremembered as objectives, which matters in an exam context. Identifying and grouping major work packages, and identifying the Transition Architectures themselves, appear in C220 Part 1 among the Phase E steps, not the objectives. The work still has to be done well: a work package is not a project name or a sprint label but an architecturally meaningful unit of change that advances the enterprise from one governed state to the next, and the grouping must explain what changes, what depends on what, and which transition state each package supports. Section 44.6 walks through the step sequence in full.

Understanding the inputs and outputs matters because it shows what Phase E inherits, what it must produce, and where the handoffs to Phase F and governance sit. If any input is weak, Phase E will produce weak groupings. If any output is missing, Phase F cannot sequence the work reliably.

Key inputs

• Architecture Definition Document. The target and baseline architectures across all four domains, including the gap analysis results. Phase E inherits the problem structure, not just the target picture.
• Architecture Requirements Specification. The constraints, assumptions, and requirements that the solution groupings must respect. Without this, groupings may violate requirements that were already agreed.
• Architecture Vision. The original scope, purpose, and stakeholder concerns that shaped the engagement. Phase E should trace its groupings back to the vision to confirm they remain aligned.
• Change requests from Requirements Management. Any scope or constraint changes that have emerged since the domain phases completed. Phase E must absorb these before grouping, not after.
• Capability assessments from Phases B through D. The maturity, gap, and readiness findings that shape what is achievable in each domain.

Key outputs

• Initial Architecture Roadmap. The first complete version showing work packages, transition architectures, and the proposed order of change.
• Transition Architecture descriptions. The designed intermediate states, each with a stated purpose, known compromises, and exit conditions.
• Work package definitions. Each package describes the architectural change it delivers, its dependencies, and which transition state it supports.
• Implementation and Migration Strategy. The high-level approach to delivery: will the enterprise use a big-bang approach, phased delivery, parallel running, or a pilot strategy? This choice shapes everything that follows.
• Updated Architecture Definition Document. Reflecting any changes that the solution-grouping analysis has exposed in the target architecture itself.

Grouping gaps into solution paths is the core intellectual work of Phase E. The enterprise must decide which changes travel together and which must be separated. The following four-fit test provides the discipline that prevents groupings from being arbitrary.

Business fit

The grouping improves a meaningful business outcome or capability rather than collecting unrelated technical upgrades. A grouping that spans three different business capabilities without a shared outcome is architecturally weak even if the components happen to use similar technology. A grouping that improves one end-to-end value stream is architecturally strong because the business can explain why those changes belong together.

Information fit

The grouping respects information authority, publication discipline, and the semantic relationships established in the information architecture. If two components share a data dependency, they may need to travel together. If they use the same data entity but with conflicting authority rules, they may need to be separated until the authority conflict is resolved.

Application and technology fit

The components support one another in delivery and operation instead of forcing the enterprise into awkward cross-dependencies immediately. If replacing Application A requires Platform B to be in place first, those two changes have a technology dependency that the grouping must acknowledge.

Governance fit

The grouping can be reviewed, sequenced, and justified without hiding major risk or exception decisions. If a grouping is so large that no single review forum can evaluate it meaningfully, the grouping needs to be reconsidered. If a grouping contains a known exception to an architecture principle, that exception should be visible rather than buried inside the package.

Phase E is one of the most frequently misunderstood parts of the ADM because it sits at the boundary between architecture and delivery. It is helpful to be explicit about what it does not do, because each of these mistakes causes real damage in practice.

It is not a vendor selection exercise.Phase E produces architecturally grouped solution candidates, not product shortlists. Vendor selection is a procurement activity that should happen after the grouping logic is established, not before. When vendor conversations start before Phase E grouping is done, the vendor's product boundaries often replace the enterprise's architecture boundaries, as the opening story illustrated.

It is not a funding request disguised as architecture. Phase E outputs should be readable as architecture decisions, not as budget proposals. If the primary purpose of the Phase E document is to secure investment approval rather than to justify how gaps have been grouped, the architecture intent has been subordinated to a financial conversation.

It is not the final roadmap. Phase E produces the initial roadmap, but sequencing logic, readiness assessment, and migration planning in Phase F will refine it. Teams that treat the Phase E roadmap as final often resist the adjustments that Phase F evidence would justify.

It is not permission to forget earlier phases. The gap analysis, capability assessment, information authority decisions, and technology constraints from Phases B through D are Phase E inputs. If Phase E groupings contradict those earlier findings without explicit justification, the architecture has lost its internal consistency.

C220 Part 1 describes Phase E as a sequence of eleven steps. The order matters more than it first appears: the standard opens with change attributes and business constraints, and only then moves to gap consolidation. That sequencing is deliberate. Knowing what matters strategically and what the business will tolerate shapes how the gaps get read, rather than the other way round. The steps are not rigid, but they establish a logical flow that prevents the enterprise from jumping to solutions before the problem grouping is sound.

Step 1: Determine key corporate change attributes. Before touching the gap analysis, establish the strategic importance, risk appetite, cost tolerance, and implementation complexity the enterprise is prepared to accept. These attributes are the lens through which every later grouping decision gets tested.

Step 2: Determine business constraints for implementation. Identify regulatory deadlines, contractual obligations, budget cycles, and organisational constraints that limit what can be grouped and when. A grouping that ignores a regulatory deadline is not just architecturally weak. It is operationally dangerous.

Step 3: Review and consolidate gap analysis results. Gather the gap analysis outputs from Phases B, C, and D into one consolidated view, now read against the change attributes and constraints from Steps 1 and 2. This step matters because the domain phases often produce gap lists independently. Phase E is the first moment when the enterprise sees all four domain gaps together and can identify cross-domain patterns, shared dependencies, and conflicts.

Step 4: Review consolidated requirements across related business functions.Check that the requirements feeding the gap picture are coherent across the business functions the changes will touch, not just within a single domain team's view.

Step 5: Consolidate and reconcile interoperability requirements. Examine how the grouped solutions must interact with one another and with retained systems. Interoperability requirements often reveal that two apparently separate groups share a hidden integration dependency.

Step 6: Refine and validate dependencies. Map the dependencies between work packages explicitly. This step catches the cases where a grouping looks clean until you realise that Package A cannot start until Package C is complete, even though they are in different transition states.

Step 7: Confirm readiness and risk for business transformation. Assess whether the enterprise is ready to absorb the change each grouping requires. If governance maturity, data quality, or organisational capacity is insufficient, the grouping may need to be redesigned or the transition pace slowed.

Step 8: Formulate the implementation and migration strategy. Decide the overall delivery approach: phased, parallel, pilot, or direct cutover. This strategy shapes the transition architecture design and the work-package boundaries.

Step 9: Identify and group major work packages. Group the gaps, building blocks, and solutions into work packages that can be assigned to specific transition states. This is where the grouping logic from earlier steps becomes concrete units of change.

Step 10: Identify Transition Architectures. Determine the intermediate states the work packages will deliver, each one designed to stand on its own as a governed position rather than an arbitrary halfway point.

Step 11: Create the Architecture Roadmap and Implementation and Migration Plan. Assemble the outputs into the initial Architecture Roadmap with defined transition states. This is the Phase E deliverable that Phase F will take forward for sequencing and migration planning.

The handoff from Phase E to Phase F is one of the most important transitions in the ADM. If Phase E hands forward a weak or incomplete set of outputs, Phase F cannot produce a credible migration plan. The handoff should include:

1. A small set of coherent change groupings that can be understood by business and delivery audiences alike. Each grouping should pass the four-fit test.
2. A clear sense of the dependencies that will shape the transition path, including both intra-group and inter-group dependencies.
3. The architectural rationale that explains why the grouping makes sense, so that Phase F reviewers can test the logic rather than simply accepting the arrangement.
4. Defined transition architectures with stated purposes, known compromises, and exit conditions. Each transition state should be readable as an intentionally designed interim position, not as an incomplete target.
5. Enough structure for Phase F to test migration logic and readiness honestly. If Phase E outputs are too vague for sequencing, Phase F will either invent its own grouping or produce a decorative roadmap.

Understanding how Phase E typically fails is as important as understanding how it should work. Each failure mode below is drawn from patterns that recur across industries and enterprise sizes.

Procurement capture.Vendor conversations begin before the architecture grouping is stable, and product boundaries replace architecture boundaries. The enterprise ends up buying a solution that fits the vendor's product architecture rather than the enterprise's gap architecture.

Wish-list Phase E. The team produces a long list of possible solutions without any grouping logic. The list looks impressive but cannot be sequenced because no one has explained which items depend on each other or which should travel together.

Single-domain grouping. The groupings are produced by each domain team independently. The business architecture team groups business gaps, the technology team groups technology gaps, and nobody checks whether the cross-domain dependencies are coherent.

Premature commitment. Phase E outputs are treated as a final delivery plan rather than as an initial roadmap that Phase F will refine. This prevents readiness and sequencing evidence from reshaping the path.

Missing transition states. The team jumps from baseline to target without designing the intermediate states. The transformation then proceeds without governed waypoints, and the enterprise discovers mid-delivery that the current position is incoherent.

The London case illustrates Phase E at full complexity. The enterprise operates across business, information, application, and technology domains simultaneously, and the gaps from each domain interact in ways that make single-domain grouping dangerous. The Phase E grouping for London must hold all four domains together.

London gap consolidation

The business architecture revealed capability gaps in connection handling, planning reuse, and stakeholder transparency. The information architecture revealed gaps in data authority, publication quality, and metadata standards. The application architecture revealed gaps in case management, evidence workflow, and integration patterns. The technology architecture revealed gaps in OT visibility, telecom resilience, and cyber assurance.

Consolidating these gaps reveals cross-domain dependencies. For example, the publication quality gap (information) depends on data authority settlement (information) and case management improvement (application). You cannot fix publication quality without fixing both of those first. That dependency shapes the grouping.

London solution groupings

Applying the four-fit test to the London gaps produces groupings like:

• Group 1: Case spine and evidence model. Business fit: improves the connections value stream end to end. Information fit: establishes the evidence authority that later groups depend on. Technology fit: requires case-management platform capability. Governance fit: can be reviewed by a single architecture board.
• Group 2: Authority and publication controls. Business fit: enables regulatory transparency. Information fit: codifies data ownership. Technology fit: builds on Group 1 platforms. Governance fit: introduces publication review discipline.
• Group 3: Model and standards pipeline. Business fit: enables planning reuse and standards consistency. Information fit: governed metadata. Technology fit: model tooling. Governance fit: standards board integration.
• Group 4: Cross-layer assurance hardening. Business fit: resilience and safety. Information fit: threat intelligence integration. Technology fit: OT/IT convergence. Governance fit: cross-layer review.

Each grouping is cross-domain. None of them can be understood as a technology-only or business-only initiative. That cross-domain coherence is what makes the London Phase E output architecturally strong rather than a collection of separate projects that happen to run in parallel.