Stage 6 summary. Opportunities, Solutions, Migration, and Delivery

Phase E is where the enterprise stops describing its architecture and starts shaping how the change will be delivered. It consolidates the gap analysis results from Phases B, C, and D into one view and groups the resulting changes into coherent solution paths. C220 Part 2 gives the phase three objectives. Generate the initial complete version of the Architecture Roadmap, determine whether an incremental approach is required and, if so, identify Transition Architectures that will deliver continuous business value, and define the overall Solution Building Blocks to finalise the Target Architecture. Identifying and grouping major work packages, and identifying the Transition Architectures themselves, appear among the Phase E steps rather than the objectives, a distinction that matters under exam conditions.

The grouping discipline is the four-fit test. Business fit asks whether a grouping improves one meaningful outcome or value stream rather than collecting unrelated upgrades. Information fit asks whether it respects data authority and publication discipline. Application and technology fit asks whether the components support one another without awkward cross-dependencies. Governance fit asks whether the grouping can be reviewed and sequenced without hiding a major risk or an exception to a principle. Each grouping also carries a business value alongside its cost, benefit, and risk, so prioritisation reflects what the change is worth rather than which stakeholder argues hardest.

The phase is equally defined by what it is not. It is not vendor selection, because product boundaries chosen early quietly replace architecture boundaries. It is not a funding request disguised as architecture, and it is not the final roadmap, which Phase F will refine with sequencing and readiness evidence. In London, applying the test to the consolidated gaps produced four cross-domain groups, starting with the case spine and evidence model that every later group depends on.

A transition architecture describes the enterprise at an architecturally significant state between the baseline and the target. It is a working architecture in its own right, never the target with some tasks deferred. Five properties make one real. A clear reason to exist, known compromises made visible so temporary arrangements do not drift into permanent fixtures, visible controls for the interim state and not just the target, a bounded exit path stated as testable architectural conditions rather than dates, and standalone value, so the programme keeps its mandate and has a coherent fallback if later states prove unachievable.

A work package is an architecturally meaningful unit of change, not a delivery label. Its anatomy covers the architectural scope stated in building-block terms, its dependencies, which can be technical, informational, organisational, or temporal, its transition-state assignment, a business value statement, a risk and constraint register, and the compliance and standards requirements that apply. A work package is not a sprint, which is a time box, not a project, which is a management construct, not a release, which is a deployment event, and not a budget line.

Governance applies at every interim state, not just at final delivery. The Architecture Board confirms that exit conditions have been met before the enterprise enters the next state, work packages are reviewed for compliance before delivery begins, exceptions are documented and time-bounded, and the Architecture Repository reflects each transition state as it is reached. London needs at least three transition states, and its four work packages, WP1 through WP4, carry explicit dependency chains between them.

Phase F takes the initial Architecture Roadmap from Phase E and subjects it to migration planning. Its three objectives from C220 are to finalise the Architecture Roadmap and the Implementation and Migration Plan, to coordinate the plan with the enterprise's approach to managing change, and to ensure that the business value and cost of work packages are understood by key stakeholders. Confirming that the transition is actually achievable is essential practice rather than a fourth objective. The two headline outputs serve different audiences. The Architecture Roadmap answers what changes, in what order, and why, for the board and leadership, while the Implementation and Migration Plan translates that order into projects, resources, timelines, and budgets for delivery.

This course groups the sequencing drivers into seven criteria. Dependency is the strongest, because violating a genuine dependency causes failure rather than mere inefficiency. Value logic brings meaningful benefit early enough to keep executive support. Risk logic tests the highest-uncertainty items first, while the enterprise can still adapt. Readiness logic paces the change to what the organisation can absorb. Cost and resource logic respects budget cycles and scarce skills, regulatory and contractual obligations are fixed inputs, and stakeholder impact logic checks whether the same group can absorb overlapping packages at once.

