TOGAF and the ADM

TOGAF is an enterprise architecture framework published by The Open Group. It gives organizations a common method, vocabulary and set of deliverables for planning how their business processes, data, applications and technology should change over time.

Its centerpiece is the Architecture Development Method (ADM), an iterative cycle for developing and governing enterprise architecture.

Diagram

flowchart LR
    p[Preliminary] --> a["Vision<br/>(phase A)"]
    a --> bcd["Architectures<br/>business, data and<br/>applications, technology<br/>(phases B to D)"]
    bcd --> ef["Plan the change<br/>(phases E and F)"]
    ef --> gh["Govern and adapt<br/>(phases G and H)"]
    gh -- next cycle --> a

Requirements management sits at the center of the cycle and feeds every phase.

How it works

• Preliminary phase. Set up the architecture capability: principles, governance and how the framework will be tailored.
• Phase A, architecture vision. Agree scope, stakeholders and the high-level target with sponsors.
• Phases B, C and D. Describe the current (baseline) and target architectures for business, information systems (data and applications) and technology, and identify the gaps.
• Phases E and F. Group the changes into projects and plan the migration roadmap.
• Phase G. Govern implementation to keep projects aligned with the target architecture.
• Phase H. Manage changes to the architecture as the business changes.
• Requirements management sits at the center and feeds every phase.

TOGAF also defines a content framework (standard deliverables and artifacts), an enterprise continuum for classifying reusable assets, and guidance on architecture governance.

Pros

• Widely recognized: a common language across organizations, consultancies and job descriptions.
• Comprehensive: covers business, data, application and technology in one method.
• Tailorable: designed to be adapted, not followed literally.

Cons

• Heavy if applied literally: producing every artifact can turn architecture into paperwork.
• Abstract: gives a method, not concrete design answers.
• Can feel slow next to agile delivery if not tailored.

When to use it

• Large organizations planning multi-year transformation across many systems.
• Establishing an enterprise architecture practice and its governance.
• When a shared, recognized vocabulary with partners and consultancies is valuable.

When to avoid it

• Small organizations or single-product companies, where lightweight decision records and roadmaps are enough.
• As a substitute for hands-on solution design.

Common pitfalls

• Following every phase and artifact by the book instead of tailoring.
• Architecture disconnected from delivery, producing documents that projects ignore.
• Skipping the business architecture and jumping straight to technology.

Related pages

• Enterprise architecture overview
• Certifications, including TOGAF and ArchiMate
• Developer to architect roadmap

Further reading

• The TOGAF Standard (The Open Group, opengroup.org)
• ArchiMate Specification (The Open Group)