Key takeaways
- Roadmap and Implementation and Migration Plan: built in E and F.
- Implementation Governance Model: output of F, used in G and H.
- Architecture Contract: partner/sponsor agreement, two variants.
- Compliance Assessment: periodic reviews and checklists in Phase G.
- Change Request → Phase H; Requirements Impact Assessment in response.
Phases E and F: sequencing the transformation
The Architecture Roadmap lists the work packages that will realize the Target and places them on a timeline, from Baseline to Target, highlighting the business value of each stage. It identifies Transition Architectures, significant intermediate states. Built progressively in E and F, it draws on the roadmap components spotted in B, C, and D.
The Implementation and Migration Plan, developed in E and F, schedules the projects that will implement the Target, grouped into portfolios and programs. Its core element is the Implementation and Migration Strategy: strategic direction and sequencing approach. It may include project charters.
The Implementation Governance Model, an output of Phase F, ensures that a project moving into implementation also moves under suitable governance in Phase G, even when a general framework already exists.
- Roadmap: work package portfolio, Implementation Factor catalog, consolidated gaps matrix, Transition Architectures, recommendations (effectiveness criteria, risks, SBBs)
- Plan: strategy, breakdown into projects and portfolios, milestones, WBS, optional project charters
- Governance: processes, structure, roles, checkpoints and success/failure criteria
Phase G: contracting and checking
The Architecture Contract is an agreement shared by development partners and sponsors, covering what the architecture delivers, its quality, and its fitness-for-purpose. The design and development contract covers architecture work; the business users' contract adds the architecture adopters and a service architecture with an SLA.
The Compliance Assessment results from periodic project reviews: it checks that design and delivery follow strategic and architecture objectives and feeds lessons back. It contains a progress status, a design overview, and completed checklists (hardware and OS, middleware, applications, information, security, systems management, engineering, methods and tools).
Phase H and Requirements Management: absorbing change
A Change Request is submitted when the definition or requirements prove insufficient during implementation, or when market, strategy, or technology open new opportunities. It is considered in Phase H and may start a new cycle, possibly through a new Request for Architecture Work.
The Requirements Impact Assessment evaluates the current requirements and specification when new facts call them into question, and recommends changes. It is often produced in response to a Change Request, with which it shares most items; the Change Request adds the description and rationale of the change.
- Reference to the requirements concerned and stakeholder priority
- Phases to revisit and the phase leading prioritization
- Investigation results and recommendations
- Repository reference number
TERMS TO KNOW
The terms, in context.
- Architecture Roadmap
- Work packages ordered from Baseline to Target, with their value and the Transition Architectures.
- Implementation and Migration Plan
- Schedule of implementation projects, grouped into portfolios and programs.
- Implementation Governance Model
- Processes, structure, roles, and checkpoints governing a project during implementation.
- Architecture Contract
- Joint agreement between development partners and sponsors on deliverables, quality, and fitness.
- Compliance Assessment
- Periodic review of a project against architecture objectives, with completed checklists.