Topic
Prev Next

The TOGAF Architecture Development Method

The key to TOGAF remains a reliable, practical method - the TOGAF Architecture Development Method (ADM) - for defining business needs and developing an architecture that meets those needs, applying the elements of TOGAF and other architectural assets available to the organization.

TOGAF embodies the concept of the Enterprise Continuum to reflect different levels of abstraction in an architecture development process. In this way TOGAF facilitates understanding and co-operation between actors at different levels. It provides a context for the use of multiple frameworks, models, and architecture assets in conjunction with the TOGAF ADM. By means of the Enterprise Continuum, architects are encouraged to leverage all other relevant architectural resources and assets, in addition to the TOGAF Foundation Architecture, in developing an organization-specific IT architecture.

Key Points About the ADM

The ADM is iterative over the whole process, between phases and within phases; for each iteration of the ADM, a fresh decision must be taken on:

  • The breadth of coverage of the enterprise to be defined
  • The level of detail to be defined
  • The extent of the time horizon aimed at, including the number and extent of any intermediate time horizons
  • The architectural assets to be leveraged in the organization's Enterprise Continuum, including:
  • Assets created in previous iterations of the ADM cycle within the enterprise
  • Assets available elsewhere in the industry (such as other frameworks, systems models and vertical industry models)

These decisions must be made on the basis of a practical assessment of resource and competence availability, and the value that can realistically be expected to accrue to the enterprise from the chosen scope of the architecture work.

As a generic method, the ADM is intended to be used by enterprises in a wide range of different geographies and applied in different vertical sectors/industry types. As such it can be - but does not necessarily have to be - tailored to specific needs. For example, it can be used:

  • In conjunction with the set of deliverables of another framework, where these are more appropriate for a specific organization; many US federal agencies have developed individual frameworks that define the deliverables specific to their particular departmental needs
  • In conjunction with the well-known Zachman Framework, which is an excellent classification scheme, but which lacks an openly available, well-defined methodology

Learn more