Home The TOGAF® Standard
Search
Word Search | Search Index


Advanced Search
Provide feedback on this page
TOGAF® Fundamental Content
Extended Guidance
General How-To
Establishing an EA Team
Domains
Agile Methods
Business Architecture
Data/Information Architecture
Sustainability
Security Architecture
Reference Models & Method

1. Introduction

Chapter Contents: 1.1 ADM Overview | 1.2 Architecture Development Cycle | 1.3 Adapting the ADM | 1.4 Architecture Governance | 1.5 Scoping the Architecture | 1.6 Architecture Alternatives | 1.7 Architecture Integration | 1.8 Summary

This chapter introduces the Architecture Development Method (ADM) cycle, adapting the ADM, architecture scope, and architecture integration.

1.1 ADM Overview

The TOGAF ADM describes a method for developing and managing the lifecycle of an Enterprise Architecture, and forms the core of the TOGAF Standard.

It integrates elements of the TOGAF Standard, as well as other available architectural assets, to meet the business needs of an organization.

1.1.1 The ADM, Enterprise Continuum, and Architecture Repository

The Enterprise Continuum provides a framework and context to support the leverage of relevant architecture assets in executing the ADM. These assets may include Architecture Descriptions, models, and patterns taken from a variety of sources, as explained in the TOGAF Standard — Architecture Content.

The Enterprise Continuum categorizes architectural source material — both the contents of the organization's own enterprise repositories and the set of relevant, available reference models and standards in the industry.

The practical implementation of the Enterprise Continuum will typically take the form of an Architecture Repository (see the TOGAF Standard — Architecture Content) that includes reference architectures, models, and patterns that have been accepted for use within the enterprise, and actual architectural work done previously within the enterprise. The architect would seek to re-use as much as possible from the Architecture Repository that was relevant to the project in hand. (In addition to the collection of architecture source material, the repository would also contain architecture development work-in-progress.)

At relevant places throughout the ADM there are reminders to consider which, if any, architecture assets from the Architecture Repository the architect should use. In some cases — for example, in the development of a Technology Architecture — this may be the TOGAF Foundation Architecture. In other cases — for example, in the development of a Business Architecture — it may be a reference model for e-Commerce taken from the industry at large.

The criteria for including source materials in an organization's Architecture Repository will typically form part of the Enterprise Architecture Governance process. These governance processes should consider available resources both within and outside the enterprise in order to determine when general resources can be adapted for specific enterprise needs and also to determine where specific solutions can be generalized to support wider re-use.

While using the ADM, the architect is developing a snapshot of the enterprise's decisions and their implications at particular points in time. Each iteration of the ADM will populate an organization-specific landscape with all the architecture assets identified and leveraged through the process, including the final organization-specific architecture delivered.

Architecture development is a continuous, cyclical process, and in executing the ADM repeatedly over time, the architect gradually adds more and more content to the organization's Architecture Repository. Although the primary focus of the ADM is on the development of the enterprise-specific architecture, in this wider context the ADM can also be viewed as the process of populating the enterprise's own Architecture Repository with relevant re-usable building blocks taken from the "left", more generic side of the Enterprise Continuum.

In fact, the first execution of the ADM will often be the hardest, since the architecture assets available for re-use will be relatively scarce. Even at this stage of development, however, there will be architecture assets available from external sources such as the TOGAF Standard, as well as the IT industry at large, that could be leveraged in support of the effort.

Subsequent executions will be easier as more and more architecture assets become identified, are used to populate the organization's Architecture Repository, and are thus available for future re-use.

1.1.2 The ADM and the Foundation Architecture

The ADM is also useful to populate the Foundation Architecture of an enterprise. Business requirements of an enterprise may be used to identify the necessary definitions and selections in the Foundation Architecture. This could be a set of re-usable common models, policy and governance definitions, or even as specific as overriding technology selections (e.g., if mandated by law). Population of the Foundation Architecture follows similar principles as for an Enterprise Architecture, with the difference that requirements for a whole enterprise are restricted to the overall concerns and thus less complete than for a specific enterprise.

