| You are here: | ||
| <<< Previous | Home | Next >>> |
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:
The focus of Phase F is the creation of an Implementation and Migration Plan in co-operation with the portfolio and project managers.
Phase E provides an incomplete Architecture Roadmap and Implementation and Migration Plan that address the Request for 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 Architecture Roadmap, Version 0.1 and Implementation and Migration Plan, Version 0.1 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.
This section defines the inputs to Phase F.
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 (see below) 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 14.4.7 Complete the Architecture Development Cycle and Document Lessons Learned).
The steps in Phase F are as follows:
This step is about coordinating 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:
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 coordinated 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.
Establish and assign business values to all 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.
If Capability-Based Planning has been used, then the business values associated with the capabilities and associated capability increments should be used to assign the business values for deliverables.
There are several issues to address in this activity:
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 Part III, 28.5 Business Value Assessment Technique).
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.
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 creation of the draft Architecture Roadmap in Phase E as well as those relating to individual stakeholders' 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.
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 Part III, 28.4 Transition Architecture State Evolution Table) 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 Part III, 28.3 Architecture Definition Increments Table).
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.
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 Part IV, 36.2.15 Implementation Governance Model).
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 Part III, 19. Applying Iteration to the ADM and 20. Applying the ADM across the Architecture Landscape for techniques to manage iteration and different levels of detail.
The outputs of Phase F may include, but are not restricted to:
The TOGAF document set is designed for use with frames. To navigate around the document:
Downloads of TOGAF®, an Open Group Standard, are available under license from the TOGAF information web site. The license is free to any organization wishing to use the TOGAF standard entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G116.