Phase E: Opportunities & Solutions

Chapter 13                             <<< Previous | Next >>>

13.1 Objectives | 13.2 Approach | 13.3 Inputs | 13.4 Steps | 13.5 Outputs

This chapter describes the process of identifying delivery vehicles (projects, programs, or portfolios) that effectively deliver the Target Architecture identified in previous phases.

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

Figure 13-1: Phase E: Opportunities & Solutions

13.1 Objectives

The objectives of Phase E are to:

  • Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D
  • Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value

13.2 Approach

Phase E concentrates on how to deliver the architecture. It takes into account the complete set of gaps between the Target and Baseline Architectures in all architecture domains, and logically groups changes into work packages within the enterprise’s portfolios. This is an effort to build a best-fit roadmap that is based upon the stakeholder requirements, the enterprise’s business transformation readiness, identified opportunities and solutions, and identified implementation constraints. The key is to focus on the final target while realizing incremental business value.

Phase E is the initial step on the creation of the Implementation and Migration Plan which is completed in Phase F. It provides the basis of a well considered Implementation and Migration Plan that is integrated into the enterprise’s portfolio in Phase F.

The following four concepts are key to transitioning from developing to delivering a Target Architecture:

  • Architecture Roadmap
  • Work Packages
  • Transition Architectures
  • Implementation and Migration Plan

The Architecture Roadmap lists individual work packages in a timeline that will realize the Target Architecture.

Each work package identifies a logical group of changes necessary to realize the Target Architecture.

A Transition Architecture describes the enterprise at an architecturally significant state between the Baseline and Target Architectures. Transition Architectures provide interim Target Architectures upon which the organization can converge.

The Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture.

13.3 Inputs

This section defines the inputs to Phase E.

13.3.1 Reference Materials External to the Enterprise

13.3.2 Non-Architectural Inputs

13.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)
  • 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)
  • Candidate Architecture Roadmap components from Phases B, C, and D

13.4 Steps

The level of detail addressed in Phase E will depend on the scope and goals of the overall architecture effort.

