Introduction to the Architecture Development Method (ADM)

Overview    Design Principles    Adapting the ADM    Development Cycle


ADM Overview

The TOGAF Architecture Development Method (ADM) forms the core of TOGAF.  It is a reliable, proven method for developing an IT architecture that meets the business needs of an organization, utilizing the other elements of TOGAF described in this document, and other architectural assets available to the organization.

Relationship to Other Parts of TOGAF

TOGAF consists of two main parts:

The TOGAF ADM describes the process of moving from the TOGAF Foundation Architecture to an organization-specific architecture (or set of architectures), leveraging the elements of the TOGAF Foundation Architecture and other relevant architectural components and building blocks along the way.

The TOGAF Foundation Architecture is, of course, not the only resource available to the architect in using the ADM. There is a wide range of architectural models, components, and building blocks relating to different aspects of the architecture domain. This much wider context in which the TOGAF Foundation Architecture resides is referred to in TOGAF as the Enterprise Continuum (also explained in Part III).

It is important to note that, in executing the ADM, the architect is not only developing the end result of an organization-specific architecture, s/he is also populating the organization's own Enterprise Continuum, with all the architectural assets identified and leveraged along the way -- including, but not limited to, the resultant organization-specific architecture.

Although the primary focus of the ADM is on the development of the organization-specific architecture, in this wider context the ADM can also be viewed as the process of populating the organization's Enterprise Continuum with relevant reusable building blocks.

Architecture development is an iterative, on-going process, and in executing the ADM repeatedly over time, the architect gradually populates more and more of the organization's Enterprise Continuum.

In fact, the first execution of the ADM will often be the hardest, since the architectural assets available for re-use will be relatively few. (Even in the first execution, however, there will be some architecture assets available, from external sources such as The Open Group and TOGAF.)

Subsequent executions will be easier, however, as more and more architecture assets become identified, used to populate the organization's Enterprise Continuum, and thus available for re-use.


Architecture Design Principles

An architecture is a set of elements (sometimes called building blocks) depicted in an architectural model, and a specification of how these elements are connected to meet the overall requirements of an information system.

The various elements of an architecture specify the services required in an organization specific system.

There are some general principles underlying the use of the TOGAF ADM for the design and successful use of specific architectures:

Detailed considerations in the use of building blocks in the ADM are described separately, in Part IV, Building Blocks and the ADM.


Adapting the ADM

The ADM is a generic method for architecture development, which has been designed to deal with most system and organizational requirements. However, it will often be necessary to modify or extend the ADM to suit specific needs. One of the tasks before applying the ADM to a specific situation will be to review the ADM and tailor it if necessary to the circumstances of the enterprise concerned. This activity may well produce an organization-specific ADM.

One reason for wanting to do this is if TOGAF and its ADM are to be integrated into a wider, enterprise framework, as explained in Part I, TOGAF in the Enterprise.

Other typical reasons for wanting to do this include the following:


The Architecture Development Cycle

The recommended approach for architecture development is a cyclic one of the phases shown in Figure 1.

 

architecture development cycle

Figure 1: Architecture Development Cycle

The phases are iterative, both within each phase and among phases.

Throughout the phases of the cycle there needs to be frequent validation of the results against the original motivation to take the architecture through a new cycle (business requirements, financial and timing constraints, etc.). This continuous validation, as depicted in Figure 1, assures that the architecture is meeting the needs of the business.

The phases of the cycle shown in Figure 1 are further divided into steps, such as depicted in the expansion of the Target Architecture phase in Figure 2 below.

architecture development cycle - expansion

Figure 2: Architecture Development Cycle - Expansion

The seven phases of the cycle are described in the following sections. They address both technical and organizational issues. Because the focus of TOGAF is primarily on phase C, the creation of a target architecture, that phase is described in greater detail. However, the ADM covers the complete architecture life-cycle.

Note that output is generated throughout the process, and that the output in an early phase may be modified in a later phase. The versioning of output is managed through version numbers. For example, in the first phase the output Business Architecture - Version 1 is generated, while in phase 2 Business Architecture - Version 2 is generated. This concept is explained in detail later under ADM Input and Output Descriptions.

The following sections describe the phases in detail, and a quick reference table summarizing the phases can be found in Part IV, Tools for Architecture Development.

A detailed model of the ADM, showing the phase structure, the various inputs and outputs, and their relationships to other entities in the architecture environment, is shown in Part IV, ADM Model.


Copyright The Open Group, 1998, 1999, 2001