36. Architecture Deliverables

Chapter Contents
36.1 Introduction | 36.2 Deliverable Descriptions

This chapter provides descriptions of deliverables referenced in the Architecture Development Method (ADM).

36.1 Introduction

This chapter defines the deliverables that will typically be consumed and produced across the TOGAF ADM cycle. As deliverables are typically the contractual or formal work products of an architecture project, it is likely that these deliverables will be constrained or altered by any overarching project or process management for the enterprise (such as CMMI, PRINCE2, PMBOK, or MSP).

This chapter therefore is intended to provide a typical baseline of architecture deliverables in order to better define the activities required in the ADM and act as a starting point for tailoring within a specific organization.

The TOGAF Content Framework (see Part IV, 33. Introduction) identifies deliverables that are produced as outputs from executing the ADM cycle and potentially consumed as inputs at other points in the ADM. Other deliverables may be produced elsewhere and consumed by the ADM.

Deliverables produced by executing the ADM are shown in the table below.


Deliverable

Output from...

Input to...

Architecture Building Blocks

F, H

A, B, C, D

(see 36.2.1 Architecture Building Blocks)

 

 

Architecture Contract

F

G

(see 36.2.2 Architecture Contract)

 

 

Architecture Definition Document

B, C, D

C, D, E, F, G, H

(see 36.2.3 Architecture Definition Document)

 

 

Architecture Principles

Preliminary,

Preliminary,

(see 36.2.4 Architecture Principles)

A, B, C, D

A, B, C, D, E, F, G, H

Architecture Repository

Preliminary

Preliminary,

(see 36.2.5 Architecture Repository)

 

A, B, C, D, E, F, G, H,

 

 

Requirements Management

Architecture Requirements

B, C, D, E, F,

C, D,

Specification (see 36.2.6 Architecture Requirements Specification)

Requirements Management

Requirements Management

Architecture Roadmap

B, C, D, E, F

C, D, E, F, G, H

(see 36.2.7 Architecture Roadmap)

 

 

Architecture Vision

A

B, C, D, E, F, G, H,

(see 36.2.8 Architecture Vision)

 

Requirements Management

Business Principles, Business Goals, and Business Drivers

Preliminary, A, B

A, B

(see 36.2.9 Business Principles, Business Goals, and Business Drivers)

 

 

Capability Assessment

A, E

B, C, D, E, F

(see 36.2.10 Capability Assessment)

 

 

Change Request

H

-

(see 36.2.11 Change Request)

 

 

Communications Plan

A

B, C, D, E, F

(see 36.2.12 Communications Plan)

 

 

Compliance Assessment

G

H

(see 36.2.13 Compliance Assessment)

 

 

Implementation and Migration Plan

E, F

F

(see 36.2.14 Implementation and Migration Plan)

 

 

Implementation Governance Model

F

G, H

(see 36.2.15 Implementation Governance Model)

 

 

Organizational Model for Enterprise

Preliminary

Preliminary,

Architecture (see 36.2.16 Organizational Model for Enterprise Architecture)

 

A, B, C, D, E, F, G, H,

 

 

Requirements Management

Request for Architecture Work

Preliminary, F

A, G

(see 36.2.17 Request for Architecture Work)

 

 

Requirements Impact Assessment

H,

Requirements Management

(see 36.2.18 Requirements Impact Assessment)

Requirements Management

 

Solution Building Blocks

G

A, B, C, D

(see 36.2.19 Solution Building Blocks)

 

 

Statement of Architecture Work

A, B, C, D

B, C, D, E, F, G, H,

(see 36.2.20 Statement of Architecture Work)

 

Requirements Management

Tailored Architecture Framework

Preliminary, A

Preliminary,

(see 36.2.21 Tailored Architecture Framework)

 

A, B, C, D, E, F, G, H,

 

 

Requirements Management

Transition Architecture

E, F

G, H

(see 36.2.22 Transition Architecture)

 

 

36.2 Deliverable Descriptions

The following sections provide example descriptions of deliverables referenced in the ADM.

Note that not all the content described here need be contained in a particular deliverable. Rather, it is recommended that external references be used where possible; for example, the strategic plans of a business should not be copied into a Request for Architecture Work, but rather the title of the strategic plans should be referenced.

