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 Architecture Development Method (ADM), described in detail here.

• The TOGAF Foundation Architecture, described in detail in Part III.  This is an architecture of generic services and functions that provides a firm foundation on which more specific architectures and architectural components can be built.

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:

• An architecture need only specify those services that it requires.
• Elements of an architecture may specify one, more than one, or only part of a service.
• Elements of an architecture should be defined in terms of standards relevant to the services they specify.
• Elements of an architecture should be reused from all the categories of the Architecture Continuum and should support reuse of solution elements of the Solution Continuum.
• Elements of the solution (or implementation) should be reused from all the categories of the Solutions Continuum.
• An architecture must be followed, or it is useless: formal IT Governance practices are therefore recommended.

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:

• It is necessary to link the ADM with other processes, such as those for authorization, risk limitation, business planning, budgeting, development planning, requirements, project management, systems development, procurement, etc.
• The ADM is being used as a development method for something other than IT architecture: for example, application architecture, data architecture, overall enterprise architecture, or as a general program management method. (As a generic method, the ADM is well suited to adaptation in this way.)

• The ADM is being mandated for use by a prime or lead contractor in an outsourcing situation, and needs to be tailored to achieve a suitable compromise between the contractor's existing practises and the contracting organization's requirements.

• The organization is a Small-to-Medium Enterprise, and wishes to produce a "cut-down" method more attuned to the reduced level of resources and system complexity typical of such an environment.

• The organziation is very large and complex, comprising many separate but interlinked "enterprises" within an overall "meta-enterprise", and the architecture method needs to be adapted to recognize this. Different approaches to planning and integration may be used in such cases, including the following (possibly in combination):
  • Top-down planning and development - designing the whole interconnected meta-enterprise as a single entity (an exercise that typically stretches the limits of practicality)
  • Development of a "generic" architecture, typical of the enterprises within the organization but not representing any specific enterprise, which individual enterprises are then expected to adapt to produce an architecture "instance" suited to the particular enterprise concerned.
    • The Open Group's Technical Architecture Builder and Browser tool provides an open, prototype tool for use in this kind of situation.
  • Replication - developing a specific architecture for one enterprise, implementing it as a proof of concept, and then taking that as a "reference architecture" to be cloned in other enterprises.
• In a vendor or production environment, a generic architecture is often referred to as a Product Line Architecture, and the analogous process to that outlined above is termed (Architecture-based) Product Line Engineering. The ADM is targeted primarily at architects in IT user organizations, but a vendor organization whose products are IT-based might well wish to adapt it as a generic method for a product line architecture development.

The Architecture Development Cycle

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

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.

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