Phase F: Migration Planning

Chapter 14                             <<< Previous | Next >>>

14.1 Objectives | 14.2 Approach | 14.3 Inputs | 14.4 Steps | 14.5 Outputs

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.

Requirements Management Phase H Phase G Phase F Phase E Phase D Phase C Phase B Phase A Preliminary Phase

Figure 14-1: Phase F: Migration Planning

14.1 Objectives

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 coordinated 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

14.2 Approach

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.

14.3 Inputs

This section defines the inputs to Phase F.

14.3.1 Reference Materials External to the Enterprise

14.3.2 Non-Architectural Inputs

14.3.3 Architectural Inputs

  • Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), 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 Part IV, 36.2.21 Tailored Architecture Framework), including:
    • Tailored architecture method
    • Tailored architecture content (deliverables and artifacts)
    • Configured and deployed tools
  • Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work)
  • Architecture Vision (see Part IV, 36.2.8 Architecture Vision)
  • Architecture Repository (see Part IV, 36.2.5 Architecture Repository), including:
    • Re-usable building blocks
    • Publicly available reference models
    • Organization-specific reference models
    • Organization standards
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Business Architecture, Version 1.0 (detailed)
    • Target Business Architecture, Version 1.0 (detailed)
    • Baseline Data Architecture, Version 1.0 (detailed)
    • Target Data Architecture, Version 1.0 (detailed)
    • Baseline Application Architecture, Version 1.0 (detailed)
    • Target Application Architecture, Version 1.0 (detailed)
    • Baseline Technology Architecture, Version 1.0 (detailed)
    • Target Technology Architecture, Version 1.0 (detailed)
    • Transition Architectures, if any
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), 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 Part IV, 36.2.11 Change Request)
  • Architecture Roadmap, Version 0.1 (see Part IV, 36.2.7 Architecture Roadmap), including:
    • Identification of work packages
    • Identification of Transition Architectures
    • Implementation Factor Assessment and Deduction Matrix
  • Capability Assessment (see Part IV, 36.2.10 Capability Assessment), including:
    • Business Capability Assessment
    • IT Capability Assessment
  • Implementation and Migration Plan, Version 0.1 (see Part IV, 36.2.14 Implementation and Migration Plan) including the high-level Implementation and Migration Strategy

14.4 Steps

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:

14.4.1 Confirm Management Framework Interactions for the Implementation and Migration Plan

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:

  • 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.
  • Portfolio/Project 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 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.

14.4.2 Assign a Business Value to Each Work Package

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:

  • 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 Part III, 28.5 Business Value Assessment Technique).

14.4.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.

14.4.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 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.

14.4.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 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).

14.4.6 Generate 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.

14.4.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 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.

14.5 Outputs

The outputs of Phase F may include, but are not restricted to:

return to top of page

<<< Previous Home Next >>>