Phase E: Opportunities and Solutions
Turn gaps into a delivery approach: work packages, Transition Architectures, and the initial Architecture Roadmap.
About this phase
Phase E is the first phase directly concerned with implementation. It takes the gaps identified in Phases B–D, consolidates them, and groups them into work packages — shaping how the Target Architecture will actually be delivered.
The phase decides the overall approach: make/buy/reuse decisions, whether to deliver in one step or through Transition Architectures (intermediate, deployable states of the architecture), and which opportunities can deliver early business value. The result is the initial, complete version of the Architecture Roadmap and the outline Implementation and Migration Strategy.
Phase E is a collaborative effort: it requires input from business planning, portfolio/project management, and operations — not just architects — because the groupings must be implementable as real projects.
Objectives
- Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D.
- Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value.
- Define the overall Solution Building Blocks approach to complete the Target Architecture.
Steps in this phase
0/11 · 0%Key inputs
- Request for Architecture Work, Statement of Architecture Work, Architecture Vision
- Product information on candidate solutions
- Capability Assessment and Communications Plan
- Planning methodologies of the enterprise
- Organizational Model for Enterprise Architecture and Tailored Architecture Framework
- Governance models and frameworks (architecture and corporate)
- Architecture Repository
- Draft Architecture Definition Document — all four domains (from Phases B–D)
- Draft Architecture Requirements Specification, including consolidated gap analysis results
- Candidate Architecture Roadmap components from Phases B, C, and D
Key outputs
- Refined and updated Architecture Vision phase deliverables where applicable
- Draft Architecture Definition Document — updated, including identification of Transition Architectures (if any)
- Draft Architecture Requirements Specification — updated
- Architecture Roadmap v0.1 — including work packages and Transition Architectures
- Implementation and Migration Plan v0.1 — including the Implementation and Migration Strategy
- Capability Assessment — updated where required
Worked example — Meridian Retail Group
Generated sample documents for a fictional company, showing what this phase consumes and produces. They are illustrative study aids, not templates from the standard.
Example inputs
example inputDeliverablefrom PreliminaryThe document from the sponsoring organization that triggers an ADM cycle — the key handoff from the Preliminary Phase into Phase A.
Request for Architecture Work
Sponsoring organization: Meridian Retail Group — Office of the COO Date: 2 April 2026 Reference: RAW-2026-001 Addressed to: Architecture Board (submitted via the Lead Architect)
Organization sponsors
Chief Operating Officer (business sponsor); Chief Information Officer (executive sponsor for architecture).
Mission statement
Deliver the "One Meridian" unified customer experience: any customer, recognized in any channel, served from a single view of orders, inventory, and preferences.
Business goals and changes
- Increase repeat-purchase rate from 31% to 40% within 24 months
- Enable buy-online-pickup-in-store (BOPIS) in all 240 stores
- Consolidate 4 customer databases into a governed single customer view
- Reduce integration spend by 20%
Strategic plans
Responds to the One Meridian strategy (FY26–FY28) and Board Directive 26-04. Goals map to drivers DRV-01 to DRV-04 in the Driver/Goal/Objective catalog.
Time limits
- Architecture definition (Target Architecture and roadmap) approved before the 1 Nov 2026 peak trading freeze
- First Transition Architecture in production before the FY27 peak freeze
Changes in the business environment
Competitors now offer click-and-collect as standard; digital revenue at 26% and rising; POS v9 reaches end of life in 2027.
Organizational constraints
- Peak trading freeze: no production change 1 Nov – 15 Jan
- Franchise stores operate their own POS until contract renewal (FY27)
Financial constraints
Indicative program envelope of $18M over 2 years, subject to Investment Committee approval per tranche.
External and business constraints
- GDPR and PCI-DSS compliance mandatory
- 3PL logistics contract fixes EDI message formats until 2027
Current business system description
Channel-based operating model: Digital Commerce, Store Operations, and Customer Care each run their own customer processes and service standards.
Current systems description
4 customer databases, 3 order management systems, in-store POS (v9, EOL 2027), monolithic e-commerce platform, nightly-batch warehouse integration.
Developing organization and resources available
Meridian EA team (Lead Architect plus 4 domain architects), working under the Tailored Architecture Framework v1.0 and Architecture Principles v1.0. Business subject-matter experts released for up to 2 days per week during Phases B–D.
Success criteria
An approved Target Architecture and Implementation and Migration Plan for the One Meridian program, with the first Transition Architecture delivered before the FY27 peak trading freeze.
Submitted by: COO, 2 April 2026 · Accepted for Phase A: Architecture Board, 9 April 2026
Example outputs
example outputMatrixThe Phase E working matrix that lines up gaps from all domains with potential solutions and their dependencies.
Consolidated Gaps, Solutions, and Dependencies matrix (extract)
Reference: CGSD-2026-001 · Version: 0.3 · Date: 25 Sep 2026 Owner: Lead Architect · Contributors: Domain Architects, PMO, Group Procurement, Store Operations
Matrix
Numbers in the Dependencies column refer to rows of this matrix.
| # | Architecture domain | Gap | Potential solution | Approach | Candidate WP | Dependencies |
|---|---|---|---|---|---|---|
| 1 | Business / Data / App | No unified customer view | Customer Profile Service (buy CDP + build API layer) | Buy + build | WP-01, WP-04 | 8 (platform), 10 (CIAM), Data Governance survivorship rules |
| 2 | Business / App | No cross-channel order lifecycle | Order Hub (packaged OMS) | Buy | WP-05 | 1, 8; WMS event adapter |
| 3 | App / Tech | Batch integration, 37 jobs | Event streaming + API gateway; decommission BatchSync | Buy (managed) | WP-06 | 8; per-system adapters |
| 4 | Business / Tech | No BOPIS capability | Inventory Service + store process + POS features | Build + process change | WP-02, WP-04b | 2, 3, 9 (store network) |
| 5 | Tech | POS EOL 2027 | Next-gen POS on Store Edge | Buy | WP-07 | 8, 9, 10; franchise contract (FY27) |
| 6 | Data | Erasure handled manually per system (REQ-D-03) | Erasure events from Profile Service to all consumers | Build (in API layer) | WP-04 | 1, 3 (compacted topics) |
| 7 | Tech | No unified observability; cross-system MTTR > 8h | Observability Service | Buy (SaaS) | WP-11 | 8 |
| 8 | Tech | No container/API/event platform | Cloud landing zone + Container, API Gateway, Event Streaming services | Buy (cloud services) | WP-08 | None. Root of the dependency tree. |
| 9 | Tech | No store segmentation; 4G backup in only 90/240 stores | Store network upgrade, POS VLAN and PCI zone | Buy (carrier + refit) | WP-09 | Field-force capacity (40 refits/month) |
| 10 | Tech | No customer identity platform | SaaS CIAM | Buy | WP-10 | 8 |
| 11 | Business | Cross-channel returns take ~9 days | One-step returns process and policy | Process change + reuse | WP-03 | 1 (profile), existing order data |
Interoperability reconciliation (step 5)
- Conflict: the OMS vendor's default is a direct file feed to WMS, but the Phase D constraint allows integration with on-prem WMS only through the Event Streaming Service. Resolved: WMS event adapter (in row 2), recorded as IR-06.
- Unnecessary interoperability removed: CareDesk had requested direct links to LoyaltyOne and WebShop. Both are replaced by one Order Hub API plus profile lookups, so 2 planned interfaces were dropped.
Shared requirements across business functions (step 4)
Store Operations, Customer Care and Digital Commerce all need "find customer plus order history". One shared solution (rows 1 + 2 through the API Gateway) replaces three separate channel requests.
Grouping decision
Solutions 1+10 group into Work Package group "Customer Foundation"; 3+8 into "Platform Foundation"; 2+4 into "Commerce Core"; 5 into "Store Modernization".
Further grouping in v0.3:
- row 6 joins Customer Foundation;
- row 7 joins Platform Foundation;
- row 9 is delivered through the existing Store Estate Refit program and sequenced with Store Modernization;
- row 11 is a quick win (One-step Returns) in TA-1.
These groups become the candidate projects P1–P7 in the Implementation and Migration Plan v0.1.
Study tips & key concepts
- Phase E answers 'how do we deliver this?' at the architecture level; Phase F answers 'in what order, when, and at what cost?' at the plan level.
- Work package classification: mainstream (part of future system), contain (expected to be replaced/modified in the planning horizon), replace (to be replaced in the planning horizon).
- A Transition Architecture is a formally described intermediate state — deployable and valuable in its own right, not just a project milestone.
- Implementation approaches to know: greenfield (start from scratch), revolutionary (big switch-over), evolutionary (phased convergence); combined with quick win / achievable target / value chain delivery methods.
- Phase E is where Solution Building Blocks (SBBs — actual products/solutions) start to be matched against Architecture Building Blocks (ABBs).
- Techniques associated with E/F: Implementation Factor catalog; Consolidated Gaps, Solutions, and Dependencies matrix; Architecture Definition Increments table; Business Value Assessment.