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

13.1 Objectives

The objectives of Phase E are:

• To review the target business objectives and capabilities, consolidate the gaps from Phases B to D, and then organize groups of building blocks to address these capabilities
• To review and confirm the enterprise's current parameters for and ability to absorb change
• To derive a series of Transition Architectures that deliver continuous business value (e.g., capability increments) through the exploitation of opportunities to realize the building blocks
• To generate and gain consensus on an outline Implementation and Migration Strategy

13.2 Approach

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.

13.3 Inputs

This section defines the inputs to Phase E.

13.3.1 Reference Materials External to the Enterprise

• Architecture reference materials (see Part IV, 36.2.5 Architecture Repository)
• Product information

13.3.2 Non-Architectural Inputs

• Request for Architecture Work (see Part IV, 36.2.17 Request for Architecture Work)
• Capability Assessment (see Part IV, 36.2.10 Capability Assessment)
• Communications Plan (see Part IV, 36.2.12 Communications Plan)
• Planning methodologies

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:
  • Enterprise Architecture Management Framework
  • Capability Management Framework
  • Portfolio Management Framework
  • Project Management Framework
  • Operations Management Framework
• 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:
  • Gap analysis results (from Business, Data, Application, and Technology Architecture)
  • Architectural requirements
  • IT service management integration requirements
• Change Requests for existing business programs and projects (see Part IV, 36.2.11 Change Request)

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.

The steps in Phase E are as follows:

• 13.4.1 Determine/Confirm Key Corporate Change Attributes
• 13.4.2 Determine Business Constraints for Implementation
• 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D
• 13.4.4 Review IT Requirements from a Functional Perspective
• 13.4.5 Consolidate and Reconcile Interoperability Requirements
• 13.4.6 Refine and Validate Dependencies
• 13.4.7 Confirm Readiness and Risk for Business Transformation
• 13.4.8 Formulate High-Level Implementation and Migration Strategy
• 13.4.9 Identify and Group Major Work Packages
• 13.4.10 Identify Transition Architectures
• 13.4.11 Create Portfolio and Project Charters and Update the Architectures

13.4.1 Determine/Confirm Key Corporate Change Attributes

Determine 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 13.4.1.1 Create an Implementation Factor Assessment and Deduction Matrix) to serve as a repository for architecture implementation and migration decisions. It should also include an assessment of the organizations involved, their culture, and abilities.

For organizations where end-to-end enterprise architecture is well established, this step can be simple, but the matrix has to be established so that it can act as a repository of decisions.

13.4.1.1 Create an Implementation Factor Assessment and Deduction Matrix

The creation of an Implementation Factor Assessment and Deduction matrix ensures that relevant factors are considered and documented. It should become part of the Implementation and Migration Plan and document the rationale for key architecture decisions in this phase. These factors will help to identify solutions and opportunities and simplify the formulation of the Implementation and Migration Plan.

For a description of the Implementation Factor Assessment and Deduction matrix, see Part III, 28.1 Implementation Factor Assessment and Deduction Matrix .

13.4.1.2 Assess Transition Capabilities of Corporate and Partner Organizations

Assess the capability to transition for the corporate organization and any partner organizations that are part of the corporate workflows (e.g., supply chain). The assessment should address at least the following factors:

• The organizational impact on shaping the Transition Architecture, such as how the business units or lines of business co-ordinate their activities; for example, the solution will be different for a company that is decentralized consisting of regional business units controlling all lines of business in their area versus a company that is organized along lines of business globally with strong central control
• The assignment of responsibilities within the organization for the implementation, so that the enterprise architecture becomes entrenched within the organization
• Corporate cultural influences for handling change; for example, a small to medium size organization in a rapidly evolving industrial sector with intense competitive pressures may change at a different rate than a large global company or government where there are more dependencies and the scale of the business transformation is more significant

These factors should be documented in the Implementation Factor Assessment and Deduction matrix.