The failure modes are recognisable. Decorative sequencing, bars arranged to look balanced across quarters, is the most common, followed by hidden dependencies, value-blind ordering, risk deferral, readiness denial, and frozen roadmaps that cannot respond to learning. Phase F also confirms the Implementation Governance Model, with an architecture contract binding each delivery team to the agreed architecture, which is exactly what Phase G governs implementation against. The review discipline asks of every step why it must precede the next and what would break if the order were reversed.

The standard is explicit that the ADM is iterative, over the whole process, between phases, and within phases. The circular diagram is not decorative. Within-phase iteration refines a phase's outputs as evidence improves. Cross-phase iteration loops backward when later work exposes a flawed earlier assumption, the pattern that stops a technology architecture being built on a business architecture the enterprise has already abandoned. Around these sit the named cycles from C220's Applying the ADM guidance, Architecture Capability iteration through the Preliminary Phase and Phase A, Architecture Development iteration through Phases B, C, and D, Transition Planning iteration through Phases E and F, and Architecture Governance iteration through Phases G and H, plus multi-level iteration between enterprise-wide and initiative-level work.

Knowing when to loop matters as much as knowing how. The signals include an invalidated assumption, an authority or boundary that proves weaker than expected, a delivery reality gap, a failed evidence gate, an escalated stakeholder concern, an unresolvable cross-domain conflict, and a formal scope change from Requirements Management. Refusing to loop when the evidence demands it wastes more than the loop would cost.

What separates learning from chaos is governance. Four controls keep iteration disciplined. The decision to loop is taken explicitly by the Architecture Board, the scope of the loop is defined precisely, the downstream impact is assessed before the loop begins, and the loop is time-bounded so refinement does not become perfectionism.

The architecture landscape is the total set of architectures the enterprise maintains and governs at any point in time, viewed across abstraction level, state, and time, and held in the Architecture Repository with the Enterprise Continuum as its classification frame. C220 Part 3 defines three levels of architecture. Strategic architecture sets enterprise-wide direction, principles, and constraints. Segment architecture details a major division or capability group. Capability architecture guides delivery of a specific capability increment. Each lower level must stay consistent with the level above, and the third level is named capability architecture, because solution architecture is a separately defined concept in the standard.

Partitioning divides that landscape into portions teams can own. The standard describes partitioning by characteristics such as breadth, depth, time period, and architecture domain, which this course expands into six practical criteria, by domain, organisational unit, geography, time horizon, subject matter, and capability or value stream. Every criterion trades scope management against dependency visibility, and partitioning turns into fragmentation the moment cross-cutting problems disappear between the boundaries. Five mechanisms keep partitions coherent, Architecture Board oversight of the joins, cross-partition dependency maps, shared standards and principles with governed exceptions, one repository for all partitions, and interface contracts on shared services and data.

The landscape is also the structural evidence behind portfolio decisions. Gap analysis, dependency mapping, risk assessment, and transition-state logic feed investment sequencing, building on the capability planning approach in G233, and a useful distinction separates strategic portfolio decisions, which set long-term direction, from tactical ones, which must still respect the landscape. London partitions primarily by capability and value stream, with strategic principles constraining all lower-level work.

The supposed conflict between TOGAF and agile delivery is usually exaggerated. The real friction comes from unclear decision rights, over-centralised review, or the absence of a feedback path from delivery back to the architecture. The standard says the ADM is intended to be used flexibly and tailored, and the adaptation guidance groups into four practical patterns, iteration across phases at different depths, phase selection so a narrow change can enter at Phase E, artefact selection tied to the decision each artefact informs, and governance scaled to the risk carried in the increment.

G210 makes the integration concrete. An architecture runway keeps a rolling buffer of just-enough decisions, views, and constraints slightly ahead of delivery. Sprint-aligned reviews at each boundary ask whether the sprint stayed within guardrails and whether it produced learning that should update the architecture. Detail emerges progressively, and decision-point governance escalates only what crosses the board-level threshold. The boundary the enterprise must draw explicitly is what stays stable and what iterates. Architecture principles, major boundary decisions, authority rules, and the transition-state logic stay stable across sprints, while detail design within guardrails, user-facing refinements, performance tuning, and feedback-driven corrections iterate safely.

