This chapter addresses the formulation of an Implementation and Migration Plan that realizes some or all of the Transition Architectures identified in Phase E.

14.1 Objectives

The objectives of Phase F are to finalize a detailed Implementation and Migration Plan; specifically:

• To ensure that the Implementation and Migration Plan is co-ordinated with the various management frameworks in use within the enterprise
• To prioritize all work packages, projects, and building blocks by assigning business value to each and conducting a cost/business analysis
• To finalize the Architecture Vision and Architecture Definition Documents, in line with the agreed implementation approach
• To confirm the Transition Architectures defined in Phase E with relevant stakeholders
• To create, evolve, and monitor the detailed Implementation and Migration Plan providing necessary resources to enable the realization of the Transition Architectures, as defined in Phase E

14.2 Approach

The main focus of Phase F is the creation of a viable Implementation and Migration Plan in co-operation with the portfolio and project managers.

Phase F activities include assessing the dependencies, costs, and benefits of the various migration projects. The prioritized list of projects will form the basis of the detailed Implementation and Migration Plan that will supplement the architectures with portfolio and project-level detail assigning tasks to specific resources.

The Implementation and Migration Plan is part of a family of plans issued by enterprise management frameworks that have to be closely co-ordinated to ensure that business value is delivered and that the resources are made available to complete the necessary work. This phase ensures that all concerned agencies outside of the enterprise architecture world are aware of the scope and import of the Implementation and Migration Plan and its implications with respect to their activities.

Finally, the architecture evolution cycle should be established to ensure that the architecture stays relevant, and lessons learned should be documented to enable continuous process improvement.

14.3 Inputs

This section defines the inputs to Phase F.

14.3.1 Reference Materials External to the Enterprise

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

14.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)

14.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:
  • Strategic Migration Plan
  • 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)
  • Impact analysis - project list and charters
• 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 integration requirements
• Change Requests for existing business programs and projects (see Part IV, 36.2.11 Change Request)
• 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

14.4 Steps

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

