Phase G: Implementation Governance

Chapter 15                             <<< Previous | Next >>>

15.1 Objectives 15.2 Approach | 15.3 Inputs | 15.4 Steps | 15.5 Outputs

This chapter provides an architectural oversight of the implementation.

Requirements Management Phase H Phase G Phase F Phase E Phase D Phase C Phase B Phase A Preliminary Phase

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

15.3.2 Non-Architectural Inputs

15.3.3 Architectural Inputs

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

  • 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 may include, but are not restricted to:

  • 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
    • Business and IT operating models for the implemented solution

return to top of page

<<< Previous Home Next >>>