13.4.1.3 Assess Transition Capabilities of the Enterprise and IT Organization

Conduct an assessment of the enterprise, and specifically the IT organization, to ensure that at least the following factors are addressed:

• The organization and culture of the enterprise and the IT organization; for example, a de-centralized enterprise and/or IT culture organized regionally or along lines of business will be different to deal with than a centralized enterprise and/or IT organization delivering corporate shared services
• The enterprise personnel skill sets; these could be a major limitation to realizing a Target Architecture that needs a major shift in skill sets - this assessment can determine whether training and/or contracted assistance and/or outsourcing may be required in certain areas
• The gap analysis between the Baseline and Target Architectures; it can be useful to compare the Technical Reference Models produced for the Baseline and Target Architecture as a way to systematically assess services

These factors should be documented in the Implementation Factor Assessment and Deduction matrix.

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 corporate and line of business strategic and business plans and a review of the Enterprise Architecture Maturity Assessment.

13.4.2.1 Review Corporate Strategic Plan

Perform a review of the corporate strategic and business plans in order to validate the fundamental business drivers for the enterprise architecture so that the enterprise architecture can explicitly address each one. As these drivers may not be self-evident or even documented (e.g., the company is in merger discussions or in the process of either acquiring or being acquired) it is important to discover them as they could have a major impact on Transition Architectures and the associated Implementation and Migration Plan.

Each of the business drivers should be assessed with respect to implementation issues and documented in the Implementation Factor Assessment and Deduction matrix.

13.4.2.2 Review the Enterprise Architecture Maturity Assessment

Review the enterprise architecture maturity assessment that was conducted in the Preliminary phase and update the Implementation Factor Assessment and Deduction matrix with any actions, activities, initiatives, and projects that have to be undertaken.

13.4.2.3 Review Corporate Line-of-Business Strategic Plans

Perform a review of the line of business strategic and business plans in order to identify any initiatives, portfolios, projects, or activities that could be leveraged to accelerate the move to the Target Architecture.

This assessment will also determine whether there are any initiatives that could create problems for the enterprise architecture implementation. For the latter, the deductions should be in the form of mitigating efforts including changes to the enterprise architecture or to the line-of-business plan, or both.

Document all of the factors and deduced actions in the Implementation Factor Assessment and Deduction matrix.

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/opportunities and inter-dependencies.

13.4.3.1 Create a Consolidated Gaps, Solutions, and Dependencies Matrix

Create a Consolidated Gaps, Solutions, and Dependencies matrix, as described in Part III, 28.2 Consolidated Gaps, Solutions, and Dependencies Matrix . This enables identification of SBBs which could potentially address one or more gaps and their associated ABBs.

In the course of the activity, any additional "factors" should be added to the Implementation Factor Assessment and Deduction matrix.

13.4.3.2 Review the Phase B, C, and D Gap Analysis Results

The gap analysis results from each one of the architecture phases should be reviewed and consolidated in one long list that will become the basis for the work breakdown structure.

The gaps should be consolidated along with potential solutions to the gaps and dependencies. A recommended technique for determining the dependencies is to create a CRUD (Create, Read, Update, and Delete) to relate business functions to information.

In the course of the activity, any additional "factors" should be added to the Implementation Factor Assessment and Deduction matrix.

13.4.3.3 Rationalize the Consolidated Gaps, Solutions, and Dependencies Matrix

Once all of the gaps have been documented, re-organize the gap list and place like items together. When grouping the gaps, refer to the factor assessment table and review the implementation factors. This will lead into the next step when examining functional requirements.

In the course of the activity, any additional "factors" should be added to the Implementation Factor Assessment and Deduction matrix.

13.4.4 Review IT Requirements from a Functional Perspective