The order of the steps in Phase F (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 F are as follows:

• 14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan
• 14.4.2 Assign a Business Value to Each Project
• 14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles
• Prioritize the migration projects through the conduct of a cost/benefit assessment and risk validation (see 14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation
• Confirm Transition Architecture increments/phases and update Architecture Definition Document (see 14.4.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document
• 14.4.6 Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan
• 14.4.7 Establish the Architecture Evolution Cycle and Document Lessons Learned

14.4.1 Confirm Management Framework Interactions for Implementation and Migration Plan

Establish what the Implementation and Migration Plan should include and ensure that it is co-ordinated with the other frameworks. There are four management frameworks that have to work closely together for the Migration Plan to succeed, namely:

• Business Planning that conceives, directs, and provides the resources for all of the activities required to achieve concrete business objectives/outcomes.
• Enterprise Architecture that structures and gives context to all enterprise activities delivering concrete business outcomes primarily but not exclusively in the IT domain; currently IT governance addresses many of these requirements.
• Portfolio/Project Management that co-ordinates, designs, and builds the business systems that deliver the concrete business outcomes.
• Operations Management that integrates, operates, and maintains the deliverables that deliver the concrete business outcomes.

If some of these areas are not managed, then the enterprise architect/CIO should at least create an ad hoc management framework capability with a plan to mature and formalize it over time.

The Implementation and Migration Plan will impact and consequently have to be reflected in each one of these frameworks. In the course of this step, understand the frameworks within the organization and ensure that these plans are co-ordinated and inserted (in a summary format) within the plans of each one of these frameworks.

The outcome of this step may well be that the Implementation and Migration Plan will not be discrete but part of a different plan produced by another one of the frameworks with enterprise architecture participation.

14.4.1.1 Align Implementation and Migration Plan with Business/Capability Planning

The Implementation and Migration Plan has to be aligned with the business strategy and plans for all aspects of the organization. The enterprise architect, with the Transition Architectures, will be able to view the strategic and in particular business plans from an architecture perspective to determine fitness-for-purpose. The assessment of business dependencies in Phase E will have ensured that there is a business fit.

The enterprise architect has to determine what can be leveraged from the strategic and business plans and conversely what has to be inserted as an addition to these plans in the upcoming release cycle. There will also be items that have to be repeated, or preferably referred to, in the Implementation and Migration Plan so that the corporate plan is synchronized. The key alignment target is the delivery of measurable, incremental business value at the end of each Transition Architecture.

14.4.1.2 Examine Business Transformation Aspects

Strategic business planning should address business transformation, as in virtually all cases of enterprise architecture implementation there is a significant business transformation element.

There are two main components, namely business transformation within and without the IT lines of service. The former is critical for the successful implementation of the IT resources and the strategic (vice-tactical/operational) planners should be made aware of and action this.

Changes within the IT operational infrastructure impact the Implementation and Migration Plan. Enterprise architecture enables a CIO/CTO to redirect the energies of his staff from maintaining a highly complex and less co-ordinated infrastructure to one where the staff can spend more time on contributing directly to business value. Where change results in downsizing an organization, a migration plan should include activities to reposition staff within the business and/or external placement.

Human capital is paramount in a knowledge-based economy and their acceptance of the changes cannot be taken for granted (in many case studies they have actually disabled or sabotaged the architectural innovations). New processes, union consultations, retraining, and appropriate severance are critical to the success of the enterprise architecture.

14.4.1.3 Assess the Synchronization of the Enterprise Architecture and Existing IT Planning Framework

The Implementation and Migration Plan is often a large subset of the corporate IT strategic and business plans. Their synchronization is essential and the need for them to proceed in alignment will be a major change in working approach for planners used to working without an enterprise architecture framework.

Enterprise architecture will provide the enterprise architecture planners with a context for their activities and provide the essential governance "fit" criteria. It will also allow for a systematic impact assessment of changes.

Ensure that the Implementation and Migration Plan is well-positioned within the IT business plan, in whatever level of detail required to ensure that resources will be provided to enable the execution of the plans. This may require a new business process to couple the planning and architecture functions.

14.4.1.4 Align Implementation and Migration Plan with the Project Management Framework

Every organization has a delivery methodology and most have some form of portfolio and project management framework at differing levels of maturity.

The Architecture Definition Document provides a Baseline Architecture, Target Architecture, gap analysis, and dependencies between building blocks. The Implementation and Migration Plan adds further detail on how the Target Architecture is to be realized through change activity.

The Implementation and Migration Plan may be part of the IT business plan (which may act as a high-level IT portfolio plan) or part of the plans managed by an IT portfolio management office. Regardless, the relationship between enterprise architecture and IT planning is symbiotic and must be leveraged.

The Implementation and Migration Plan has to be embedded within the appropriate and, more importantly, funded delivery vehicle. An important aspect to recall is that projects are transient delivery vehicles, whereas the enterprise architecture is permanent and manages the enterprise architecture artifacts delivered by the projects throughout their lifecycle.

Knowledge of the appropriate project delivery methodology (e.g., PRINCE2, PMBOK) should be used to frame the Implementation and Migration Plan. The enterprise architect and CIO will have to assess the best way for ensuring that the Implementation and Migration Plan is created and executed.

14.4.1.5 Align Implementation and Migration Plan with the Operations Management Framework

The linkage between implementation of the architecture and operations management has several dimensions that have to be directly addressed in the Implementation and Migration Plan.

The Operations Management function (if it exists) will have been closely involved in the establishment of the Baseline Architecture and have been solicited for recommendations for the Target Architectures.

The Operations Management function will be the recipient of the architecture artifacts which are the project deliverables (as indicated in the Implementation and Migration Plan and detailed by the systems development method) and it will take the ultimate decision as to whether they are to be implemented and when. This function runs the corporate infrastructure and the minute that an artifact is handed to them it comes under their configuration management and control, not the projects' nor the architects'.

The Implementation and Migration Plan has to cater for the hand-off to the operations management group and arrange for the co-ordination of the artifact configuration management. Operations management constantly execute "maintenance fixes" to the existing infrastructure. These could have significant architectural implications and complicate the integration of project deliverables unless properly co-ordinated. These "bottom-up" changes to the portfolios and architecture are very important as these Change Requests highlight either more efficient ways of implementing and/or deficiencies. Changes to the Solution Building Blocks (SBBs) are not a major issue as long as the interfaces and business rules are respected, and the SBB is made available across the organization. However, changes to the Architecture Building Blocks (ABBs) and interfaces will require architecture co-operation.

The intent should be to co-ordinate the service management functions and ideally create a combined configuration management database to hold the artifacts. Other services, such as release and change management, should be catered for in the Implementation and Migration Plan especially when lead times and processes have to be respected. Conversely, the Implementation and Migration Plan will give the operations management staff advanced consolidated insight into upcoming changes and allow for them to prepare as well as focus the expenditure of their limited funding. Conceptually the introduction of new building blocks should be treated as a Request for Change (RFC) and managed accordingly. Recommended processes will be discussed in some detail in Phase H (Architecture Change Management).

14.4.1.6 Establish Plans for Enterprise Architecture Management

The Implementation and Migration Plan sits at the intersection of numerous technical and management frameworks; indeed it may be part of an overall plan within another framework and be generated by the enterprise architecture team. The intent is to get the Implementation and Migration Plan executed and the actual vehicle used to present and resource it is actually moot.

The enterprise architecture framework (established in the Preliminary phase) should reflect the interactions, but may have to be modified to explicitly state how the architecture is to be implemented and migrated. Ensuring that the Implementation and Migration Plan (however presented) is followed is detailed in Phase G (Architecture Governance).

At this point, a Tailored Architecture Framework should be completed and a vehicle for the Implementation and Migration Plan established.

14.4.2 Assign a Business Value to Each Project

Establish and assign business values to all of the projects and project increments. The intent is to first establish what constitutes business value within the organization, how it can be measured, and then apply it to each one of the projects and project increments.

14.4.2.1 Confirm Organizational Business Value, Return on Investment, and Performance Measurement Parameters

This activity will ensure that the business value parameters are well-understood and serve as the basis for the creation and monitoring of the Implementation and Migration Plan. The intent is to enable the generation of continuous business value, even accepting that this might involve planned rework in subsequent sets of deliverables. There are several issues to address in this activity:

• Performance Evaluation Criteria are used by portfolio and capability managers to approve and monitor the progress of the architecture transformation.
• Return on Investment Criteria have to be detailed and signed off by the various executive stakeholders. Some of the IT contributions (e.g., business applications) to the realization of capabilities will be highly visible, while others (e.g., messaging services) might be critical but not visible. It is important that the CIO, as part of the corporate executive, establish return on investment criteria that ensure that the IT contribution is appropriately measured.
• Business Value has to be defined as well as techniques, such as the value chain (e.g., NASCIO), which are to be used to illustrate the IT role (as well as other business functions) in achieving tangible business outcomes. The business value will be used by portfolio and capability managers to allocate resources and, in cases where there are cutbacks, business value in conjunction with return on investment are the two prime factors used to determine whether an endeavor proceeds, is delayed, or canceled.
• Critical Success Factors (CSF) should be established to define success for a project and/or project increment. These will provide managers and implementers with a gauge as to what constitutes a successful implementation; it is also a form of contract between clients and developers/builders that will ensure a mutual understanding of business value.
• Measures of Effectiveness (MOE) are often performance criteria and many corporations include them in the CSFs. Where they are treated discretely, the enterprise architecture Transformation Plan should be clear as to how these criteria are to be grouped (e.g., in defense they include categories such as Persistence, Agility, Reach, Information, etc.).
• Strategic Fit based upon the overall enterprise architecture (all tiers) will be the critical factor for allowing the approval of any new endeavor (project/initiative or whatever) or determining the value of any deliverable. For example, the implementation of a new service will be assessed with respect to the enterprise architecture models; if it is to be delivered strategically fine; if it is not in the plan, then either the project is not approved or the architecture model can be changed to accommodate a good idea.

This activity should result in the establishment of a concrete set of criteria with which to assess the business value, return on investment, and measures to ascertain how the project is meeting their objectives.

14.4.2.2 Assign Risk to the Projects and Project Increments

The Consolidated Gaps, Solutions, and Dependencies Assessment (from Phase E) has a column of risks for each of the activities. The activities were logically grouped into portfolios, projects, and project increments in Phase E. The action is to aggregate the risks associated with each activity for the projects and their potential increments.

14.4.2.3 Assign Business Value to the Projects and Project Increments

Develop an estimated value to the business for each project. This should be completed with business management input with the enterprise architects ensuring that the value of the business enabling IT infrastructure is well understood (e.g., the single data environment that supports six other work packages).

14.4.2.4 Determine Continuous Business Value Assessment Technique

This assessment could be developed through the use of a matrix based on a value index dimension and a risk index dimension. An example is shown in Part III, 28.5 Business Value Assessment Technique .

This activity should be conducted by both business clients and the IT body. These measures will be used in portfolio management where the projects are often assessed with respect to this value-risk matrix with size and status (performance measurement) being graphically displayed. Value in this case should also be largely premised upon strategic fit that is directly attributed to the enterprise architecture.

Add project/SBB business value to the project list.

14.4.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicles

Determine the required resources and times for each project and project increment and provide the initial cost estimates for the projects. The costs should be broken down into capital (to create the capability) and operations and maintenance (to run and sustain the capability). Note that operations and maintenance funding will have to commence as soon as the first increment is delivered to the operations management organization, so it has to be clear from the outset where both types of funding are coming from (and whether they are affordable). Excellent examples of the challenges are the cost of software maintenance and the costs associated with upgrading (including some of the custom software modifications that were made).

Costs should be inclusive of all capability expenses including business process development, interoperability requirements, training, new personnel, facilities, and so on, keeping in mind that the actual cost estimate will be refined by the project once it has been established.

Using dependencies, opportunities should be identified where the costs associated with delivering new and/or better capability can be offset by sun-setting existing systems whose maintenance that might absorb a disproportionate amount of resources. This should be clearly annotated.

Assign required resources to each activity and aggregate them at the project increment and project level.

14.4.3.1 Determine Personnel and Infrastructure (Capital) Costs

Against each SBB, determine what the costs will be in terms of personnel and infrastructure. For personnel, this estimate should also include the costs associated with training, moving, and severance. Each organization accounts differently for these costs and the architect should be aware of what comes from the project budget and what does not. Ensure that all infrastructure costs are captured, including office space, furniture, and so on, charging them against the activities or against the project. For IT infrastructure costs, include hardware and software that has to be acquired.

Aggregate the SBB costs to come up with a total for capital costs for the project and project increment and then add this project capital cost to the list of projects.

14.4.3.2 Determine Operations and Maintenance Costs

These costs are associated with the total cost of ownership for a SBB. These costs are triggered after the SBB has been handed over to operations management from the project delivery organization. When delivering increments, projects will have in-service building blocks while they are still creating others. However, the project will be well over before the lifecycle of the SBB expires. The operations and maintenance costs for the incremental building blocks in service during the life of the project have to be factored in by either the project or the operations management organization.

This cost estimate will ensure that there are sufficient resources available to service the SBB while in the field, so it should address the entire SBB lifecycle. The operations and maintenance costs should be added to the SBB construction cost to give a total cost of ownership. This total cost of ownership should now be added to the list of projects.

14.4.3.3 Determine Transition Architecture/Project Increment Timings

The determination of resources will enable an initial estimate of the time that the projects and project increments will take. This gross estimate should be included by every SBB being envisaged.

14.4.3.4 Assess Best Delivery Vehicle

The architect should use this estimate to look at the resources available within the organization and determine whether the delivery vehicle should be internal, by contract, or a combination thereof.

In many organizations, the implications of contracting are time-consuming, but the availability of an enterprise architecture and a series of well-defined building blocks should greatly facilitate the composition of the Statement of Architecture Work and result in well-focused bids that address the needs.

14.4.4 Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation

Prioritize the projects by ascertaining the business value of the artifacts delivered by the projects against the cost of delivering them. The approach is to first determine, as clearly as possible, the net benefit of all of the SBBs delivered by the projects, then verify that the risks have been effectively mitigated and factored in. Afterwards, the intent is to gain the requisite consensus (often at the enterprise level) to create a prioritized list of projects (based upon SBB net benefit and risk) that will provide the basis for resource allocation.

14.4.4.1 Derive Cost Benefit Analysis for the Migration Projects

Use the previously derived business drivers (Phase E) to initiate the cost/benefit analysis and drive the return on investment. The return on investment has to be clear and take into account the stakeholders for which it is being prepared. There are many ways of presenting a return on investment, not all of which involve the compilation of a complex report and a never-ending presentation.

Sensitivity to stakeholders' concerns is paramount. For example, if employee retention is a top priority, then the transferability of the skill sets being made redundant by a new system has to be taken into consideration and a retraining effort factored into the cost/benefit arrangement.

The important part of this step is to discover all costs, and ensure that executives deal with the net benefit (cost savings over time - cost of initiative over time). Surprises can impact the credibility of the entire architecture transformation and migration effort. Update the list of projects with the project net benefit supported by comments.

14.4.4.2 Validate the Risk Assessment

In this activity the architect reviews the risks documented in the Gaps, Solutions, and Dependencies Report and ensures that the risks for the project artifacts have been mitigated as much as possible. Update the project list with risk-related comments.

14.4.4.3 Prioritize the Projects

Using the previously calculated net benefits, and the Gaps, Solutions, and Dependencies Analysis, get consensus amongst the stakeholders to agree upon a prioritization of the projects and a validation/update of the corporate risk assessment based upon the prioritization.

Prioritization criteria will include the key business drivers identified in Phase E as well as those relating to individual stakeholders' agendas, such as:

• Reduction of costs
• Consolidation of services
• Ability to handle change
• A goal to have a minimum of "interim" solutions (they often become long-term/strategic!)

The outcome of this step is critical as the funding line will be clearly drawn somewhere down the list and projects below the line will have to wait or be canceled. The stakeholders creating the prioritization should be fully familiar with the risk assessment and have it (preferably an executive summary) close at hand when prioritizing the various projects/initiatives.

Make sure that foundation projects (i.e., those that were the result of the requirements analysis and consolidated common requirements into one project) are identified. The stakeholders should be able to agree to a funding line (projects above are funded and those below are not, unless extra funds become available) that will extend over the duration of the strategic plan (dependent upon the organization and its definition of strategic).

The list of projects should clearly highlight dependencies; often the line cannot be arbitrarily drawn as dependencies might dictate that either more or even less funding will be required. For example, there may be no point in only funding Projects A-D and not Project E because Project D needs Project E functionality to run. It is a business decision as to whether to:

• Fund Project E
• Cancel Project D
• Re-scope Project D to include the dependent functionality Project E was to deliver

From an IT perspective, it is essential that the foundation projects, that are often invisible to the end client but an essential intermediary, be understood and supported by senior management. The approach of top-down design and partial bottom-up implementation is easy to grasp but hard to implement as some of the business functionality may initially have to be given a lower implementation priority than some of the core IT work (e.g., implementing a portal or setting up the network).

Conversely, foundation projects have to be business success-aware and be able to support business outcomes as soon as possible. This means that the technical implementation roadmap may initially be less than technically optimal, but through the delivery of consistent business success, converge upon an ideally optimized (at least managed) solution. For example, the optimal way of implementing a full-service portal is to buy a complete solution and integrate it, but to get business results, creating an initial portal capability (using an ad hoc approach) to deliver a very narrow range of services might suffice in the short term. Strategically, a complete portal offering can be designed and planned for the future, incorporating implementation lessons learned. [Efficient, no; but effective (in business terms), yes.] Naturally the CIO has to ensure that corporate governance is aware of and takes ownership of this approach.

Finally, the stakeholders have to review the risk assessment and revise it as necessary ensuring that there is a full understanding of the residual risk associated with the prioritization and the projected funding line.

Update and reorder the list of projects with a "Priorities" column documenting the agreed priorities.

14.4.5 Confirm Transition Architecture Increments/Phases and Update Architecture Definition Document

An incremental implementation infers that concurrent activity may occur on multiple Transition Architectures that are defined to the necessary, but minimum, level of detail.

Confirm the proposed Transition Architecture increments and content. Review the work to date to assess what the Transition Architecture time-spans should be, taking into consideration the business value (or capability) increments to be delivered and all other factors. Once the Transition Architecture increments have been determined, consolidate the deliverables by project increment for each Transition Architecture. This will result in the initial Transition Architecture Roadmap.

14.4.5.1 Confirm Transition Architecture Time-Spans

The first activity is to agree to a time-span of an increment. This is challenging and has to take into account the area where the architecture has to be implemented and the results of the analysis of the enterprise list of events and timings (i.e., Zachman Column 5, Rows 1 and 2).

For example, in a government agency the tendering process may end up determining how long an increment will be; in other enterprises it could be the budgetary cycle and in another support of a corporate strategic objective. In most cases, a budgetary cycle will be the key factor influencing the delivery of an increment, with the rationale being that if a future increment's funding is delayed, at least there will be a solid delivery of business capability by the preceding increment. The phases mark natural checkpoints to re-evaluate and refocus portfolios and projects that are not delivering as expected.

Ultimately, it is the availability of funding that will determine whether increments move forward or not.

14.4.5.2 Confirm Business Value Delivered by the Increments

Once the length of an increment is clearly established, review gap analyses, dependencies, and prioritized portfolios/projects and validate that discrete business outcomes can be delivered in increments.

This should be completed at the portfolio level as entire projects may be re-scheduled to allow others to move forward more rapidly. A successful basic strategy is to focus on projects that will deliver short-term pay-offs and so create an impetus for proceeding with longer-term projects.

This again has to be conducted with business and IT staff contributing. Based upon the previously determined business value criteria and the consolidated list of dependencies, the business capability managers and the IT enterprise architects have to determine realistic "chunks" of business capability that the inter-dependent prioritized projects can realistically deliver in increments.

From an IT perspective, it is again important to align the architectures of the foundation projects to ensure that they flexibly, and potentially sub-optimally, deliver the requisite support to achieving the business outcomes. For example, the implementation of e-Government could start in the first increment with the issuance of "licenses" with each subsequent increment delivering ever-increasing levels of functionality.

14.4.5.3 Update Previously Created Architecture Deliverables

If the implementation approach has shifted as a result of confirming the implementation increments, update the Transition Architectures to reflect the revised direction. Update the Architecture Definition, assigning project objectives and aligning projects and their deliverables with the enterprise architecture increments. An example using a tabular form assigning projects their incremental deliverables is shown in Part III, 28.3 Architecture Definition Increments Table .

The main feature is that the enterprise Architecture Definition is technology-aware but, as much as possible, technology-independent. The composition of the enterprise Architecture Definition Document is as described in Part IV, 36. Architecture Deliverables .

14.4.6 Generate the Architecture Implementation Roadmap (Time-Lined) and Migration Plan

This step generates the Implementation and Migration Plan sequence and details.

One of the main innovations of the tiered architecture is that it focuses on the continuous delivery of incremental business value and allows for the opportunistic exploitation of new technologies through the creation of just-in-time Transition Architectures.

The cost of this agility and flexibility is that there is significant concurrent activity that has to be closely co-ordinated. There are normally three to four Transition Architectures being managed concurrently, namely delivery, construction, design, and planning. There will be no one enterprise architecture and supporting plan with a myriad of detail, much of which will not stand the test of time; either from a business event or technology evolution perspective. Rather it will evolve over time towards a target state and be directed by a series of converging architecture states opportunistically moving towards a strategically defined Target Architecture. The enterprise architecture and Architecture Repository will also become ever-richer with enhanced content, re-usable resources and an ever-increasing amount of detail as the enterprise becomes self-documenting.

The main feature of architecture planning is that there will be a great deal of concurrent activity and the Implementation and Migration Plan will be the "glue" holding all of these artifacts together.

Much of the detail for the plan has already been gathered and this step brings it all together using accepted portfolio/project planning and management techniques.

14.4.6.1 Confirm Enterprise Architecture Evolution

There is a need to confirm the actual evolution of the architecture to co-ordinate the development of several concurrent instances of the various architectures. Resources have to be assigned to move the architectures ahead in a coherent manner, taking advantage of opportunities and innovations as well as coping with significant business events such as mergers, acquisitions, and the sell-off of certain lines of business.

This first part of the Implementation and Migration Plan shows the evolution of the architectures, that addresses the co-ordination of architectures created at different levels of granularity, and their various domain (business, data, application, and technology) components/building blocks. Detailed architectures are concerned with the state of the architecture at specific points in time, whereas more abstracted architectures are concerned with the state of the enterprise spanning a roadmap of many projects.

14.4.6.2 Enterprise Architecture State Evolution

This part of the Implementation and Migration Plan will show the proposed state of the architectures at various levels of detail depending upon how far in the future the snapshot is. This snapshot describes the functionality (in terms of implemented SBBs) delivered by the enterprise architecture at a particular point in time.

This can be effectively done through the use of the Foundation Architecture Technical Reference Model (TRM) and shows how the capabilities in each area evolve through the Transition Architectures.

14.4.6.3 Detailed Implementation and Migration Plan

The enterprise architect should complete this activity in conjunction with the portfolio management staff, whose primary responsibility will be to govern the implementation of the Target Architecture.

In Phase E and in previous steps within Phase F, most of the portfolio planning actions will have been completed and this step brings all the detail together into an overall plan.

Formally integrate all of the projects, project increments, and activities as well as dependencies into a project plan, preferably using a project scheduling and management tool that uses a standard methodology such as Critical Path Method or the like. The Transition Architecture states, with their defined business value, will act as portfolio milestones.

Ensure that all external dependencies are captured and included. For example, a delay in passing a certain piece of legislation may free up resources that can be used on another priority project.

Conduct resource leveling to ascertain the overall availability of resources with precedence being given to the priorities previously allocated. This exercise will clearly determine what can be done internally or externally with contract support. This will ensure that the architects allocate/reserve sufficient funds to projects with which to start their detailed planning. With the project architects already having participated in the specification of the Transition Architecture, these estimates should be fairly complete at this point in time.

14.4.6.4 Incorporate Project Schedules

Projects will take their assigned roles and ensure that their deliverables are thoroughly planned. Their project plans should be in part rolled up (in part or in their entirety) into the Implementation and Migration Plan. The enterprise architect might also find that the plan cannot accommodate their project concerns and must be updated.

The enterprise architect will then ensure that the plan is adjusted so that it has the best chance for success.

This activity results in the finalized Implementation and Migration Plan.

14.4.6.5 Plan the Migration Details

A building block is delivered when it becomes part of the corporate infrastructure and handed over to the operations management function.

The Migration Plan focuses on the actual handover of the constructed building blocks and their integration into the infrastructure.

The Migration Plan must cater for the ongoing operations and maintenance of the delivered building block and ensure that either the project and/or operations management have the resources to ensure that the building block is effectively sustained. As new project deliverables are often dependent upon those building blocks already in service, it is important that these deliverables are quickly but systematically placed into service.

14.4.7 Establish the Architecture Evolution Cycle and Document Lessons Learned

This treats the strategic enterprise Architecture Definition and Transition Architectures as configuration items that are managed in accordance with an accepted standard such as Information Technology Infrastructure Library (ITIL) that is now the basis for BS 15000 and ISO 20000.

Enterprise architectures must be kept up-to-date or they will slowly become irrelevant, superseded by portfolio and/or project architectures. The time required to translate a change from the strategic to the project architecture is significant and must be understood and catered for within the organization.

Furthermore, lessons learned are crucial within a learning organization and should be documented and assessed as part of the enterprise evolution process. The architecture evolution cycle will both impact and be governed by the enterprise's Architecture Change Management (Phase H).

14.4.7.1 Confirm the Enterprise Architecture Evolution Cycle

The set of architectures are dynamic and the transformation cycle will have to be subject to strict control in order to ensure that the architectures remain relevant and provide the critical guidance to the projects designing and delivering the SBBs.

There is also no point in creating a family of architecture artifacts that are not being maintained as they will become obsolete relatively quickly. In support of corporate business agility and to enable the incorporation of relevant emerging technology, there has to be a regular update mechanism built into the architecture transformation process.

Allocate sufficient time to execute this update cycle, considering the many activities to be co-ordinated. Specifically, there will be a "ripple" effect that will impact not only architectures, but portfolio and project plans. For example, a change in the enterprise Architecture Definition will probably impact two if not three Transition Architectures. This has to be taken into consideration when approving changes and formulating the update cycle.

There will also be a need to closely co-ordinate with the Enterprise Continuum and the ABBs and SBBs being actually deposited through the portfolio/project and Operations Management Frameworks. This will be part of the Architecture Governance phase.

14.4.7.2 Confirm the Enterprise Architecture Management Processes

Release management is particularly important so that everybody is able to contribute in a timely manner and that architects within the enterprise are using the authoritative architectures. Configuration management is also critical to ensure that the Enterprise Continuum and architectures are co-ordinated and that the architectures accurately reflect current and planned reality.

14.4.7.3 Document Lessons Learned

Lessons learned should be documented and treated as governance artifacts, reviewed and actioned, in the form of one or more change requests, or changes in processes, organizations, or whatever is needed to improve the development and implementation of enterprise architecture.

14.5 Outputs

The outputs of Phase F are:

• Implementation and Migration Plan, Version 1.0 (see Part IV, 36.2.14 Implementation and Migration Plan)
• Finalized Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document)
• Finalized Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification)
• Finalized Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)
• Finalized Transition Architecture (see Part IV, 36.2.22 Transition Architecture)
• Re-Usable Architecture Building Blocks (see Part IV, 36.2.1 Architecture Building Blocks)
• Requests for Architecture Work (see Part IV, 36.2.17 Request for Architecture Work) for the architecture aspects of implementation projects (if any)
• Architecture Contracts (standard) (see Part VII, 49. Architecture Contracts) for implementation projects
• Implementation Governance Model (see Part IV, 36.2.15 Implementation Governance Model)
• Change Requests arising from lessons learned

return to top of page