TOGAF ADM Tutorial

TOGAF®, The Open Group standard, is a proven enterprise architecture methodology and framework used by the world's leading organizations to improve business efficiency. It's the most prominent and reliable enterprise architecture standard, ensuring consistent standards, methods, and communication among enterprise architecture professionals. Enterprise architecture professionals fluent in TOGAF standards enjoy greater industry credibility, job effectiveness, and career opportunities. TOGAF helps practitioners avoid being locked into proprietary methods, utilize resources more efficiently and effectively, and realize a greater return on investment.

Why TOGAF?

The IT architecture needs to closely reflect the business goals of the organization. Indeed, specific techniques (business scenarios) should be used to ensure that the business goals are properly understood by the IT architect, and reflected in the IT architecture developed using TOGAF.

TOGAF Illustration

Here are the reasons that we should adopt TOGAF ADM for architecture development:

  • A comprehensive general method
  • Complementary to, not competing with, other frameworks
  • Widely adopted in the market
  • Tailorable to meet an organization and industry needs
  • Available under a free perpetual license
  • Vendor, tool and technology neutral open standard
  • Avoids re-inventing the wheel
  • Business IT alignment
  • Based in best practices
  • Possible to participate in the evolution of the framework

What is TOGAF Architecture Development Method (ADM)?

The Architecture Development Method (ADM) is applied to develop an enterprise architecture which will meet the business and information technology needs of an organization. The TOGAF ADM is the result of continuous contributions from a large number of architecture practitioners for serving the following purposes:

  • It describes a method for developing and managing the lifecycle of an enterprise architecture, and forms the core of TOGAF.
  • It may be tailored to the organization's needs and is then employed to manage the execution of architecture planning activities.

TOGAF and ArchiMate

ArchiMate is a modeling standard introduced by the Open Group. It provides a rich set of modeling notations and concepts that supports modeling Enterprise Architectures consistently within and across domains.

Since both TOGAF and ArchiMate are standards maintained by the Open Group and they both are used in enterprise architecture development, many people are confused between them, asking questions like "what's the difference between TOGAF and ArchiMate?", "TOGAF vs ArchiMate?", etc. The TOGAF framework and the ArchiMate modeling language are both maintained by The Open Group. The TOGAF 9.1 and ArchiMate 2.1 or above work well together and are compatible and complementary for EA development. While TOGAF ADM is an EA framework that can be used to develop and implement enterprise systems, processes, and structures, ArchiMate can be served as a visual modeling language that can be used to create EA descriptions.

It is important to reiterate that the ArchiMate standard is a modeling language and not a framework. The ArchiMate language is widely used for developing visual EA models, usually in conjunction with the TOGAF ADM. Moreover, the TOGAF and ArchiMate standards can put together to provide a set of viewpoints that can be applied for modeling the different architectures.

The ArchiMate language consists of the ArchiMate core language, which includes the Business, Application, and Technology Layers, along with elements to model the strategy and motivation underlying an architecture, as well as its implementation and migration.

The figure below shows a simplified mapping of how the ArchiMate language can be used in relation to the phases of the TOGAF Architecture Development Method (ADM).

TOGAF ADM and ArchiMate

ArchiMate Core

The code ArchiMate layers enables modeling of the architecture domains defined by TOGAF.

The Business, Application, and Technology Layers support the description of the Business, Information Systems, and Technology Architecture domains defined by the TOGAF framework, as well as their interrelationships.

Strategy and Motivation Extension

The strategy & motivation extension enables the modeling of stakeholders, drivers for change, business goals, principles and requirements.

The strategy and motivation elements in the ArchiMate language can be used to support the Requirements Management, Preliminary, and Architecture Vision phases of the TOGAF ADM, which establish the high level business goals, architecture principles, and initial business requirements. They are also relevant to the Architecture Change Management phase of the TOGAF ADM, since the phase deals with changing requirements.

Implementation and Migration Extension

The implementation and migration extension enables the modeling of project portfolio management, gap analysis and transition and migration planning.