Assess the IT requirements, gaps, solutions, and factors to identify a minimal set of functional requirements whose integration into work packages would lead to a more efficient and effective implementation of the Target 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 are resolved through the provision of a shared set of IT services within a work package/project. In many organizations the funding of these services by multiple lines of business is an issue that has to be addressed at the CxO level.

13.4.4.1 Assess the IT Requirements from a Functional Perspective

Review all of the information acquired so far to determine whether the solutions to the "gaps" can be functionally consolidated. The requirements so far collected should also be assessed in conjunction with the Target Architecture, the Consolidated Gaps, Solutions, and Dependencies matrix, and the Implementation Factor Assessment and Deduction matrix for verification and review.

This activity consolidates the requirements functionally and groups them together to act as the basis for work packages. A major benefit will be the reduction to an absolute minimum of projects that have to be managed, administered, and co-ordinated.

Once this is completed, then refine the Consolidated Gaps, Solutions, and Dependencies matrix, listing the new "gaps" that will form the basis for work packages.

13.4.4.2 Determine Issues Associated with Functional Integration

Often, requirements can be derived and funded in a siloed manner aligned with corporate business processes, leading to the same functionality being required (and possibly delivered) in many different places.

The Target Architecture offers an integrated solution with little or no redundancy, but the integration of requirements, and the associated funding often by lines of business, may be problematic. A useful heuristic is that it costs about twice as much to build a generic re-usable component or service versus a single-purpose component. An individual line of business may not wish to absorb the cost of building a shared service. An assessment of this issue may lead to a modification of the enterprise architecture to be less efficient, but still ensure that line of business funding is maintained.

These issues and outcomes should be documented in the Implementation Factor Assessment and Deduction matrix and, as required, included in the Consolidated Gaps, Solutions, and Dependencies matrix.

13.4.5 Consolidate and Reconcile Interoperability Requirements

Consolidate interoperability requirements identified in previous phases. Reconcile the consolidated requirements with potential solutions.

13.4.5.1 Consolidate Interoperability Requirements

During Phase A (Architecture Vision), the corporate operating model and interoperability levels should have been clearly defined and the latter refined in Phases B though D following the guidance described in Part III, 29. Interoperability Requirements .

The Architecture Vision and Target Architectures, as well as the Implementation Factor Assessment and Deduction matrix and Consolidated Gaps, Solutions, and Dependencies matrix, should now be consolidated and reviewed to look for any constraints on interoperability required by the potential set of solutions.

13.4.5.2 Reconcile Interoperability Requirements with Potential Solutions

The enterprise architect will have to ensure that there are no interoperability conflicts, especially if there is an intention to re-use existing SBBs and/or Commercial Off-The-Shelf (COTS) products, or third-party service providers.

The most significant issue to be addressed is business interoperability. Most SBBs, COTS, or third-party service providers will have their own business processes. Changes to embedded business processes will often require so much work that the advantages of re-using solutions will be lost. An alternative approach is to review business processes embedded within the Target Architecture and see whether they can be aligned with the SBB, COTS, or third-party service provider processes, and supporting Information Systems and Technology Architecture. The enterprise architect will have to ensure that any change to the Target Architecture or the SBB, COTS, or third-party service provider is signed off by the business architects and architecture sponsors in a revised Statement of Architecture Work.

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, described below, that have to be taken discretely into account, namely:

• Business dependencies
• Information dependencies
• Workflow dependencies
• IT dependencies
• Foundation dependencies

In assessing the dependencies, examine the projects and see whether logical increments of deliverables can be identified. The dependencies will also help to identify when the identified increment can be delivered.

Once finished, these dependencies should be grouped into a Dependency Analysis Report that becomes a governance artifact as part of the Transition Architecture, and serves as the basis for migration planning.

13.4.6.1 Assess Business Dependencies

Business dependencies are matters outside of the IT domain that impact the successful delivery of the IT service. These dependencies, when taken into a business capability-based planning perspective (see Part III, 32. Capability-Based Planning), could include matters such as:

