Migration Planning Techniques

togaf-tm-sm

Chapter 28                             <<< Previous | Next >>>

28.1 Implementation Factor Assessment & Deduction Matrix | 28.2 Consolidated Gaps, Solutions, & Dependencies Matrix | 28.3 Architecture Definition Increments Table | 28.4 Transition Architecture State Evolution Table | 28.5 Business Value Assessment Technique

This chapter contains a number of techniques used to support migration planning in Phases E and F.

28.1 Implementation Factor Assessment & Deduction Matrix

The technique of creating an Implementation Factor Assessment and Deduction matrix can be used to document factors impacting the architecture Implementation and Migration Plan.

The matrix should include a list of the factors to be considered, their descriptions, and the deductions that indicate the actions or constraints that have to be taken into consideration when formulating the plans.

Factors typically include:

  • Risks
  • Issues
  • Assumptions
  • Dependencies
  • Actions
  • Impacts

An example matrix is shown in Figure 28-1.

 

Figure 28-1: Implementation Factor Assessment and Deduction Matrix

28.2 Consolidated Gaps, Solutions, & Dependencies Matrix

The technique of creating a Consolidated Gaps, Solutions, and Dependencies matrix allows the architect to group the gaps identified in the domain architecture gap analysis results and assess potential solutions and dependencies to one or more gaps.

This matrix can be used as a planning tool when creating work packages. The identified dependencies will drive the creation of projects and migration planning in Phases E and F.

An example matrix is shown in Figure 28-2.

 

Figure 28-2: Consolidated Gaps, Solutions, and Dependencies Matrix

28.3 Architecture Definition Increments Table

The technique of creating an Architecture Definition Increments table allows the architect to plan a series of Transition Architectures outlining the status of the enterprise architecture at specified times.

A table should be drawn up, as shown in Figure 28-3, listing the projects and then assigning their incremental deliverables across the Transition Architectures.

 

Figure 28-3: Architecture Definition Increments Table

28.4 Transition Architecture State Evolution Table

The technique of creating the Transition Architecture State Evolution table allows the architect to show the proposed state of the architectures at various levels using the Technical Reference Model (TRM).

A table should be drawn, listing the services from the TRM used in the enterprise, the Transition Architectures, and proposed transformations, as shown in Figure 28-4.

All Solution Building Blocks (SBBs) should be described with respect to their delivery and impact on these services. They should also be marked to show the progression of the enterprise architecture. In the example, where target capability has been reached, this is shown as “new” or “retain”; where capability is transitioned to a new solution, this is marked as “transition”; and where a capability is to be replaced, this is marked as “replace”.

 

Figure 28-4: Transition Architecture State Evolution TableAnother technique (not shown here) is to use color coding in the matrix; for example:

  • Green: Service SBB in place (either new or retained).
  • Yellow: Service being transitioned into a new solution.
  • Red: Service to be replaced.

28.5 Business Value Assessment Technique

A technique to assess business value is to draw up a matrix based on a value index dimension and a risk index dimension. An example is shown in Figure 28-5. The value index should include criteria such as compliance to principles, financial contribution, strategic alignment, and competitive position. The risk index should include criteria such as size and complexity, technology, organizational capacity, and impact of a failure. Each criterion should be assigned an individual weight.

The index and its criteria and weighting should be developed and approved by senior management. It is important to establish the decision-making criteria before the options are known.

 

Figure 28-5: Sample Project Assessment with Respect to Business Value and Riskreturn to top of page