It is important to recognize that existing models from these various sources, when integrated, may not necessarily result in a coherent Enterprise Architecture. "Integratability" of Architecture Descriptions is considered in 1.7 Architecture Integration .

1.1.3 ADM and Supporting Guidelines and Techniques

The application of the TOGAF ADM is supported by an extended set of resources — guidelines, templates, checklists, and other detailed materials. These are included in:

The individual guidelines and techniques are described separately so that they can be referenced from the relevant points in the ADM as necessary, rather than having the detailed text clutter the description of the ADM itself.

1.2 Architecture Development Cycle

1.2.1 Key Points

The following are the key points about the ADM:

These issues are considered in detail in 1.3 Adapting the ADM .

1.2.2 Basic Structure

The basic structure of the ADM is shown in Figure 1-1 .

Throughout the ADM cycle, there needs to be frequent validation of results against the original expectations, both those for the whole ADM cycle, and those for the particular phase of the process.

Figure 1-1: Architecture Development Cycle

The phases of the ADM cycle are further divided into steps, which are defined in the detailed description of each phase.

The Requirements Management phase is a continuous phase which ensures that any changes to requirements are handled through appropriate governance processes and reflected in all other phases. An enterprise may choose to record all new requirements, including those which are in scope of the current Statement of Architecture Work through a single Requirements Repository.

The phases of the cycle are described in detail in the following chapters.

Note that output is generated throughout the process, and that the output from an early phase may be modified in a later phase. In the ADM, the status of outputs at each stage is defined. The lifecycle of outputs must be managed through a version numbering policy, adapted by the architect to meet the requirements of the organization and to work with the architecture tools and repositories employed by the organization.

In the ADM, documents which are under development and have not undergone any formal review and approval process are designated "draft". Documents which have been reviewed and approved are designated "approved" in accordance with the organization's governance practices. Approved does not necessarily mean finalized. Documents may evolve during subsequent phases but may only be changed through an appropriate change control and governance process. This is used in particular within the ADM to illustrate the evolution of Baseline and Target Architecture Definitions.

1.3 Adapting the ADM

The ADM is a generic method for architecture development, which is 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 is to review its components for applicability, and then tailor them as appropriate to the circumstances of the individual enterprise. This activity may well produce an "enterprise-specific" ADM.

One reason for wanting to adapt the ADM, which it is important to stress, is that the order of the phases in the ADM is to some extent dependent on the maturity of the architecture discipline within the enterprise. For example, if the business case for doing architecture at all is not well recognized, then creating an Architecture Vision is almost always essential; and a detailed Business Architecture often needs to come next, in order to underpin the Architecture Vision, detail the business case for remaining architecture work, and secure the active participation of key stakeholders in that work. In other cases a slightly different order may be preferred; for example, a detailed inventory of the baseline environment may be done before undertaking the Business Architecture.

The order of phases may also be defined by the Architecture Principles and business principles of an enterprise. For example, the business principles may dictate that the enterprise be prepared to adjust its business processes to meet the needs of a packaged solution, so that it can be implemented quickly to enable a fast response to market changes. In such a case, the Business Architecture (or at least the completion of it) may well follow completion of the Information Systems Architecture or the Technology Architecture.

Another reason for wanting to adapt the ADM is if the TOGAF framework is to be integrated with another enterprise framework (as explained in the TOGAF Standard — Introduction and Core Concepts). For example, an enterprise may wish to use the TOGAF framework and its generic ADM in conjunction with the Zachman® Framework, or another Enterprise Architecture framework that has a defined set of deliverables specific to a particular vertical sector: Government, Defense, e-Business, Telecommunications, etc. The ADM has been specifically designed with this potential integration in mind.

Other possible reasons for wanting to adapt the ADM include:

The descriptions of the phases of the ADM contain lists of deliverables and artifacts that could be applicable to any enterprise. It is important to adapt deliverables and artifacts to reflect the specific needs of the enterprise for the required architecture.

