This chapter provides an architectural oversight of the implementation.
Figure 15-1: Phase G: Implementation Governance
15.1 Objectives
The objectives of Phase G are to:
Ensure conformance with the Target Architecture by implementation projects
Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests
15.2 Approach
It is here that all the information for successful management of the various implementation projects is brought together. Note that, in parallel with Phase G, there is the execution of an organizational-specific development process, where the actual development happens.
To enable early realization of business value and benefits, and to minimize the risk in the transformation and migration program, the favored approach is to deploy the Target Architecture as a series of transitions. Each transition represents an incremental step towards the target, and each delivers business benefit in its own right. Therefore, the overall approach in Phase G is to:
Establish an implementation program that will enable the delivery of the Transition Architectures agreed for implementation during the Migration Planning phase
Adopt a phased deployment schedule that reflects the business priorities embodied in the Architecture Roadmap
Follow the organization's standard for corporate, IT, and architecture governance
Use the organization's established portfolio/program management approach, where this exists
Define an operations framework to ensure the effective long life of the deployed solution
Phase G establishes the connection between architecture and implementation organization, through the Architecture Contract.
Project details are developed, including:
Name, description, and objectives
Scope, deliverables, and constraints
Measures of effectiveness
Acceptance criteria
Risks and issues
Implementation governance is closely allied to overall architecture governance, which is discussed in Part VII, 50. Architecture Governance.
A key aspect of Phase G is ensuring compliance with the defined architecture(s), not only by the implementation projects, but also by other ongoing projects within the enterprise. The considerations involved with this are explained in detail in Part VII, 48. Architecture Compliance.
15.3 Inputs
This section defines the inputs to Phase G.
15.3.1 Reference Materials External to the Enterprise
The level of detail addressed in Phase G will depend on the scope and goals of the overall architecture effort.
The order of the steps in Phase G (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.
15.4.1 Confirm Scope and Priorities for Deployment with Development Management
Review migration planning outputs and produce recommendations on deployment
Identify enterprise architecture priorities for development teams
Identify deployment issues and make recommendations
Identify building blocks for replacement, update, etc.
Perform gap analysis on enterprise architecture and solutions framework
The gaps in the existing enterprise solutions framework need to be identified and the specific Solution Building Blocks (SBBs) required to fill these gaps will be the identified by the solutions architects. These SBBs may have a one-to-one or many-to-one relationship with the projects. The solutions architects need to define exactly how this will be done. There may be other projects working on these same capabilities and the solutions architects need to ensure that they can leverage best value from these investments.
Produce a gap analysis report
15.4.2 Identify Deployment Resources and Skills
The project resources will include the development resources which will need to be educated in the overall enterprise architecture deliverables and expectations from the specific development and implementation projects.
The following considerations should be addressed in this step:
Identify system development methods required for solutions development
Note:
There are a range of systems development methods and tools available to the project teams. The method should ideally be able to interoperate with the architecture outputs; for example, generate code from architecture artifacts delivered to date. This could be achieved through the use of modeling languages used for the enterprise architecture development that may be captured as inputs to the systems development tools and thereby reduce the cost of solutions development.
Ensure that the systems development method enables feedback to the architecture team on designs
15.4.3 Guide Development of Solutions Deployment
Formulate project recommendation
For each separate implementation and deployment project, do the following:
Document scope of individual project in impact analysis
Document strategic requirements (from the architectural perspective) in impact analysis
Document change requests (such as support for a standard interface) in impact analysis
Document rules for conformance in impact analysis
Document timeline requirements from roadmap in impact analysis
Document Architecture Contract
Obtain signature from all developing organizations and sponsoring organization
Update Enterprise Continuum directory and repository for solutions
Guide development of business & IT operating models for services
Provide service requirements derived from enterprise architecture
Guide definition of business & IT operational requirements
Carry out gap analysis between the Solution Architecture and operations
Review ongoing implementation governance and architecture compliance for each building block
Conduct post-development reviews
Close development part of deployment projects
15.4.5 Implement Business and IT Operations
Carry out the deployment projects including: IT services delivery implementation; business services delivery implementation; skills development & training implementation; communications documentation publication
Publish new Baseline Architectures to the Architecture Repository and update other impacted repositories, such as operational configuration management stores
15.4.6 Perform Post-Implementation Review and Close the Implementation
Conduct post-implementation reviews
Publish reviews and close projects
Closure on Phase G will be when the solutions are fully deployed once.
15.5 Outputs
The outputs of Phase G may include, but are not restricted to:
Architecture Contract (signed) (see Part VII, 49. Architecture Contracts), as recommended in the architecture-compliant implemented architectures
The implemented system is actually an output of the development process. However, given the importance of this output, it is stated here as an output of the ADM. The direct involvement of architecture staff in implementation will vary according to organizational policy, as described in Part VII, 50. Architecture Governance.
Populated Architecture Repository
Architecture compliance recommendations and dispensations
The TOGAF document set is designed for use with frames. To navigate around the document:
In the main Contents frame in the left margin of the page, click the relevant hyperlink to load the Contents List for that Part of the TOGAF document or go direct to a chapter within the document.
Within a chapter you can select Previous and Next at the top and bottom of the page to move to the previous or next chapter, or select Home to return to the welcome page.
Downloads of TOGAF®, an Open Group Standard, are available under license from the TOGAF information web site. The license is free to any organization wishing to use the TOGAF standard 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 G116.