• Professional development and training to implement, operate, and sustain the IT capability in both a business and technical context
• Infrastructure that is to provide the physical building to house the new business capability enhanced by IT (e.g., corporate data fusion center)
• Processes that enable the business use of the IT capability through the establishment of workflows, processes, and governance arrangements to ensure that the IT resources can be appropriately leveraged
• Policies, including government legislation, that guide the development of and use of the IT resources

13.4.6.2 Assess Information Dependencies

Information dependencies have to be assessed to ensure that IT resources and systems that create the data precede those that use the data. This can be achieved through the development of an information sequence for the projects, as described in the Phase C (Data Architecture).

It is recommended that the CRUD (Create, Read, Update, and Delete) matrix created in 13.4.3 Review and Consolidate Gap Analysis Results from Phases B to D be used to help sequence the projects such that projects that create information precede projects that read or update that information. Laying out the projects in that manner will be a valuable guide for the transformation planners.

13.4.6.3 Assess Workflow Dependencies

Business workflow dependencies include those that ensure that work processes are supported in a logical manner so that the workflows can be implemented in an incremental manner and as expeditiously as possible. This is closely linked to the information dependencies, but is more subtle as it relies on the support of workflow steps in a logical business-driven manner.

This could be sequential (e.g., Steps 1, 2, 3, and so on) or business-driven (e.g., Step 1, 5, 4, 6, and so on) depending upon the requirements. Sequential is straightforward to deal with, but the business-driven steps require a solid understanding of what the real business needs are.

Capability-based planning (refer to Part III, 32. Capability-Based Planning), for example, would see business sponsors and architects co-ordinating a series of projects and project increments to deliver business value on a continual basis. The fully implemented ideal workflow could well be preceded by an abbreviated one focusing on the critical and/or high return on investment processes.

13.4.6.4 Assess IT Dependencies

IT dependencies include those endeavors outside of the IT portfolio whereby IT resources/systems are critical to the achievement of their business capabilities. These could be triggered by business policy decisions. For example, the Business Re-engineering Group has deemed that a decrease in the corporate workforce could be compensated for through the introduction of new business processes enabled by IT. In this case, the delivery of certain key IT resources may be predicated by the wave of retirements in certain areas.

Some of the areas containing these dependencies are referred to in Part III, 32. Capability-Based Planning , specifically the capability dimensions.

13.4.6.5 Assess Foundation Dependencies and Interim Capabilities

Foundation dependencies include the assessment of the required resources, determining the optimal implementation path within the constraints of the enterprise's capacity for creating and absorbing change.

This "molding" to enable the continuous provision of business capabilities may necessitate the creation of interim or partial SBBs. For example, the creation of a partial information environment with information provider applications may be necessary for the first applications creating the information.

Avoid an "all or nothing" approach. For example, the management of client information does not require the presence of an entire information environment or a complete corporate data model. A minimal subset that will enable the initial applications to show business values will suffice and ensure that the funding envelope will be sustained for the fuller implementation of the Target Architecture.

Often, enterprise architecture involves top-down design and bottom-up implementation; however, the need to deliver business value in the short term will most likely necessitate implementation compromises and creates planned rework. The foundation dependencies will highlight the impact of decisions made and the extent of the rework that should be factored into the final resource bill.

13.4.6.6 Rationalize and Consolidate Dependencies

Dependency rationalization and consolidation includes the integration of the dependencies, many of which will have been repeated in the different areas. These dependencies should be included in a Dependency Analysis Report that will be part of the documentation of the Implementation and Migration Plan and will become a governance artifact.

13.4.7 Confirm Readiness and Risk for Business Transformation

Assess the readiness of the organization to undergo the business transformation changes necessary to leverage the enterprise architecture. Assess the ability of the organization to adapt to change and capture the associated risks. The actual Business Transformation Readiness Assessment or equivalent will have been conducted in Phase A as part of the Architecture Vision and the accompanying roadmap.

