Opportunities, Solutions, Migration, and Delivery

Phase E is where architecture gaps become coherent solution candidates. When a retailer plans warehouse automation, the business, data, application, and infrastructure gaps are not handed straight to a vendor shortlist; they are clustered into a small number of workable change packages that move together. The work is to identify sensible groupings, recognise the dependencies between them, and decide how the target might realistically be realised, all under delivery pressure rather than in the abstract.

The frequent mistake is to treat Phase E as the moment to pick products and vendors, so that a list of candidate platforms feels like the solution. That skips the architectural step. The phase weakens the instant it becomes a procurement discussion before the change has been grouped coherently. The better discipline is to form coherent, dependency-aware solution candidates first and let any product selection follow that grouping, rather than letting a chosen tool dictate how the change is shaped.

Phase E also asks what each grouping is worth, not just how the work fits together. When a university consolidates its student systems, each work package carries a business value alongside its cost, benefit, and risk, so the prioritisation reflects what the change is actually worth rather than which department argues hardest for going first. The temptation is to let the loudest stakeholder set the order, but a package sequenced on value and dependency is the one that survives scrutiny when budgets tighten.

A transition architecture is a deliberately designed interim state with its own constraints, dependencies, and acceptable compromises. It is a working architecture in its own right, not a half-finished version of the target. When a streaming provider moved its catalogue to the cloud, it held a stable hybrid state, running its data centre and the cloud together, and proved each service before the next cutover. That interim state existed because the change was too large and too risky to attempt in one leap.

The common error is to treat a transition architecture as the target with some tasks deferred, as if the intermediate states were optional scaffolding or merely a project schedule. They are not. Each interim state needs its own logic so that the enterprise stays operable at every step. The stronger approach is to design each one as a genuine architecture with its own controls and assumptions, so the best transition makes the next step safer and clearer rather than simply earlier.

Phase F sequences change by dependency, value, and risk rather than by dates alone. When a bank replaces its core banking system, the work is ordered so the customer-data migration proves out before payments cut over, which keeps the sequence defensible whatever quarter each piece happens to land in. The dates still matter, but the reasoning behind the order matters more, because it is the dependency logic that protects the enterprise from sequencing change in a way it cannot survive.

The usual mistake is to think a roadmap is a Gantt chart of dated projects, so a tidy calendar of deliverables looks like a finished plan. A roadmap with no explicit dependency model tends to become a calendar of wishful thinking. The first thing to challenge in a neat but weak roadmap is its dependency logic. Every step should be justified by an explicit dependency, value, or risk-control reason, because a sequence that cannot explain why one package follows another has dates that are not credible either.

Phase F draws these threads into one document, the Implementation and Migration Plan, which sets out the work packages, their order, and the reasoning that holds them together. When a hospital phases in a new patient record system, that plan is governed as delivery proceeds through the Implementation Governance Model, with an architecture contract binding each delivery team to the agreed architecture so the build does not quietly drift from the design it was meant to realise.

The method expects architecture work to loop rather than run as a single pass. When an airline modernises its booking platform, it can deepen the application domain quickly while data governance matures more slowly, running nested and parallel cycles so each domain advances at the pace its own questions allow. Iteration is what lets scope be refined, assumptions revisited, and domains deepened at different speeds as the work reveals what it really involves.

The common misreading is to treat the cycle as a strict stage-gate where each phase must be fully closed before the next can begin. The more telling version of this error is talking about iteration while still managing the work as if every phase had to finish before the next could start. When the method feels rigid, the cause is usually the implementation, not the concept. Planning deliberate iteration points, and treating the cycle as looping not linear, protects the enterprise from the false certainty of committing before delivery realities are clear.

Partitioning splits a large architecture into manageable slices by level and scope while keeping the shared interfaces between them visible. When a university divides student records, finance, and research computing into separate partitions, it still names the identity and reporting interfaces that every partition depends on. The point is to work across strategic, segment, capability, or solution-level slices without losing sight of the constraints they hold in common.

The mistake is to treat partitioning as simply chopping the work into separate teams, so that a clean org-style boundary is assumed to be a good architectural one. Partitioning turns harmful the moment it is used to push difficult cross-cutting problems out of sight. The discipline is to draw boundaries that clarify ownership while keeping cross-partition interfaces explicit, so the best partitioning makes ownership clearer without lying about how the parts depend on one another.

Architecture governance and sprint delivery are meant to run together, with the architecture stating what must stay stable and what may iterate. A scale-up can ship features every sprint while routing cross-team interface changes and repository updates through scheduled architecture review points. The real question is never the method against agility; it is how architecture intent, guardrails, and review points are translated into delivery increments without losing coherence across teams.

The mistaken framing treats this as a choice, where governance means delay and agility means abandoning structure. The failure modes run both ways: agile language used to avoid architectural accountability, or architecture language used to resist incremental learning. The better practice is to translate architecture intent into sprint-ready guardrails and named review points, so local increments stay traceable and add up to coherent enterprise change rather than drifting apart one autonomous decision at a time.

Readiness measures whether the enterprise can absorb a change across governance, data quality, platform, and people, and it directly shapes the sequence. A hospital phases a records rollout ward by ward because clinical adoption capacity, not the software, sets the safe pace. Readiness covers far more than training: operating capability, governance maturity, data quality, platform preparedness, stakeholder buy-in, and delivery dependence all decide how fast change can be introduced.

The mistake is to treat readiness as mostly training and to check it near the end once the design is finished, which turns it into an excuse for delay rather than a design input. Assessed late, it can only slow things down. Assessed early, across governance, data, platform, and adoption, it shapes sequencing, transition states, and support needs before the enterprise commits to a path it cannot realistically absorb.