The order of the steps in Phase E (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 Create the Architecture Roadmap & Implementation and Migration Plan step (see 13.4.11 Create the Architecture Roadmap & Implementation and Migration Plan).

The steps in Phase E are as follows:

13.4.1 Determine/Confirm Key Corporate Change Attributes

This step determines how the enterprise architecture can be best implemented to take advantage of the organization’s business culture. This should include the creation of an Implementation Factor Assessment and Deduction matrix (see Part III, 28.1 Implementation Factor Assessment & Deduction Matrix) to serve as a repository for architecture implementation and migration decisions. The step also includes assessments of the transition capabilities of the organization units involved (including culture and abilities), and assessments of the enterprise (including culture and skill sets).

The resulting factors from the assessments should be documented in the Implementation Factor Assessment and Deduction matrix. For organizations where enterprise architecture is well established, this step can be simple, but the matrix has to be established so that it can be used as an archive and record of decisions taken.

13.4.2 Determine Business Constraints for Implementation

Identify any business drivers that would constrain the sequence of implementation. This should include a review of the business and strategic plans, at both a corporate and line-of-business level, and a review of the Enterprise Architecture Maturity Assessment.

13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D

Consolidate and integrate the gap analysis results from the Business, Information Systems, and Technology Architectures (created in Phases B to D) and assess their implications with respect to potential solutions and inter-dependencies. This should be done by creating a Consolidated Gaps, Solutions, and Dependencies matrix, as shown in Part III, 28.2 Consolidated Gaps, Solutions, & Dependencies Matrix, which will enable the identification of Solution Building Blocks (SBBs) that could potentially address one or more gaps and their associated Architecture Building Blocks (ABBs).

Review the Phase B, C, and D gap analysis results and consolidate them in a single list. The gaps should be consolidated along with potential solutions to the gaps and dependencies. A recommended technique for determining the dependencies is to use sets of views such as the Business Interaction matrix, the Data Entity/Business Function matrix, and the Application/Function matrix to completely relate elements from different architectural domains.

Rationalize the Consolidated Gaps, Solutions, and Dependencies matrix. Once all of the gaps have been documented, re-organize the gap list and place similar items together. When grouping the gaps, refer to the Implementation Factor Assessment and Deduction matrix and review the implementation factors. Any additional factors should be added to the Implementation Factor Assessment and Deduction matrix.

13.4.4 Review Consolidated Requirements Across Related Business Functions

Assess the requirements, gaps, solutions, and factors to identify a minimal set of requirements whose integration into work packages would lead to a more efficient and effective implementation of the Target Architecture across the business functions that are participating in the architecture. This functional perspective leads to the satisfaction of multiple requirements through the provision of shared solutions and services. The implications of this consolidation of requirements with respect to architectural components can be significant with respect to the provision of resources. For example, several requirements raised by several lines of business can be resolved through the provision of a shared set of Business Services and Information System Services within a work package or project.

13.4.5 Consolidate and Reconcile Interoperability Requirements

Consolidate the interoperability requirements identified in previous phases. The Architecture Vision and Target Architectures, as well as the Implementation Factor Assessment and Deduction matrix and Consolidated Gaps, Solutions, and Dependencies matrix, should be consolidated and reviewed to identify any constraints on interoperability required by the potential set of solutions.

A key outcome is to minimize interoperability conflicts, or to ensure such conflicts are addressed in the architecture. Re-used Solution Building Blocks (SBBs), Commercial Off-The-Shelf (COTS) products, and third-party service providers typically impose interoperability requirements that conflict. Any such conflicts must be addressed in the architecture, and conflicts must be considered across all architecture domains (Business, Applications, Data, and Technology).

There are two basic approaches to interoperability conflicts; either create a building block that transforms or translates between conflicting building blocks, or make a change to the specification of the conflicting building blocks.

13.4.6 Refine and Validate Dependencies

Refine the initial dependencies, ensuring that any constraints on the Implementation and Migration Plans are identified. There are several key dependencies that should be taken into account, such as dependencies on existing implementations of Business Services and Information System Services or changes to them. Dependencies should be used for determining the sequence of implementation and identifying the coordination required. A study of the dependencies should group activities together, creating a basis for projects to be established. Examine the relevant projects and see whether logical increments of deliverables can be identified. The dependencies will also help to identify when the identified increments can be delivered. Once finished, an assessment of these dependencies should be documented as part of the Architecture Roadmap and any necessary Transition Architectures.

Addressing dependencies serves as the basis for most migration planning.

13.4.7 Confirm Readiness and Risk for Business Transformation

Review the findings of the Business Transformation Readiness Assessment previously conducted in Phase A and determine their impact on the Architecture Roadmap and the Implementation and Migration Strategy. It is important to identify, classify, and mitigate risks associated with the transformation effort. Risks should be documented in the Consolidated Gaps, Solutions, and Dependencies matrix.

13.4.8 Formulate Implementation and Migration Strategy

Create an overall Implementation and Migration Strategy that will guide the implementation of the Target Architecture, and structure any Transition Architectures. The first activity is to determine an overall strategic approach to implementing the solutions and/or exploiting opportunities. There are three basic approaches as follows:

  • Greenfield: A completely new implementation.
  • Revolutionary: A radical change (i.e., switch on, switch off).
  • Evolutionary: A strategy of convergence, such as parallel running or a phased approach to introduce new capabilities.

Next, determine an approach for the overall strategic direction that will address and mitigate the risks identified in the Consolidated Gaps, Solutions, and Dependencies matrix. The most common implementation methodologies are:

  • Quick win (snapshots)
  • Achievable targets
  • Value chain method

These approaches and the identified dependencies should become the basis for the creation of the work packages. This activity terminates with agreement on the Implementation and Migration Strategy for the enterprise.

13.4.9 Identify and Group Major Work Packages

Key stakeholders, planners, and the enterprise architects should assess the missing business capabilities identified in the Architecture Vision and Target Architecture.

Using the Consolidated Gaps, Solutions, and Dependencies matrix together with the Implementation Factor Assessment and Deduction matrix, logically group the various activities into work packages.

Fill in the "Solution" column in the Consolidated Gaps, Solutions, and Dependencies matrix to recommend the proposed solution mechanisms. Indicate for every gap/activity whether the solution should be oriented towards a new development, or be based on an existing product, and/or use a solution that can be purchased. An existing system may resolve the requirement with minor enhancements. For new development this is a good time to determine whether the work should be conducted in-house or through a contract.

Classify every current system that is under consideration as:

  • Mainstream: Part of the future information system.
  • Contain: Expected to be replaced or modified in the planning horizon (next three years).
  • Replace: To be replaced in the planning horizon.

Supporting top-level work packages should then in turn be decomposed into increments to deliver the capability increments. Analyze and refine these work packages, or increments with respect to their business transformation issues and the strategic implementation approach. Finally, group the work packages into portfolios and projects within a portfolio, taking into consideration the dependencies and the strategic implementation approach.

13.4.10 Identify Transition Architectures

Where the scope of change to implement the Target Architecture requires an incremental approach, then one or more Transition Architectures may be necessary. These provide an ability to identify clear targets along the roadmap to realizing the Target Architecture. The Transition Architectures should provide measurable business value. The time-span between successive Transition Architectures does not have to be of uniform duration.

Development of Transition Architectures must be based upon the preferred implementation approach, the Consolidated Gaps, Solutions, and Dependencies matrix, the listing of projects and portfolios, as well as the enterprise’s capacity for creating and absorbing change.

Determine where the difficult activities are, and unless there are compelling reasons, implement them after other activities that most easily deliver missing capability.

13.4.11 Create the Architecture Roadmap & Implementation and Migration Plan

Consolidate the work packages and Transition Architectures into the Architecture Roadmap, Version 0.1, which describes a timeline of the progression from the Baseline Architecture to the Target Architecture. The timeline informs the Implementation and Migration Plan. The Architecture Roadmap frames the migration planning in Phase F. Identified Transition Architectures and work packages should have a clear set of outcomes. The Architecture Roadmap must demonstrate how the selection and timeline of Transition Architectures and work packages realizes the Target Architecture.

The detail of the Architecture Roadmap, Version 0.1 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 before implementation the architecture is likely transitioning to a different level. 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 Implementation and Migration Plan must demonstrate the activity necessary to realize the Architecture Roadmap. The Implementation and Migration Plan forms the basis of the migration planning in Phase F. The detail of the Implementation and Migration Plan, Version 0.1 must be aligned to the detail of the Architecture Roadmap and be sufficient to identify the necessary projects and resource requirements to realize the roadmap.

When creating the Implementation and Migration Plan there are many approaches to consider, such as a data-driven sequence, where application systems that create data are implemented first, then applications that process the data. A clear understanding of the dependencies and lifecycle of in-place SBBs is required for an effective Implementation and Migration Plan.

Finally, update the Architecture Vision, Architecture Definition Document, and Architecture Requirements Specification with any additional relevant outcomes from this phase.

13.5 Outputs

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

  • Refined and updated version of the Architecture Vision phase deliverables, where applicable, including:
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Baseline Business Architecture, Version 1.0 updated if necessary
    • Target Business Architecture, Version 1.0 updated if necessary
    • Baseline Data Architecture, Version 1.0 updated if necessary
    • Target Data Architecture, Version 1.0 updated if necessary
    • Baseline Application Architecture, Version 1.0 updated if necessary
    • Target Application Architecture, Version 1.0 updated if necessary
    • Baseline Technology Architecture, Version 1.0 updated if necessary
    • Target Technology Architecture, Version 1.0 updated if necessary
    • Transition Architecture, number and scope as necessary
    • Views corresponding to the selected viewpoints addressing key stakeholder concerns
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including:
    • Consolidated Gaps, Solutions, and Dependencies Assessment
  • Capability Assessments, including:
    • Business Capability Assessment
    • IT Capability Assessment
  • Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap), including:
    • Work package portfolio:
      • Work package description (name, description, objectives)
      • Functional requirements
      • Dependencies
      • Relationship to opportunity
      • Relationship to Architecture Definition Document and Architecture Requirements Specification
      • Relationship to any capability increments
      • Business value
      • Implementation Factor Assessment and Deduction Matrix
      • Impact
    • Identification of Transition Architectures, if any, including:
      • Relationship to Architecture Definition Document
    • Implementation recommendations:
      • Criteria measures of effectiveness
      • Risks and issues
      • Solution Building Blocks (SBBs)
  • Implementation and Migration Plan, Version 0.1, including:
    • Implementation and Migration Strategy

The outputs may include some or all of the following:

  • Diagrams:
    • Project Context diagram
    • Benefits diagram

return to top of page

<<< Previous Home Next >>>