At this point, the architects should review the findings and determine the impact of the findings on the Transition Architecture.

There will always be risks associated with any transformation effort and it is important to identify, classify, and mitigate them before starting so that they can be tracked throughout any specific transformation effort. See Part III, 30. Business Transformation Readiness Assessment for a detailed description of the conduct of a Business Transformation Readiness Assessment, and 31. Risk Management for a Risk Management Framework.

In enterprise architecture, the shortest distance between two points (the Baseline and Target Architectures) may not be a straight line, but rather a more indirect path that the organization can realistically negotiate. The determination of this path will be key in identifying what the Transition Architectures will be.

The outcome will help the enterprise architect to determine implementation approaches that will be culturally as well as technically feasible for both tactical and strategic success.

13.4.8 Formulate High-Level Implementation and Migration Strategy

Create an overall solutions strategy that will guide the Target Architecture implementation and structure the Transition Architectures.

The first activity is to determine an overall strategic approach to implementing the solutions and/or exploiting opportunities. The move to a new architecture paradigm (e.g., SOA) will require a different strategy to the upgrade of existing IT infrastructure. Formulation of an appropriate strategic approach will rely on the analysis of the previously identified risks.

Next, determine an approach to implement the overall strategic direction just selected, that will address and mitigate the risks identified in the Consolidated Gaps, Solutions, and Dependencies matrix.

In all cases, there is a need for high-level business and technical consensus as the implications of the approach could be significant. For example, a strategic investment could be highly profitable in the long term, but have a significant negative impact on stock price in the short term unless properly communicated.

13.4.8.1 Determine Overall Strategic Implementation Direction

Once the enterprise's capacity to create and absorb change is understood, it is important to determine what strategic approach will be taken to implement the Target Architecture. This critical step is often overlooked and the Target Architecture is decomposed into a series of projects that proceed independently with unfortunate results. Stakeholders need to know how the strategic goals are to be achieved.

Essentially there are three basic approaches as follows:

• Greenfield: start from the beginning
• Revolutionary: radical change (switch on, switch off); need for major surge resourcing (double/shadow system)
• Evolutionary: includes strategy of convergence; a phased approach is needed to introduce most capabilities

The greenfield and revolutionary approaches may be the most profitable strategically, but the intermediate costs must be taken into account, with the potential necessity to sustain two parallel environments. The costs are more than fiscal, but also include the impact of business transformation and a de facto reduction in management flexibility during the transition period. If either of these two approaches is adopted, then the impact on the Transition Architectures could be significant and, potentially, the Transition Architecture period could be significantly extended with in-service use being scheduled at a future point in time.

By far, the most common approach is the evolutionary one with ever-increasing levels of capability being introduced into the enterprise supported by a strategy of convergence to gradually integrate the existing corporate IT infrastructure.

It is recommended to collaborate with enterprise stakeholders to select a transformation approach and then to ensure that the resources will be provided to support its implementation.

13.4.8.2 Determine an Implementation Approach

The implementation approach addresses how the strategic implementation direction is to be executed to provide direction to both architects and portfolio/project managers alike.

The most common implementation methodology recommendations include:

• Quick win (snapshots)
• Achievable targets
• Value chain method (e.g., NASCIO methodology)

These approaches and the identified dependencies should become the rationale basis for the creation of the Transition Architectures.

This activity terminates with agreement on the Implementation and Migration Strategy for the enterprise.

13.4.9 Identify and Group Major Work Packages

Logically group the architectural activities into a coherent set of portfolios and projects, respecting the strategic implementation direction and approach.

Using the Consolidated Gaps, Solutions, and Dependencies matrix and Implementation Factor Assessment and Deduction matrix, logically group the various activities into work packages (where a work package is an inter-dependent set of activities and deliverables that deliver a discrete enterprise outcome). Although the outcome will be at the enterprise level, the work packages may not necessarily have a direct business outcome but might deliver a foundation artifact that will support other work packages that do. The architecture is a way to communicate the value of all work.

