| You are here: | ||
| <<< Previous | Home | Next >>> |
This chapter describes the process of identifying delivery vehicles (projects, programs, or portfolios) that effectively deliver the Target Architecture identified in previous phases.
The objectives of Phase E are:
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.
This section defines the inputs to Phase E.
The level of detail addressed in Phase E will depend on the scope and goals of the overall architecture effort.
The order of the steps in Phase E (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance.
The steps in Phase E are as follows:
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.
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 .
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:
These factors should be documented in the Implementation Factor Assessment and Deduction matrix.
Conduct an assessment of the enterprise, and specifically the IT organization, to ensure that at least the following factors are addressed:
These factors should be documented in the Implementation Factor Assessment and Deduction matrix.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Consolidate interoperability requirements identified in previous phases. Reconcile the consolidated requirements with potential solutions.
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.
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.
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:
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.
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:
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.
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.
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.
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.
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.
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.
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.
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:
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.
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:
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.
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.
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:
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:
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).
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.
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.
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.
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.
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.
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.
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.
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.
The outputs of Phase E are:
The TOGAF document set is designed for use with frames. To navigate around the document:
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G091.