Phase E is the first phase which is directly concerned with the structure of how the Target Architecture will be implemented.
Phase E concentrates on how to deliver the architecture. It takes both a corporate business and technical perspective to rationalize the IT activities, and logically group them into project work packages within the IT portfolio and also within any other portfolios that are dependent upon IT. This is a collaborative effort with key enterprise stakeholders from business and IT (those who develop and implement/run the infrastructure) to assess the organization's business transformation readiness, identify opportunities and solutions, and identify all implementation constraints. Focus on business value, flexibility, co-ordination, and compromise will be keys to success.

When this phase is approached from an enterprise strategic change perspective, the identification of opportunities and solutions is done in a top-down fashion based on the architectural work to date, often with phased delivery working towards the Target Architecture.

However, in some circumstances the organizational environment does not allow for a top-down approach. In these circumstances this phase is approached in a tactical opportunistic way. Projects and factors outside the control of the corporate planners are influenced to achieve some of the planning objectives. In between these two extremes is a scenario where this phase is executed in a top-down fashion, but with a more limited timeframe and/or more focused scope.
The inputs into this phase are extensive and the architects and planners have to consolidate, integrate, and analyze the information to determine the best way ahead. Existing building blocks and case studies from the Architecture Repository can be useful when deciding how to move forward.
All of the previous architecture artifacts (especially the gap analysis results) are consolidated and their inter-dependencies closely assessed to derive an initial critical path. The overall intent is to simplify the transformation process by ruthlessly reducing the number of building blocks to be created as well as the administrative overhead associated with portfolio and project management.

Co-existence and interoperability issues (from a business, information, and technology perspective) are examined and clarified to provide precise development and implementation guidance. Implementation risks are identified, consolidated, and pragmatically accepted, transferred, and/or mitigated leaving residual risks that have to be documented and accepted.
A high-level Implementation and Migration Strategy (that will be part of the Implementation and Migration Plan) is created to illustrate the overall implementation approach based upon the outline critical path resulting from the dependencies analysis. At this point the work packages on the path are organized into portfolios, projects, or initiatives given a clear context (business value and fit) by the enterprise architecture. An impact analysis on the enterprise - especially the existing IT infrastructure - is conducted to assess further required activities (e.g., re-training of staff to handle new building blocks).

Finally, the architectures from Phases A to D are used to develop a series of Transition Architectures that show incremental progress from the Baseline Architecture to the Target. In smaller-scale change efforts, it may be possible to move directly from the Baseline to the Target, in which case, the Target Architecture is the only transition stage. When larger-scale change is being considered, several interim stages may be required, each described by a Transition Architecture.

Transition Architectures consist of a set of co-ordinated and well-defined building blocks grouped into work packages that define the scope of delivery vehicles (i.e., portfolios, projects, and initiatives). The Transition Architectures incrementally implement building blocks focusing on the delivery of a continuous flow of business value in support of corporate business objectives.
An advantage of using the phased Transition Architecture approach is that most organizations find that a change of architecture has too much impact on the organization to be undertaken in a single phase. Migration often requires consideration of a number of business and technical issues, not the least of which are those associated with the means of introducing change to operational systems.

The Transition Architecture delivers discrete business value based upon the overall enterprise capabilities that they are attempting to deliver, as well as the architecture dependencies discovered in the previous phase. Transition Architectures integrate and in turn support implementation governance and any follow-on design, or detailed architecture definition.
In many cases, simultaneous work will be conducted on several architectures at different levels of detail. It is perfectly possible for several Transition Architectures to be worked on simultaneously. While one Transition Architecture is being built, another is being designed, and another is being planned.

The success of the transformation is often dependent on factors and projects outside the control of the corporate planners. Enterprise business drivers and constraints provide guidance, constraints, and potential opportunities where existing portfolios, projects, and initiatives are creating associated change. The participation of key stakeholders - preferably those from corporate strategic planning - is highly recommended for the derivation of the potential Transition Architectures and the outline Implementation and Migration Plan.