G188 supplies the project-management bridge, and it is method-neutral. Architecture outputs from Phases E and F become project inputs, project stage gates become architecture compliance checkpoints against the architecture contract, and change control stays aligned so exceptions and project changes flow through both processes. In London, the OT/IT boundary and the information authority model stay stable while the internals of individual connection-offer services iterate within published patterns.

The business transformation readiness assessment technique in C220 Part 2 evaluates whether the enterprise can absorb a change at the planned pace, and its findings should modify the Architecture Roadmap rather than merely annotate it. Assessed early, readiness shapes work-package order, transition pace, and risk mitigation before the enterprise overcommits. Assessed late, it can only delay an agreed plan or be politely ignored. The technique identifies twelve readiness factors, vision, desire, need, business case, funding, sponsorship, governance, accountability, workable approach and execution model, IT capacity to execute, enterprise capacity to execute, and enterprise ability to implement and operate.

Each factor is scored on two dimensions, a readiness rating based on evidence rather than optimism, and an urgency of improvement. The combination creates four quadrants that drive the roadmap directly. High readiness with low urgency proceeds as planned, high readiness with high urgency proceeds under close monitoring, low readiness with low urgency becomes a managed risk with compensating controls, and low readiness with high urgency is a sequencing constraint, the dependent work package is deferred, the pace is slowed, or a dedicated readiness improvement precedes the main transformation.

Token readiness has three symptoms, assessment after the roadmap is committed, findings with no authority to change the plan, and a single-dimension exercise that checks only technology or training. In London, each of the four work packages has a different readiness profile. WP1 starts first because its regulatory driver and readiness are strongest, and WP4 cannot run at full pace alongside WP2 and WP3 because enterprise capacity is already constrained.

The final module assembles everything the stage taught into one architecture-controlled transformation. Four work packages are sequenced by dependency logic. WP1, the case spine and evidence model, comes first because every later package consumes its evidence-quality rules. WP2, authority and publication controls, stabilises data authority and governed publication. WP3, the model and standards pipeline, makes planning outputs consistent, and WP4, cross-layer assurance hardening, protects the new state, starting foundational controls in parallel but reaching full capability only after the others stabilise. The packages sit inside three transition states, evidence foundation, publication and modelling discipline, and full operating capability, each delivering recognisable business value in its own right.

Between the states sit three evidence gates, and a gate is a decision point, not a status report. At each gate the Architecture Board can proceed, proceed with conditions, or hold and revise, and that authority is the difference. The gates test architectural conditions, evidence quality, information authority, assurance integration, and compliance conformance, rather than delivery milestones, because a project can be on time and on budget while producing an architecturally ungoverned state.

Readiness findings flow directly into gate conditions. Weak information readiness for WP1 becomes a Gate 1 condition that the evidence model works with real case data. Constrained enterprise capacity becomes a Gate 2 condition giving the board explicit authority to slow the pace, and scarce OT/IT specialist capacity becomes a Gate 3 condition on assurance completeness. The result is a roadmap that stays under architecture control while remaining adjustable as delivery evidence emerges.

The London thread through this stage is the assembly of one defensible change path. Phase E grouping turned the consolidated gaps into four cross-domain groups, transition design gave the journey three states that each stand on their own, and Phase F sequenced the work by explicit reasoning, data-authority codification before publication migration because publishing from unclear authority creates compliance risk, with Ofgem transparency deadlines treated as fixed inputs. Readiness profiles then set the pace, starting WP1 on its strong readiness and regulatory driver and stopping WP4 from running at full pace while capacity is constrained.

Hold the discipline the case demonstrates. Architecture stays in control of how change happens, through gates that test evidence rather than dates, while the plan remains adjustable as delivery evidence emerges. Every stage that follows assumes this roadmap exists, and Stage 7 formalises the governance structures the gates rely on.