This chapter provides an architectural oversight of the implementation.

15.1 Objectives

The objectives of Phase G are:

• To formulate recommendations for each implementation project
• To govern and manage an Architecture Contract covering the overall implementation and deployment process
• To perform appropriate governance functions while the solution is being implemented and deployed
• To ensure conformance with the defined architecture by implementation projects and other projects
• To ensure that the program of solutions is deployed successfully, as a planned program of work
• To ensure conformance of the deployed solution with the Target Architecture
• To mobilize supporting operations that will underpin the future working lifetime of the deployed solution

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

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

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

15.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
• 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
• Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document)
• Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including:
  • Architectural requirements
  • Gap analysis results (from Business, Data, Application, and Technology Architectures)
• Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)
• Transition Architecture (see Part IV, 36.2.22 Transition Architecture), including:
• Implementation Governance Model (see Part IV, 36.2.15 Implementation Governance Model)
• Architecture Contract (standard) (see Part VII, 49. Architecture Contracts)
• Request for Architecture Work (see Part IV, 36.2.17 Request for Architecture Work) identified during Phases E and F
• Implementation and Migration Plan (see Part IV, 36.2.14 Implementation and Migration Plan)

15.4 Steps

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.

The steps in Phase G are as follows:

• 15.4.1 Confirm Scope and Priorities for Deployment with Development Management
• 15.4.2 Identify Deployment Resources and Skills
• 15.4.3 Guide Development of Solutions Deployment
• 15.4.4 Perform Enterprise Architecture Compliance Reviews
• 15.4.5 Implement Business and IT Operations
• 15.4.6 Perform Post-Implementation Review and Close the Implementation

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
• Produce Implementation Plan

15.4.4 Perform Enterprise Architecture Compliance Reviews

• 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 are:

• Architecture Contract (signed) (see Part VII, 49. Architecture Contracts), as recommended in the architecture-compliant implemented architectures
• Compliance Assessments (see Part IV, 36.2.13 Compliance Assessment)
• Change Requests (see Part IV, 36.2.11 Change Request )
• Architecture-compliant solutions deployed including:
  • The architecture-compliant implemented system

    Note:

    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
  • Recommendations on service delivery requirements
  • Recommendations on performance metrics
  • Service Level Agreements (SLAs)
  • Architecture Vision, updated post-implementation
  • Architecture Definition Document, updated post-implementation
  • Transition Architecture, updated post-implementation
  • Business and IT operating models for the implemented solution

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