10. Phase F: Migration Planning
This chapter addresses migration planning; that is, how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan.
The objectives of Phase F are to:
- Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan
- Ensure that the Implementation and Migration Plan is co-ordinated with the enterprise's approach to managing and implementing change in the enterprise's overall change portfolio
- Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders
This section defines the inputs to Phase F.
10.2.1 Reference Materials External to the Enterprise
- Architecture reference materials (see the TOGAF Standard — Architecture Content)
10.2.2 Non-Architectural Inputs
- Request for Architecture Work (see the TOGAF Standard — Architecture Content)
- Capability Assessment (see the TOGAF Standard — Architecture Content)
- Communications Plan (see TOGAF Standard — Architecture Content)
10.2.3 Architectural Inputs
- Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
- Scope of organizations impacted
- Maturity assessment, gaps, and resolution approach
- Roles and responsibilities for architecture team(s)
- Constraints on architecture work
- Budget requirements
- Governance and support strategy
- Governance models and frameworks for:
- Corporate Business Planning
- Enterprise Architecture
- Portfolio, Program, Project Management
- System Development/Engineering
- Operations (Service)
- Tailored Architecture Framework (see the TOGAF Standard — Architecture Content), including:
- Tailored architecture method
- Tailored architecture content (deliverables and artifacts)
- Configured and deployed tools
- Statement of Architecture Work (see the TOGAF Standard — Architecture Content)
- Architecture Vision (see the TOGAF Standard — Architecture Content)
- Architecture Repository (see the TOGAF Standard — Architecture Content), including:
- Re-usable building blocks
- Publicly available reference models
- Organization-specific reference models
- Organization standards
- Draft Architecture Definition Document, which may include Baseline and/or Target Architectures of any architecture domain, and/or Transition Architectures
- Draft Architecture Requirements Specification (see the TOGAF Standard — Architecture Content), including:
- Architectural requirements
- Gap analysis results (from Business, Data, Application, and Technology Architecture)
- IT Service Management requirements
- Change Requests for existing business programs and projects (see the TOGAF Standard — Architecture Content)
- Architecture Roadmap, Draft (see the TOGAF Standard — Architecture Content),
- Identification of work packages
- Identification of Transition Architectures
- Implementation Factor catalog
- Capability Assessment (see the TOGAF Standard — Architecture Content),
- Business Capability Assessment
- IT Capability Assessment
- Implementation and Migration Plan, Draft (see the TOGAF Standard — Architecture Content), including the high-level Implementation and Migration Strategy
The level of detail addressed in Phase F will depend on the scope and goals of the overall architecture effort.
The order of the steps in Phase F as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established Architecture Governance.
All activities that have been initiated in these steps must be closed during the "Complete the Architecture Development Cycle and Document Lessons Learned" step (see 10.3.7 Complete the Architecture Development Cycle and Document Lessons Learned).
The steps in Phase F are as follows:
- Confirm management framework interactions for Implementation and Migration Plan (see 10.3.1 Confirm Management Framework Interactions for the Implementation and Migration Plan)
- Assign a business value to each work package (see 10.3.2 Assign a Business Value to Each Work Package)
- Estimate resource requirements, project timings, and availability/delivery vehicle (see 10.3.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle)
- Prioritize the migration projects through the conduct of a cost/benefit assessment and risk validation (see 10.3.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation )
- Confirm Architecture Roadmap and update Architecture Definition Document (see 10.3.5 Confirm Architecture Roadmap and Update Architecture Definition Document)
- Complete the Implementation and Migration Plan (see 10.3.6 Complete the Implementation and Migration Plan)
- Complete the architecture development cycle and document lessons learned (see 10.3.7 Complete the Architecture Development Cycle and Document Lessons Learned)
10.3.1 Confirm Management Framework Interactions for the Implementation and Migration Plan
This step is about co-ordinating the Implementation and Migration Plan with the management frameworks within the organization. There are typically four management frameworks that have to work closely together for the Implementation and Migration Plan to succeed:
- Business Planning that conceives, directs, and provides the resources for all of the activities required to achieve concrete business objectives/outcomes
- Enterprise Architecture that structures and gives context to all enterprise activities delivering concrete business outcomes primarily but not exclusively in the IT domain
- Project/Portfolio Management that co-ordinates, designs, and builds the business systems that deliver the concrete business outcomes
- Operations Management that integrates, operates, and maintains the deliverables that deliver the concrete business outcomes
The Implementation and Migration Plan will impact the outputs of each of these frameworks and consequently has to be reflected in them. In the course of this step, understand the frameworks within the organization and ensure that these plans are co-ordinated and inserted (in a summary format) within the plans of each one of these frameworks.
The outcome of this step may well be that the Implementation and Migration Plan could be part of a different plan produced by another one of the frameworks with Enterprise Architecture participation.
10.3.2 Assign a Business Value to Each Work Package
Establish and assign a business value to each of the work packages. The intent is to first establish what constitutes business value within the organization, how value can be measured, and then apply this to each one of the projects and project increments.
There are several issues to address in this activity:
- Performance Evaluation Criteria are used by portfolio and capability managers to approve and monitor the progress of the architecture transformation
- Return-on-Investment Criteria have to be detailed and signed off by the various executive stakeholders
- Business Value has to be defined as well as techniques, such as the value chain, which are to be used to illustrate the
role in achieving tangible business outcomes
Business value will be used by portfolio and capability managers to allocate resources and, in cases where there are cutbacks, business value in conjunction with return on investment can be used to determine whether an endeavor proceeds, is delayed, or is canceled.
- Critical Success Factors (CSFs) should be established to define success for a project and/or project increment
These will provide managers and implementers with a gauge as to what constitutes a successful implementation.
- Measures of Effectiveness (MOE) are often performance criteria and many corporations include them in the CSFs
Where they are treated discretely, it should be clear as to how these criteria are to be grouped.
- Strategic Fit based upon the overall Enterprise Architecture (all tiers) will be the critical factor for allowing the approval of any new project or initiative and for determining the value of any deliverable
Use the work packages as a basis of identifying projects that will be in the Implementation and Migration Plan. The identified projects will be fully developed in other steps in Phase F. The projects, and project increments, may require adjustment of the Architecture Roadmap and Architecture Definition Document.
Risks should then be assigned to the projects and project increments by aggregating risks identified in the Consolidated Gaps, Solutions, and Dependencies Matrix (from Phase E).
Estimate the business value for each project using the Business Value Assessment Technique (see the TOGAF Standard — ADM Techniques).
10.3.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle
This step determines the required resources and times for each project and their increments and provides the initial cost estimates. The costs should be broken down into capital (to create the capability) and operations and maintenance (to run and sustain the capability). Opportunities should be identified where the costs associated with delivering new and/or better capability can be offset by decommissioning existing systems. Assign required resources to each activity and aggregate them at the project increment and project level.
10.3.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation
Prioritize the projects by ascertaining their business value against the cost of delivering them. The approach is to first determine, as clearly as possible, the net benefit of all of the SBBs delivered by the projects, and then verify that the risks have been effectively mitigated and factored in. Afterwards, the intent is to gain the requisite consensus to create a prioritized list of projects that will provide the basis for resource allocation.
It is important to discover all costs, and to ensure that decision-makers understand the net benefit over time.
Review the risks to ensure that the risks for the project deliverables have been mitigated as much as possible. The project list is then updated with risk-related comments.
Have the stakeholders agree upon a prioritization of the projects. Prioritization criteria will use elements identified in the creation of the draft Architecture Roadmap in Phase E as well as those relating to individual stakeholder agendas. Notice that it is possible for a project to earn a high priority if it provides a critical deliverable on the path to some large benefit, even if the immediate benefit of the project itself is small.
Formally review the risk assessment and revise it as necessary ensuring that there is a full understanding of the residual risk associated with the prioritization and the projected funding line.
10.3.5 Confirm Architecture Roadmap and Update Architecture Definition Document
Update the Architecture Roadmap including any Transition Architectures. Review the work to date to assess what the time-spans between Transition Architecture should be, taking into consideration the increments in business value and capability and other factors, such as risk. Once the capability increments have been finalized, consolidate the deliverables by project. This will result in a revised Architecture Roadmap.
This is needed in order to co-ordinate the development of several concurrent instances of the various architectures. A Transition Architecture State Evolution Table (see the TOGAF Standard — ADM Techniques) can be used to show the proposed state of the domain architectures at various levels of detail.
If the implementation approach has shifted as a result of confirming the implementation increments, update the Architecture Definition Document. This may include assigning project objectives and aligning projects and their deliverables with the Transition Architectures to create an Architecture Definition Increments Table (see the TOGAF Standard — ADM Techniques).
10.3.6 Complete the Implementation and Migration Plan
Generate the completed Implementation and Migration Plan. Much of the detail for the plan has already been gathered and this step brings it all together using accepted planning and management techniques. This should include integrating all of the projects and activities as well as dependencies and impact of change into a project plan. Any Transition Architectures will act as portfolio milestones.
All external dependencies should be captured and included, and the overall availability of resources assessed. Project plans may be included within the Implementation and Migration Plan.
10.3.7 Complete the Architecture Development Cycle and Document Lessons Learned
This step transitions governance from the development of the architecture to the realization of the architecture. If the maturity of the Architecture Capability warrants, an Implementation Governance Model may be produced (see the TOGAF Standard — Architecture Content).
Lessons learned during the development of the architecture should be documented and captured by the appropriate governance process in Phase H as inputs to managing the Architecture Capability.
The detail of the Architecture Roadmap and the Implementation and Migration Plan should be expressed at a similar level of detail to the Architecture Definition Document developed in Phases B, C, and D. Where significant additional detail is required by the next phase the architecture is likely transitioning to a different level. Depending upon the level of the Target Architecture and Implementation and Migration Plan it may be necessary to iterate another ADM cycle at a lower level of detail. See the TOGAF Standard — Applying the ADM for techniques to manage iteration and different levels of detail.
The outputs of Phase F may include, but are not restricted to:
- Implementation and Migration Plan, Approved (see the TOGAF Standard — Architecture
- Implementation and Migration Strategy
- Project and portfolio breakdown of the implementation:
- Allocation of work packages to project and portfolio
- Capabilities delivered by projects
- Relationship to Target Architecture and any Transition Architectures
- Milestones and timing
- Work breakdown structure
- Project charters (optional):
- Related work packages
- Business value
- Risk, issues, assumptions, dependencies
- Resource requirements and costs
- Benefits of migration
- Estimated costs of migration options
- Finalized Architecture Definition Document (see the TOGAF Standard — Architecture
- Finalized Transition Architectures, if any
- Finalized Architecture Requirements Specification (see the TOGAF Standard — Architecture Content)
- Finalized Architecture Roadmap (see the TOGAF Standard — Architecture Content)
- Re-Usable ABBs (see the TOGAF Standard — Architecture Content)
- Requests for Architecture Work (see the TOGAF Standard — Architecture Content) for a new iteration of the ADM cycle (if any)
- Implementation Governance Model (if any) (see the TOGAF Standard — Architecture Content)
- Change Requests for the Architecture Capability arising from lessons learned
The focus of Phase F is the creation of an Implementation and Migration Plan in co-operation with the project and portfolio managers.
Phase E provides an incomplete Architecture Roadmap and Implementation and Migration Plan that address the Statement of Architecture Work. In Phase F this Roadmap and the Implementation and Migration Plan are integrated with the enterprise's other change activity.
Activities include assessing the dependencies, costs, and benefits of the various migration projects within the context of the enterprise's other activity. The Draft Architecture Roadmap, and Draft Implementation and Migration Plan, from Phase E will form the basis of the final Implementation and Migration Plan that will include portfolio and project-level detail.
The architecture development cycle should then be completed and lessons learned documented to enable continuous process improvement.
TOGAF is a registered trademark of The Open Group