| You are here: | ||
| <<< Previous | Home | Next >>> |
This chapter describes the process of identifying delivery vehicles (projects, programs, or portfolios) that effectively deliver the Target Architecture identified in previous phases.
The objectives of Phase E are to:
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:
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.
This section defines the inputs to Phase E.
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:
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.
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.
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.
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.
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.
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.
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.
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:
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:
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.
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:
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.
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.
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.
The outputs of Phase E may include, but are not restricted to:
The outputs may include some or all of the following:
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.