This chapter is a checkpoint to verify suitability for implementation.

Objectives

The objectives of Phase E are to:

• Evaluate and select among the implementation options identified in the development of the various Target Architectures (for example, build versus buy versus re-use options, and sub-options within those major options)
• Identify the strategic parameters for change, and the top-level work packages or projects to be undertaken in moving from the current environment to the target
• Assess the dependencies, costs, and benefits of the various projects
• Generate an overall implementation and migration strategy and a detailed Implementation Plan

Approach

Phase E identifies the parameters of change, the major phases along the way, and the top-level projects to be undertaken in moving from the current environment to the target. The output of Phase E will form the basis of the Implementation Plan required to move to the Target Architecture. This phase also attempts to identify new business opportunities arising from the architecture work in previous phases.

Sometimes the process of identifying implementation opportunities allows a business to identify new applications, and in this case it may be necessary to iterate between Phase E and previous phases. Iteration must be limited by time or money to avoid wasting effort in the search for a perfect architecture.

Phase E is the first phase which is directly concerned with implementation. The task is to identify the major work packages or projects to be undertaken.

An effective way to do this is to use the gap analysis on the business functions between the old environment and the new, created in Phase D. Any functions appearing as "new" items will have to be implemented (developed or purchased and deployed).

Slightly harder to identify are the projects required to update or replace existing functions which must be done differently in the new environment. One of the options to be considered here is leaving an existing system in place and coexisting with the new environment.

During this final step in the specification of building blocks it must be verified that the organization-specific requirements will be met. Key to this is reason checking against the business scenario driving the scope of the project. It is important to note that the ensuing development process must include recognition of dependencies and boundaries for functions and should take account of what products are available in the marketplace. An example of how this might be expressed can be seen in the building blocks example (Part IV: Resource Base , Building Blocks).

Coexistence appears on the surface to be easy. After all, the original system is left in place, largely unchanged. Unfortunately, it is not always as easy as it looks. The main problems with coexistence are:

• User interfaces: combining user interfaces to the old and new applications in a single unit on the users' desks can be difficult, if not impossible.
• Access to data: often the new applications need to share some data with the old applications, and some kind of data sharing must be established. This can be difficult unless the old and new systems use the same database technology.
• Connectivity: this may involve expenditure on software and gateway equipment. In difficult cases, equipment simply may not be available in a useful timescale. Often this happens because the old system is simply too out-of-date for connectivity solutions to be still on the market.

The most successful strategy for Phase E is to focus on projects that will deliver short-term pay-offs and so create an impetus for proceeding with longer-term projects.

Inputs

Inputs to Phase E are:

• Request for Architecture Work (Request for Architecture Work)
• Statement of Architecture Work (Major Output Descriptions)
• Target Business Architecture (Business Architecture )
• Data Architecture
• Applications Architecture ), Version 1.0
• Target Technology Architecture (Technology Architecture ) ), Version 1.0
• Target Data Architecture, Version 1.0
• Target Applications Architecture, Version 1.0
• Re-usable Architecture Building Blocks (from organization's Enterprise Continuum (see Part III: Enterprise Continuum), if available)
• Product information (Product Information)

Steps

Key steps in Phase E include:

1. Identify the key business drivers constraining the sequence Key Business Drivers Constraining Sequence of implementation (for example, Implementation

   Examples are reduction of costs, consolidation of services, introduction of new customer services, etc.). etc.

2. Review the gap analysis generated in Gap Analysis from Phase D. D
3. Brainstorm technical requirements Technical Requirements from a functional perspective. Functional Perspective
4. Brainstorm co-existence Co-existence and interoperability requirements. Interoperability Requirements
5. Perform architecture assessment Architecture Assessment and gap analysis. Gap Analysis
6. Identify major work packages Major Work Packages or projects, and classify Projects

   Classify these as new development, purchase opportunity, or re-use of existing system.

Outputs

The outputs of Phase E are:

• Implementation and migration strategy
• High-level Implementation Plan
• Impact Analysis (see Impact Analysis) - project list

The TOGAF document set is designed for use with frames. To navigate around the document:

• In the main Contents frame at the top of the page, click the relevant hyperlink (Part I, Part II, etc.) to load the Contents List for that Part of the TOGAF document into the Secondary Index frame in the left margin.
  
  
• Then click in that Contents List to load a page into this main frame.
  
  

Downloads of the TOGAF documentation, are available under license from the TOGAF information web site . The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063 .