Adapting the Content Framework and Enterprise Metamodel, which defines the organization-specific deliverables and artifacts, together with detailed descriptions of the specific deliverables and artifacts referenced in the ADM phase descriptions may be found in the TOGAF Standard — Architecture Content.

The ADM can also be adapted to support an Agile Enterprise Architecture delivery style as well as to enable enterprise agility. Detailed guidance on how to adapt the ADM may be found in the following documents:

Additional guidance on adapting the ADM process may be found in the TOGAF Standard — Applying the ADM, and also in the TOGAF® Series Guide: A Practitioners' Approach to Developing Enterprise Architecture Following the TOGAF ADM.

1.4 Architecture Governance

The ADM, whether adapted by the organization or used as documented here, is a key process to be managed in the same manner as other architecture artifacts classified through the Enterprise Continuum and held in the Architecture Repository. The Architecture Board should be satisfied that the method is being applied correctly across all phases of an architecture development iteration. Compliance with the ADM is fundamental to the governance of the architecture, to ensure that all considerations are made and all required deliverables are produced.

The management of all architectural artifacts, governance, and related processes should be supported by a controlled environment. Typically, this would be based on one or more repositories supporting versioned objects, process control, and status.

The major information areas managed by a governance repository should contain the following types of information:


The governance artifacts and process are themselves part of the contents of the Architecture Repository.

Architecture Governance is addressed in detail in the TOGAF Standard — EA Capability and Governance.

1.5 Scoping the Architecture

There are many reasons to constrain (or restrict) the scope of the architectural activity to be undertaken, most of which relate to limits in:

The scope chosen for the architecture activity should ideally allow the work of all architects within the enterprise to be effectively governed and integrated. This requires a set of aligned "architecture partitions" that ensure architects are not working on duplicate or conflicting activities. It also requires the definition of re-use and compliance relationships between architecture partitions.

The division of the enterprise and its architecture-related activity is discussed in more detail in the TOGAF Standard — Applying the ADM.

Four dimensions are typically used in order to define and limit the scope of an architecture:

Typically, the scope of an architecture is first expressed in terms of breadth, depth, and time. Once these dimensions are understood, a suitable combination of architecture domains can be selected that are appropriate to the problem being addressed. Techniques for using the ADM to develop a number of related architectures are discussed in the TOGAF Standard — Applying the ADM.

The four dimensions of architecture scope are explored in detail below. In each case, particularly in large-scale environments where architectures are necessarily developed in a federated manner, there is a danger of architects optimizing within their own scope of activity, instead of at the level of the overall enterprise. It is often necessary to sub-optimize in a particular area, in order to optimize at the enterprise level. The aim should always be to seek the highest level of commonality and focus on scalable and re-usable modules in order to maximize re-use at the enterprise level.

1.5.1 Breadth

One of the key decisions is the focus of the architecture effort, in terms of the breadth of overall enterprise activity to be covered (which specific business sectors, functions, organizations, geographical areas, etc.).

It is often necessary to have a number of different architectures existing across an enterprise, focused on particular timeframes, business functions, or business requirements.

For large complex enterprises, federated architectures — independently developed, maintained, and managed architectures that are subsequently integrated within an integration framework — are typical. Such a framework specifies the principles for interoperability, migration, and conformance. This allows specific business units to have architectures developed and governed as stand-alone architecture projects. More details and guidance on specifying the interoperability requirements for different solutions can be found in the TOGAF Standard — ADM Techniques.

The feasibility of a single enterprise-wide architecture for every business function or purpose may be rejected as too complex and unwieldy. In these circumstances it is suggested that a number of different Enterprise Architectures exist across an enterprise. These Enterprise Architectures focus on particular timeframes, business segments or functions, and specific organizational requirements. In such a case we need to create the overarching Enterprise Architecture as a "federation" of these Enterprise Architectures. An effective way of managing and exploiting these Enterprise Architectures is to adopt a publish-and-subscribe model that allows architecture to be brought under a governance framework. In such a model, architecture developers and architecture consumers in projects (the supply and demand sides of architecture work) sign up to a mutually beneficial framework of governance that ensures that:

