20. Applying the ADM at Different Enterprise Levels

Chapter Contents
20.1 Overview | 20.2 Classes of Architecture Engagement | 20.3 Developing Architectures at Different Levels | 20.4 ADM Cycle Approaches

20.1 Overview

The TOGAF Architecture Development Method (ADM) is intended to be used as a model to support the definition and implementation of architecture at multiple levels within an enterprise. As discussed in Part V, 40. Architecture Partitioning , it is not possible to develop a single architecture that addresses all the needs of all stakeholders. Therefore, the enterprise must be partitioned into different areas, each of which can be supported by architectures. As discussed in Part V, enterprise architectures are typically partitioned according to Subject Matter, Time Period, and Level of Detail, as illustrated in Summary Classification Model for Architecture Landscapes .


Figure 20-1: Summary Classification Model for Architecture Landscapes

This chapter discusses the types of engagement that architects may be required to perform and how the ADM can be used to co-ordinate the activities of various teams of architects, working at different levels of the enterprise.

20.2 Classes of Architecture Engagement

An architecture function or services organization may be called on to assist an enterprise in a number of different contexts, as architects range from summary to detail, broad to narrow coverage, and current state to future state. Typically, there are three areas of engagement for architects:

Classes of Enterprise Architecture Engagement and the following table show the classes of enterprise architecture engagement.


Figure 20-2: Classes of Enterprise Architecture Engagement

Each of these architecture engagement types is described in the table below.


Area of

Architecture

 

Engagement

Engagement

Description

Definition of Change

Architectural Definition of Foundational Change Initiatives

Foundational change initiatives are change efforts that have a known objective, but are not strictly scoped or bounded by a shared vision or requirements.

In foundational change initiatives, the initial priority is to understand the nature of the problem and to bring structure to the definition of the problem.

Once the problem is more effectively understood, it is possible to define appropriate solutions and to align stakeholders around a common vision and purpose.

 

_

_

 

Architectural Definition of Bounded Change Initiatives

Bounded change initiatives are change efforts that typically arise as the outcome of a prior architectural strategy, evaluation, or vision.

In bounded change initiatives, the desired outcome is already understood and agreed upon. The focus of architectural effort in this class of engagement is to effectively elaborate a baseline solution that addresses the identified requirements, issues, drivers, and constraints.

Implementation Change

Architectural Governance of Change Implementation

Once an architectural solution model has been defined, it provides a basis for design and implementation.

In order to ensure that the objectives and value of the defined architecture are appropriately realized, it is necessary for continuing architecture governance of the implementation process to support design review, architecture refinement, and issue escalation.

Different classes of architecture engagement at different levels of the enterprise will require focus in specific areas, as shown below.


Engagement Type

Focus Iteration Cycles

Scope Focus

Supporting Business Strategy

Architecture Context

Architecture Definition
(Baseline First)

Broad, shallow consideration given to the Architecture Landscape in order to address a specific strategic question and define terms for more detailed architecture efforts to address strategy realization.

Architectural Portfolio Management of the Landscape

Architecture Context

Architecture Definition
(Baseline First)

Focus on physical assessment of baseline applications and technology infrastructure to identify improvement opportunities, typically within the constraints of maintaining business as usual.

Architectural Portfolio Management of Projects

Transition Planning

Architecture Deployment

Focus on projects, project dependencies, and landscape impacts to align project sequencing in a way that is architecturally optimized.

Architectural Definition of Foundational Change Initiatives

Architecture Context

Architecture Definition
(Baseline First)

Transition Planning

Focus on elaborating a vision through definition of baseline and identifying what needs to change to transition the baseline to the target.

Architectural Definition of Bounded Change Initiatives

Architecture Definition
(Target First)

Transition Planning

Focus on elaborating the target to meet a previously defined and agreed vision, scope, or set of constraints. Use the target as a basis for analysis to avoid perpetuation of baseline, sub-optimal architectures.

Architectural Governance of Change Implementation

Architecture Deployment

Use the Architecture Vision, constraints, principles, requirements, Target Architecture definition, and transition roadmap to ensure that projects realize their intended benefit, are aligned with each other, and are aligned with wider business need.

20.3 Developing Architectures at Different Levels

The previous sections have identified that different types of architecture are required to address different stakeholder needs at different levels of the organization. Each architecture typically does not exist in isolation and must therefore sit within a governance hierarchy. Broad, summary architectures set the direction for narrow and detailed architectures.

A number of techniques can be employed to use the ADM as a process that supports such hierarchies of architectures. Essentially there are two strategies that can be applied:

  1. Architectures at different levels can be developed through iterations within a single cycle of the ADM process.
  2. Architectures at different levels can be developed through a hierarchy of ADM processes, executed concurrently.

At the extreme ends of the scale, either of these two options can be fully adopted. In practice, an architect is likely to need to blend elements of each to fit the exact requirements of their Request for Architecture Work.

Each of these approaches is described in the sections below.

20.4 ADM Cycle Approaches

20.4.1 Using Iterations within a Single ADM Cycle

In situations where a single architecture team is tasked with defining architectures at many levels within the enterprise, it is possible to use iterations within a single ADM cycle to create all required architectures.

Using this approach, the Architecture Vision phase can be used to develop a strategic view of the architecture. Phases B, C, and D then provide a more detailed and formal architectural view of the landscape for different segments or time periods. Phases E and F then develop a detailed Migration Plan, which may include even more detailed and specific Capability Architectures.

A summary of the approach is shown in Iterations within a Single ADM Cycle Example .


Figure 20-3: Iterations within a Single ADM Cycle Example

The key benefits of this approach are:

The key limitations of this approach are:

Generally speaking, this approach should be used when a number of architectures are being developed within a similar time period by a single team.

20.4.2 Using a Hierarchy of ADM Processes

In cases where larger-scale architectures need to be developed by a number of different architecture teams, a more hierarchical application of the ADM may be used. This approach to the ADM uses the Migration Planning phase of one ADM cycle to initiate new projects, which will also develop architectures. This approach is illustrated in A Hierarchy of ADM Processes Example .


Figure 20-4: A Hierarchy of ADM Processes Example

The key benefits of this approach are:

The key limitations of this approach are:

Generally speaking, this approach should be used when architectures are being developed over different timelines by different teams.
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.