Then, analyze and refine these activities with respect to their business transformation issues and the agreed to strategic implementation approach.

Finally, group the work packages into portfolios and then projects within the portfolios taking into consideration the dependencies and the strategic implementation approach.

13.4.9.1 Identify Major Work Packages

Examine the Implementation Factor Assessment and Deduction matrix and Consolidated Gaps, Solutions, and Dependencies matrix. Add a column to the latter that recommends the proposed solution mechanism.

The best way to conduct this is to hold a working session with the domain architects and operations management personnel to determine what potentially the best solutions would be.

Indicate for every gap/activity whether the solution should be oriented towards:

• New development
• Based upon a existing product and/or solution that can be purchased

An existing system may resolve the requirement with minor enhancements.

For new development, this is a good point to determine whether the work is to be conducted in-house or through a contract, possibly requiring the involvement of procurement experts. Especially in government, significant lead times should be allowed, to perform the Request for Proposals/Quotes (RFP/RFQ) processes involved in awarding a contract.

Finally, group like solutions together as potential work packages.

By the end of this activity, there should be a re-grouped Consolidated Gaps, Solutions, and Dependencies matrix with an additional column addressing proposed solutions.

It might be useful to classify every current system as:

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

13.4.9.2 Analyze the Work Packages with Respect to Business Transformation

The enterprise architect should assess the business transformation-related activities and group them together as potential projects.

For example, as a result of the business transformation, a new line of business may be formed, so it may well be logical for activities pertaining to this new organization to be grouped together so that they can take ownership of the activities and mold them to their needs. In many organizations details are sometimes protected and the enterprise architecture team has to be sufficiently trusted to be perceived as key players and facilitators in the business transformation process.

The work packages should be re-grouped with respect to dependencies (including workflow) and this final analysis used as the basis for project identification. 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, retro-fitted to be able to co-exist with the new environment.

Once the projects are identified, then their project charter and scope statements should be clearly written and initial (i.e., order of magnitude) resource estimates completed. The benefits can also now be framed in the context in an enterprise-wide context using the enterprise architecture. High return on investment projects should be identified as potential pathfinders to show early success.

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 checking against the original business scenario(s) driving the scope of the projects. 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 (see Part IV, 37. Building Blocks).

13.4.10 Identify Transition Architectures

Where the scope of change required to realize the Target Architecture requires an incremental approach, then the enterprise architects will need to develop a series of Transition Architectures as necessary.

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. At this point, business capabilities and the supporting projects and portfolios will be broken down into realizable increments.

Transition Architectures provide an ability to continuously deliver business value. This must be measurable and either direct or indirect (i.e., supporting, foundational) business value. Transition Architectures do not have to be of uniform duration, but the timing of the Transition Architectures should not be considered at this point as it will be dealt with in the Migration Plan.

Finally, group the projects and portfolios into Transition Architectures.

13.4.10.1 Identify Transition Architecture and Capability Increments

Key stakeholders, planners, and the enterprise architect(s) will re-assess the missing business capabilities identified in the Architecture Vision and Target Architecture. They will decompose these targeted capabilities into capability increments each having clearly identified and measurable business value. The supporting top-level projects are in their turn decomposed into increments to deliver the capability increments.

It is useful to determine where the "hard" activities are. Unless there are compelling reasons, do not attack the hardest activities first. Rather, focus on activities that most easily deliver missing capability. Through the development of missing capability and any associated improvement to create and absorb change, perform hard activities, and manage associated risks, the enterprise's capacity will increase.

Most of the challenges in creating and absorbing change are challenges based upon an enterprise's maturity and are expressed in organization and cultural barriers to change.