Publish and subscribe techniques are being developed as part of general IT governance and specifically for the Defense sphere.

1.5.2 Depth

Care should be taken to judge the appropriate level of detail to be captured, based on the intended use of the Enterprise Architecture and the decisions to be made based on it. It is important that a consistent and equal level of depth be completed in each architecture domain (Business, Data, Application, Technology) included in the architecture effort. If pertinent detail is omitted, the architecture may not be useful. If unnecessary detail is included, the architecture effort may exceed the time and resources available, and/or the resultant architecture may be confusing or cluttered. Developing architectures at different levels of detail within an enterprise is discussed in more detail in the TOGAF Standard — Applying the ADM.

It is also important to predict the future uses of the architecture so that, within resource limitations, the architecture can be structured to accommodate future tailoring, extension, or re-use. The depth and detail of the Enterprise Architecture needs to be sufficient for its purpose, and no more.

Iterations of the ADM will build on the artifacts and the capabilities created during previous iterations.

There is a need to document all the models in an enterprise, to the level of detail appropriate to the need of the current ADM cycle. The key is to understand the status of the enterprise's architecture work, and what can realistically be achieved with the resources and competencies available, and then focus on identifying and delivering the value that is achievable. Stakeholder value is a key focus: too broad a scope may deter some stakeholders (no return on investment).

1.5.3 Time Period

The ADM is described in terms of a single cycle of Architecture Vision, and a set of Target Architectures (Business, Data, Application, Technology) that enable the implementation of the vision.

In such cases, a wider view may be taken, whereby an enterprise is represented by several different architecture instances (for example, strategic, segment, capability), each representing the enterprise at a particular point in time. One architecture instance will represent the current enterprise state (the "as-is", or baseline). Another architecture instance, perhaps defined only partially, will represent the ultimate target end-state (the "vision"). In-between, intermediate or "Transition Architecture" instances may be defined, each comprising its own set of Target Architecture Descriptions. An example of how this might be achieved is given in the TOGAF Standard — ADM Techniques.

By this approach, the Target Architecture work is split into two or more discrete stages:

  1. First, develop Target Architecture Descriptions for the overall (large-scale) system, demonstrating a response to stakeholder objectives and concerns for a relatively distant timeframe (for example, a six-year period).
  2. Then develop one or more "Transition Architecture" descriptions, as increments or plateaus, each in line with and converging on the Target Architecture Descriptions, and describing the specifics of the increment concerned.

In such an approach, the Target Architectures are evolutionary in nature, and require periodic review and update according to evolving business requirements and developments in technology, whereas the Transition Architectures are (by design) incremental in nature, and in principle should not evolve during the implementation phase of the increment, in order to avoid the "moving target" syndrome. This, of course, is only possible if the implementation schedule is under tight control and relatively short (typically less than two years).

The Target Architectures remain relatively generic, and are therefore less vulnerable to obsolescence than the Transition Architectures. They embody only the key strategic architectural decisions, which should be blessed by the stakeholders from the outset, whereas the detailed architectural decisions in the Transition Architectures are deliberately postponed as far as possible (i.e., just before implementation) in order to improve responsiveness vis a vis new technologies and products.

The enterprise evolves by migrating to each of these Transition Architectures in turn. As each Transition Architecture is implemented, the enterprise achieves a consistent, operational state on the way to the ultimate vision. However, this vision itself is periodically updated to reflect changes in the business and technology environment, and in effect may never actually be achieved, as originally described. The whole process continues for as long as the enterprise exists and continues to change.

Such a breakdown of the Architecture Description into a family of related architecture products of course requires effective management of the set and their relationships.

1.5.4 Architecture Domains