Also, it is not suggested that these descriptions should be followed to the letter. However, each element should be considered carefully; ignoring any input or output item may cause problems downstream.

36.2.1 Architecture Building Blocks

Architecture documentation and models from the enterprise's Architecture Repository; see Part IV, 37. Building Blocks .

36.2.2 Architecture Contract

Purpose

Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. Successful implementation of these agreements will be delivered through effective architecture governance (see Part VII, 50. Architecture Governance ). By implementing a governed approach to the management of contracts, the following will be ensured:

Content

Typical contents of an Architecture Design and Development Contract are:

Typical contents of a Business Users' Architecture Contract are:

For more detail on the use of Architecture Contracts, see Part VII, 49. Architecture Contracts .

36.2.3 Architecture Definition Document

Purpose

The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, interim state(s), and target).

The Architecture Definition Document is a companion to the Architecture Requirements Specification, with a complementary objective:

Content

Typical contents of an Architecture Definition Document are:

36.2.4 Architecture Principles

Purpose

Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.

In their turn, principles may be just one element in a structured set of ideas that collectively define and guide the organization, from values through to actions and results.

Content

See Part III, 23. Architecture Principles for guidelines and a detailed set of generic architecture principles, including:

36.2.5 Architecture Repository

Purpose

The Architecture Repository acts as a holding area for all architecture-related projects within the enterprise. The repository allows projects to manage their deliverables, locate re-usable assets, and publish outputs to stakeholders and other interested parties.

Content

See Part V, 41. Architecture Repository for a detailed description of the content of an Architecture Repository.

Typical contents of an Architecture Repository are:

36.2.6 Architecture Requirements Specification

Purpose

The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition.

As mentioned above, the Architecture Requirements Specification is a companion to the Architecture Definition Document, with a complementary objective:

Content

Typical contents of an Architecture Requirements Specification are:

36.2.7 Architecture Roadmap

Purpose

The Architecture Roadmap lists individual increments of change and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. The Architecture Roadmap forms a key component of Transition Architectures and is incrementally developed throughout Phases B, C, D, E, and F within the ADM.

Content

Typical contents of an Architecture Roadmap are:

36.2.8 Architecture Vision

Purpose

The Architecture Vision is created early on in the project lifecycle and provides a high-level, aspirational view of the end architecture product. The purpose of the vision is to agree at the outset what the desired outcome should be for the architecture, so that architects can then focus on the critical areas to validate feasibility. Providing an Architecture Vision also supports stakeholder communication by providing an executive summary version of the full Architecture Definition.

Content

Typical contents of an Architecture Vision are:

36.2.9 Business Principles, Business Goals, and Business Drivers

Purpose

Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. Many factors that lie outside the consideration of architecture discipline may nevertheless have significant implications for the way that architecture is developed.

Content

The content and structure of business context for architecture is likely to vary considerably from one organization to the next.

36.2.10 Capability Assessment

Purpose

Before embarking upon a detailed Architecture Definition, it is valuable to understand the baseline and target capability level of the enterprise. This Capability Assessment can be examined on several levels:

Content

Typical contents of a Capability Assessment are:

36.2.11 Change Request

Purpose

During implementation of an architecture, as more facts become known, it is possible that the original Architecture Definition and requirements are not suitable or are not sufficient to complete the implementation of a solution. In these circumstances, it is necessary for implementation projects to either deviate from the suggested architectural approach or to request scope extensions. Additionally, external factors - such as market factors, changes in business strategy, and new technology opportunities - may open up opportunities to extend and refine the architecture.

In these circumstances, a Change Request may be submitted in order to kick-start a further cycle of architecture work.

Content

Typical contents of a Change Request are:

36.2.12 Communications Plan

Purpose

Enterprise architectures contain large volumes of complex and inter-dependent information. Effective communication of targeted information to the right stakeholders at the right time is a critical success factor for enterprise architecture. Development of a Communications Plan for architecture allows for this communication to be carried out within a planned and managed process.

Content

Typical contents of a Communications Plan are:

36.2.13 Compliance Assessment

Purpose