If there is a business transformation organization within the enterprise, its staff should be involved in definition of capability increments, as they will often have to synchronize several enterprise portfolios delivering their part of the overall transformed set of capabilities. At this point, it may be desirable to assign capability managers whose job it will be to align all of the projects delivering their part of the capability increment.

This co-operation between the architects and business transformation office will help ensure co-ordination and at the same time facilitate the future approval (and release of resources) for the Implementation and Migration Plan.

The collaborative creation of capability increments should identify what activities and outcomes can be grouped together and roughly in what sequence they should be delivered.

13.4.10.2 Group Portfolios and Projects into Increments

This activity takes the sequence of activities and outcomes and groups the delivery vehicles (the portfolios and projects) into increments, specifying what should be delivered in each increment.

The projects should be broken down into increments based upon the deliverables required in each one of the Transition Architectures.

13.4.11 Create Portfolio and Project Charters and Update the Architectures

The approach is to complete the portfolio and major project charters with their deliverables being grouped into increments and scheduled for release within Transition Architecture increments. These architectures provide the enterprise context allowing projects to start their system development methodology initiation, planning, and requirements assessment phases.

Subsequently, the Architecture Vision, Architecture Definition Document, and Architecture Requirements Specification are updated with any additional relevant outcomes from this phase.

13.4.11.1 Create the Portfolio Charters

Review and consolidate the portfolio and potentially major project charters and ensure that their architectural outcomes are clearly defined. These architectural outcomes will give the portfolios enterprise context and determine the "fit" and "value" of the deliverables for governance.

13.4.11.2 Create the Project Charters

Review and consolidate the project charters and ensure that their architectural outcomes are clearly defined. These architectural outcomes will give the projects enterprise context and determine the "fit" and "value" of the deliverables for governance. These project charters will enable the projects to start with their system development method in particular initiation, planning, and requirements gathering.

13.4.11.3 Create the Transition Architectures

Create Transition Architectures that will form the basis for Migration Planning in Phase F. These Transition Architectures should have a clear set of outcomes and a specification of which delivery vehicle (portfolios/projects) will deliver them.

Generally speaking, each Transition Architecture will 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, the architect may elect to re-visit Phases B, C, and D for further elaboration. Alternatively, the architecture definition work could be deferred to a future work effort.

13.4.11.4 Conduct Overall Architecture Updates

Update the Architecture Vision with interoperability policy decisions and any other information that will remain relatively stable for the strategic duration and is largely technology-independent. The Architecture Vision also identifies all of the business capabilities that are to be implemented, and the subset of these capabilities that are to be implemented in the initial Architecture Definition Document.

The narrower scope of the Architecture Definition Document has to have a definitive list of targeted capabilities grouped into Transition Architectures that deliver capability increments through specific projects. The scope of each project is included within their charters that are outlined in the Architecture Definition Document.

13.5 Outputs

The outputs of Phase E are:

• Refined and updated versions of the Architecture Vision, Business Architecture, Information Systems Architecture, and Technology Architecture phase deliverables, where applicable:
  • Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work)
  • Architecture Vision (see Part IV, 36.2.8 Architecture Vision), including definition of types and degrees of interoperability
  • Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
    • Identification of increments
    • Interoperability and co-existence requirements
    • Inclusion of project list and project charters
  • Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification)
• Consolidated and validated Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)
• Capability Assessment (see Part IV, 36.2.10 Capability Assessment), including:
  • Enterprise Architecture Maturity Profile
  • Transformation Readiness Report
• Transition Architecture, Version 1.0 (see Part IV, 36.2.22 Transition Architecture), including:
  • Consolidated Gaps, Solutions, and Dependencies Assessment
  • Risk Register, Version 1.0
  • Impact analysis - project list
  • Dependency Analysis Report
  • Implementation Factor Assessment and Deduction Matrix
• Implementation and Migration Plan, Version 0.1 (see Part IV, 36.2.14 Implementation and Migration Plan) including the high-level Implementation and Migration Strategy

return to top of page