A complete Enterprise Architecture should address all four architecture domains (Business, Data, Application, Technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive Architecture Description encompassing all four architecture domains.

Architecture Descriptions will normally be built with a specific purpose in mind — a specific set of business drivers that drive the architecture development — and clarifying the specific issue(s) that the Architecture Description is intended to help explore, and the questions it is expected to help answer, is an important part of the initial phase of the ADM.

For example, if the purpose of a particular architecture effort is to define and examine technology options for achieving a particular capability, and the fundamental business processes are not open to modification, then a full Business Architecture may well not be warranted. However, because the Data, Application, and Technology Architectures build on the Business Architecture, the Business Architecture still needs to be thought through and understood.

While circumstances may sometimes dictate building an Architecture Description not containing all four architecture domains, it should be understood that such an architecture cannot, by definition, be a complete Enterprise Architecture. One of the risks is a lack of consistency and therefore an ability to integrate. Integration either needs to come later — with its own costs and risks — or the risks and trade-offs involved in not developing a complete and integrated architecture need to be articulated by the architect, and communicated to and understood by the enterprise management.

1.6 Architecture Alternatives

There is often more than one possible Target Architecture that would conform to the Architecture Vision, Architecture Principles, and Requirements. It is important to identify alternative Target Architectures and build understanding of different possibilities and identify trade-offs between the alternatives. Creating an architecture normally requires trade-offs among competing forces. Presenting different alternatives and trade-offs to stakeholders helps architects to extract hidden agendas, principles, and requirements that could impact the final Target Architecture.

1.6.1 Method

It is most common that a single alternative does not exist that will meet all stakeholders' concerns. The TOGAF Standard (see the TOGAF Standard — ADM Techniques: Architecture Alternatives and Trade-offs) provides a technique to investigate different alternatives and to discuss these with the stakeholders.

Commonly, alternatives are defined per domain. This is done to simplify the analysis of the different alternatives. Of course, the alternatives per domain can be merged into on overall analysis of the alternatives for the whole architecture. This approach is illustrated in Figure 1-2 .

The first part of the method uses the vision, principles, requirements, and other information to select sets of criteria fitting for different alternatives.

The second part of the method defines alternatives based on the criteria and builds an understanding of each.

The third part of the method will either select one of the alternatives, or else combine features from more than one, to create the proposed alternative. Perform the following activities in just enough detail to support that decision. The method can be used for any phase at any level of an architecture.

Figure 1-2: Architecture Alternatives Method

1.7 Architecture Integration

Architectures that are created to address a subset of issues within an enterprise require a consistent frame of reference so that they can be considered as a group as well as point deliverables. The dimensions that are used to define the scope boundary of a single architecture (e.g., level of detail, architecture domain, etc.) are typically the same dimensions that must be addressed when considering the integration of many architectures. Figure 1-3 illustrates how different types of architecture need to co-exist.

At the present time, the state of the art is such that architecture integration can be accomplished only at the lower end of the integratability spectrum. Key factors to consider are the granularity and level of detail in each artifact, and the maturity of standards for the interchange of architectural descriptions.

Figure 1-3: Integration of Architecture Artifacts

As organizations address common themes (such as Service-Oriented Architecture (SOA), and integrated information infrastructure) and universal data models and standard data structures emerge, integration toward the high end of the spectrum will be facilitated. However, there will always be the need for effective standards governance to reduce the need for manual co-ordination and conflict resolution.

1.8 Summary

The TOGAF ADM defines a recommended sequence for the various phases and steps involved in developing an architecture, but it cannot recommend a scope — this has to be determined by the organization itself, bearing in mind that the recommended sequence of development in the ADM process is an iterative one, with the depth and breadth of scope and deliverables increasing with each iteration. Each iteration will add resources to the organization's Architecture Repository.

While a complete framework is useful (indeed, essential) to have in mind as the ultimate long-term goal, in practice there is a key decision to be made as to the scope of a specific Enterprise Architecture effort. This being the case, it is vital to understand the basis on which scoping decisions are being made, and to set clear expectations for the goal of the effort.

The main guideline is to focus on what creates value to the enterprise, and to select horizontal and vertical scope, and time periods, accordingly. Whether or not this is the first time around, understand that this exercise will be repeated, and that future iterations will build on what is being created in the current effort, adding greater width and depth.

return to top of page
Copyright © 1999-2022 The Open Group, All Rights Reserved.
TOGAF is a registered trademark of The Open Group
  Home Next >>>