Once an architecture has been defined, it is necessary to govern that architecture through implementation to ensure that the original Architecture Vision is appropriately realized and that any implementation learnings are fed back into the architecture process. Period compliance reviews of implementation projects provide a mechanism to review project progress and ensure that the design and implementation is proceeding in-line with the strategic and architectural objectives.

Content

Typical contents of a Compliance Assessment are:

36.2.14 Implementation and Migration Plan

Purpose

The Implementation and Migration Plan provides a schedule for implementation of the solution described by a Transition Architecture. The Implementation and Migration Plan includes timing, cost, resources, benefits, and milestones for the implementation.

Content

Typical contents of an Implementation and Migration Plan are:

36.2.15 Implementation Governance Model

Purpose

Once an architecture has been defined, it is necessary to plan how the Transition Architecture that implements the architecture will be governed through implementation. Within organizations that have established architecture functions, there is likely to be a governance framework already in place, but specific processes, organizations, roles, responsibilities, and measures may need to be defined on a project-by-project basis.

The Implementation Governance Model ensures that a project transitioning into implementation also smoothly transitions into appropriate architecture governance.

Content

Typical contents of an Implementation Governance Model are:

36.2.16 Organizational Model for Enterprise Architecture

Purpose

In order for an architecture framework to be used successfully, it must be supported by the correct organization, roles, and responsibilities within the enterprise. Of particular importance is the definition of boundaries between different enterprise architecture practitioners and the governance relationships that span across these boundaries.

Content

Typical contents of an Organizational Model for enterprise architecture are:

36.2.17 Request for Architecture Work

This is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. Requests for Architecture Work can be created as an output of the Preliminary phase, a result of approved architecture Change Requests, or terms of reference for architecture work originating from migration planning.

In general, all the information in this document should be at a high level.

Requests for Architecture Work typically include:

36.2.18 Requirements Impact Assessment

Purpose

Throughout the ADM, new information is collected relating to an architecture. As this information is gathered, new facts may come to light that invalidate existing aspects of the architecture. A Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes.

Content

Typical contents of a Requirements Impact Assessment are:

36.2.19 Solution Building Blocks

Implementation-specific building blocks from the enterprise's Architecture Repository; see Part IV, 37. Building Blocks .

36.2.20 Statement of Architecture Work

Purpose

The Statement of Architecture Work defines the scope and approach that will be used to complete an architecture project. The Statement of Architecture Work is typically the document against which successful execution of the architecture project will be measured and may form the basis for a contractual agreement between the supplier and consumer of architecture services.

Content

Typical contents of a Statement of Architecture Work are:

36.2.21 Tailored Architecture Framework

Purpose

TOGAF provides an industry standard framework for architecture that may be used in a wide variety of organizations. However, before TOGAF can be effectively used within an architecture project, tailoring at two levels is necessary.

Firstly, it is necessary to tailor the TOGAF model for integration into the enterprise. This tailoring will include integration with project and process management frameworks, customization of terminology, development of presentational styles, selection, configuration, and deployment of architecture tools, etc. The formality and detail of any frameworks adopted should also align with other contextual factors for the enterprise, such as culture, stakeholders, commercial models for enterprise architecture, and the existing level of architecture capability.

Once the framework has been tailored to the enterprise, further tailoring is necessary in order to tailor the framework for the specific architecture project. Tailoring at this level will select appropriate deliverables and artifacts to meet project and stakeholder needs.

See Part II, 6.4.5 Select and Tailor Architecture Framework(s) for further considerations when selecting and tailoring the architecture framework.

Content

Typical contents of a Tailored Architecture Framework are:

36.2.22 Transition Architecture

Purpose

A Transition Architecture shows the enterprise at incremental states reflecting periods of transition that sit between the Baseline and Target Architectures. Transition Architectures are used to allow for individual work packages and projects to be grouped into managed portfolios and programs, illustrating the business value at each stage.

Content

Typical contents of a Transition Architecture are:


return to top of page

Navigation

The TOGAF document set is designed for use with frames. To navigate around the document:

return to top of page

Downloads

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.


Copyright © 1999-2009 The Open Group, All Rights Reserved. Not for redistribution.
TOGAF is a registered trademark of The Open Group in the United States and other countries.