The implementation and migration elements of the ArchiMate language support the implementation and migration of architectures through the Opportunities and Solutions, Migration Planning, and Implementation Governance phases of the TOGAF ADM.

TOGAF ADM Lifecycle - Iteration

The ADM supports the concept of iteration at three levels:

Cycling around the ADM: The ADM is presented in a circular manner indicating that the completion of one phase of architecture work directly feeds into subsequent phases of architecture work.

Iterating between phases: TOGAF describes the concept of iterating across phases (e.g., returning to Business Architecture on completion of Technology Architecture).

Cycling around a single phase: TOGAF supports repeated execution of the activities within a single ADM phase as a technique for elaborating architectural content.

TOGAF ADM

During application of the ADM process, a number of outputs are produced based on some inputs and steps according to the phase objective provided by the ADM.

TOGAF ADM - Input, Steps and Output

For example:

  • process flows
  • architectural requirements
  • project plans
  • project compliance assessments
  • etc.

In order to collate and present these major work products in a consistent and structured manner, TOGAF defines a structural model, in which to place them.

ADM Input and Output

TOGAF provides a number of input and output deliverables from each phases:

  • These are suggestions and need not be followed exactly
  • Each deliverable produced should be versioned to indicate when a change has occurred
  • The version numbering shown is also a suggestion and need not be followed

Deliverables

A work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. It will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model

TOGAF ADM - Steps and Deliverables

ADM Preliminary Phase

The preparation and initiation activities required to create an Architecture Capability including customization of TOGAF and definition of Architecture

Output Deliverables:

ADM Phase A: Architecture Vision

The initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development

Output Deliverables:

ADM Phase B: Business Architecture

Business Architecture: the development of a Business Architecture to support the agreed Architecture Vision

Output Deliverables:

ADM Phase C: Information Systems Architecture

Information Systems Architectures: the development of Information Systems Architectures to support the agreed Architecture Vision

ADM Phase D: Technology Architecture

Technology Architecture: the development of the Technology Architecture to support the agreed Architecture Vision

Output Deliverables:

ADM Phase E: Opportunities & Solutions

Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases

Output Deliverables:

ADM Phase F: Migration Planning

Migration Planning addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan

ADM Phase G: Implementation Governance

Implementation Governance provides an architectural oversight of the implementation

Output Deliverables:

ADM Phase H: Architecture Change Management

Architecture Change Management establishes procedures for managing change to the new architecture Requirements Management examines the process of managing architecture requirements throughout the ADM

Summary

The ADM is a comprehensive general method

  • It recommends a sequence for various phases and steps involved in developing an architecture
  • It is an iterative method
  • It draws on the other parts of TOGAF for assets and processes
  • It can be used with other deliverables from other frameworks

Here is the overview of the TOGAF ADM for each of the development phase as shown in the following Figure:

TOGAF ADM Cycle
TOGAF ADM Phase Phase Objective
Preliminary Prepares the organization for a successful architecture project
A. Architecture Vision Sets the scope, constraints and expectations for the project. Validate the business context and create the Statement of Architecture Work
B. Business Architecture Develop Business Architecture. Develop baseline as-is and target to-be and analyze the gaps.
C. Information Systems Architectures Develop Information Systems Architectures. Develop baseline as-is and target to-be and analyze the gaps.
D. Technology Architecture Develop Technology Architecture. Develop baseline as-is and target to-be and analyze the gaps.
E. Opportunities and Solutions Identify major implementation projects
F. Migration Planning Analyze the costs, benefits and risks. Produce an implementation roadmap.
G. Implementation Governance Ensure that the implementation projects conforms to the architecture
H. Architecture Change Management Ensure that the architecture responds to the needs of the enterprise as changes arise
Requirements Management Every stage of the project should be based on and validate business requirements.

創造美好 共同成長

We use cookies to offer you a better experience. By visiting our website, you agree to the use of cookies as described in our Cookie Policy.

OK