TOGAF 9 Architecture Development (ADM) Cycle - The Easy Way

Introduction to TOGAF and the ADM Cycle

Hello and welcome to the TOGAF 9 Architecture Development Cycle Quick Reference Guide. In this session, you'll get a clear, easy-to-understand overview of the important activities performed in each phase of the ADM.

Let's start by understanding exactly what TOGAF is.

What is TOGAF?

The term TOGAF stands for The Open Group Architecture Framework. It is the de-facto global standard for Enterprise Architecture, and any enterprise organization can use it freely.

TOGAF provides a comprehensive set of tools, vocabulary, and a step-by-step method to build an Enterprise Architecture (EA).

It was initially developed in 1995, based heavily on the Technical Architecture Framework for Information Management (TAFIM), which was created by the US Department of Defense (DoD). Today, The Open Group consortium continually develops and maintains TOGAF.

The TOGAF ADM Cycle Overview

The Architecture Development Method (ADM) is the beating heart of TOGAF. It describes a proven method for developing and managing the lifecycle of enterprise architecture.

The ADM cycle is a combination of ten separate, distinct phases. Each ADM phase integrates various architectural assets to ensure the IT landscape perfectly aligns with the business goals of the organization.

Let's break down the objective and the crucial activities performed in each phase.

Preliminary Phase

The very first step of the TOGAF ADM cycle is the Preliminary Phase. You can think of this as the "preparation" phase. The objective here is to determine and establish the architecture capability desired by the organization before any actual architecture design begins.

Key activities performed:

Prepare the organization for successful TOGAF architecture projects.
Define what "Architecture" means to this specific enterprise.
Customize the TOGAF framework to fit the organization's specific needs.
Select the tools that will be used.
Define the core Architecture Principles.

Phase A: Architecture Vision

Once the organization is prepared, we move to Phase A: Architecture Vision. The primary objective is to define the scope, identify the stakeholders, create the architecture vision, and obtain approvals to proceed.

Key activities performed:

Set the scope, constraints, and expectations for the project.
Identify key stakeholders and their primary concerns.
Create an Architecture Vision Document.
Validate the business context and create the Statement of Architecture Work.
Obtain formal approvals to move to the next phase.

Phase B: Business Architecture

Phase B focuses on the development of the Business Architecture. This demonstrates how the business will realistically operate to achieve the vision defined in Phase A.

In practical terms, this phase is crucial for demonstrating the business value of the subsequent architecture work to key stakeholders.

Key activities performed:

Select reference models, viewpoints, and tools.
Define the Baseline (Current State) Business Architecture.
Define the Target (Future State) Business Architecture.
Perform a gap analysis between the baseline and target.
Create the Architecture Definition Document.

Phase C: Information Systems Architectures

Phase C is actually a combination of two distinct architectures: Data Architecture and Application Architecture. It describes how the Information Systems will allow the Business Architecture to function.

It describes the fundamental organization of an IT system by defining:

The major types of information and the applications that process them.
The relationships between these applications and the environment.
The principles governing their design and future evolution.

Phase D: Technology Architecture

With the Business, Data, and Application architectures defined, Phase D focuses on the Technology Architecture. This is the physical and logical infrastructure required to run the applications.

Technology Architecture describes:

Hardware, software, and communications networks (servers, cloud infrastructure, routers).
The relationships between these physical/virtual components.
The guiding principles for technology selection.

By the end of Phase D, the logical blueprint of the Target Enterprise Architecture is complete.

Phase E: Opportunities and Solutions

In Phase E, the focus shifts from design to delivery. The goal is to identify the delivery vehicles (projects, programs, or portfolios) that will actually build the Target Architecture.

Key activities performed:

Consolidate and prioritize the gaps found in Phases B, C, and D.
Group the gaps according to their dependencies to form major implementation projects.
Determine if a single "Big Bang" implementation is possible, or if an incremental approach (using Transition Architectures) is required.
Assess priorities and schedule projects based on business value and urgency.

Phase F: Migration Planning

Working closely with portfolio and project managers, Phase F addresses exactly how to move from the Baseline to the Target Architecture by finalizing a detailed Implementation and Migration Plan.

Key activities performed:

Cost/Benefit Analysis: Assess the business value of every proposed project.
Risk Assessment: Identify which projects carry high risk and plan mitigation strategies.
Prioritize projects based on value and risk, locking them into the migration plan.
Conclude transition planning.

Phase G: Implementation Governance

In Phase G, the implementation projects are formally kicked off. The role of the enterprise architect shifts from designer to overseer. The architecture team provides governance to ensure the build teams don't deviate from the blueprint.

Key activities performed:

Provide architectural oversight for the implementation teams.
Prepare and issue Architecture Contracts.
Ensure that the final implemented systems actually conform to the Target Architecture designed in Phases B, C, and D.

Phase H: Architecture Change Management

Even after a system is deployed, the world continues to change. Phase H establishes procedures for managing changes to the new architecture over time.

Key activities performed:

Continuously monitor requests for governance, new technology developments, and changes in the business environment.
Determine if a change is small (requiring a simple patch) or large (requiring a completely new cycle of the ADM to be initiated).
Ensure the architecture continues to maximize business value.

Requirements Management (The Center of the ADM)

If you look at diagrams of the ADM, you will notice Requirements Management sitting directly in the center of the cycle.

This indicates that the ADM is continuously driven by requirements. It is a dynamic process—requirements are identified, stored, fed into, and fed out of every single phase of the ADM constantly. Every stage of a TOGAF project must validate and address business requirements.

Summary

The Architecture Development Method (ADM) forms the absolute core of TOGAF. It provides a proven, repeatable 10-step method for deriving an organization-specific Enterprise Architecture.

By following the ADM, organizations ensure that their massive IT investments directly support and enable their strategic business goals.