TOGAF overview: the Architecture Development Method cycle

What TOGAF is

TOGAF (The Open Group Architecture Framework) is a vendor-neutral framework for developing and governing enterprise architecture. It is maintained by The Open Group; the current edition is the TOGAF Standard, 10th Edition, which splits content into a stable fundamental core and a library of optional guidance. Certification is common for architects and appears in many job adverts.

TOGAF has several parts: the ADM method, guidance on content and artefacts, the idea of an architecture repository to store work, and advice on governance and capability. The ADM is the part most people mean when they say "we use TOGAF".

The ADM cycle

Requirements management sits in the middle of the cycle. Requirements are captured and checked in every phase, not just at the start.

Key ideas to remember

• Iteration: you can loop between phases (for example B, C and D) and run several ADM cycles at different levels, from whole enterprise to a single programme.
• Architecture principles: short agreed rules such as "data is an asset with a named owner" or "prefer cloud services before building our own".
• Building blocks: reusable components. Architecture Building Blocks describe what is needed; Solution Building Blocks describe the actual products.
• Enterprise Continuum: a way of classifying architecture assets from generic (industry-wide) to specific (your organisation).

Using TOGAF in practice

Critics say TOGAF can become heavy and document-driven. The framework itself says it should be tailored. A small team might use only Phases A to F informally, with one-page artefacts. Modern teams often combine the ADM with agile delivery: architecture sets the direction and guardrails, while product teams deliver in short iterations.

Tip: for exams, memorise the phase letters and names in order (Preliminary, then A to H) and remember that requirements management is central. For work, focus on the vision, gap analysis and migration planning, which give the most value.

Example: a college moving its student records system to the cloud would agree the vision and stakeholders (A), model enrolment and assessment processes (B), map the data and integrations (C), design the network and identity platform (D), group the work into projects (E), sequence them around term dates (F), review each project for compliance (G), and later revisit the design when regulations change (H).