TOGAF ADM is base of DBJ ADM
Togaf ADM and a subset of its deliverables
The TOGAF ADM driven project (we also call it “wheel”, as in steering wheel) produces architecture artifacts — documented decisions, not deployed systems. It is one of the central parts of the TOGAF. It is intended as a tool for Enterprise Architecture teams producing the numerous carefully classified deliverables: diagrams, lists, tables, documents. All unified with common non trivial templates. Color coordinated and graphically synchronized.
Specifically subset of most important deliverables is classified as: principles, vision, architecture definitions (business, information systems, technology), roadmaps, migration plans, and governance reports.
The ADM wheel authorizes delivery.
DBJ ADM
The DBJ ADM is a (much) simplified version of the TOGAF ADM, adapted for business to use in projects following the DBJ Method. It retains the circular metaphor while reducing the nine TOGAF steps to five, with Requirements Management at the hub. This document describes the structural logic of one DBJ ADM wheel.
Each step sits at a level of abstraction in the DBJ Taxonomy.
| DBJ ADM | Level of Abstraction (DBJ Taxonomy) |
|---|---|
| Strategy & Motivation | Conceptual |
| Business | Conceptual |
| Application | Logical |
| Technology | Physical |
| Implementation | Implementation |
The DBJ ADM outputs are always architectural: decisions, principles, constraints, blueprints. Never deployed systems or running code. Delivery is what the wheel guides.
DBJ ADM deliverables
Every step of the DBJ ADM is expected to produce deliverables: formal documents, diagrams, or catalogs that record decisions and evidence for review. They are not bureaucracy for its own sake. They exist because verbal agreements disappear; written artifacts persist, can be audited, and can be handed to the next team or the next review cycle.
Why deliverables? Without them, governance has no object to review. The Architecture & Business Board cannot approve or reject a verbal description. Deliverables are what the board reads.
What kinds of deliverables exist? TOGAF names many: Principles Catalogs, Capability Maps, Application Portfolio Catalogs, Interface Catalogs, Technology Standards Catalogs, Roadmaps, and more. Each is a structured document that captures a specific slice of the architecture. Only five are mandatory as presented in that table. Others are optional.
Which deliverables are required? The rule is: produce what is needed to answer the business or governance questions at that ADM step. Each DBJ ADM wheel calls out the five required artifacts, one per step.
What do they belong to? A deliverable is part of the project that develops a Product. The Product is the unit (the item) whose development the DBJ Taxonomy classifies. The deliverables are classified, and all of them point to the same Product. Each is written in the context of the domain it resides in. For example, a software product has a Conceptual, a Logical, a Physical and an Implementation architecture.
Who produces them? The project team roles: architects, tech leads, product owners, and engineers; depending on the project location inside the BPT domain.
Minimal set of deliverables per one DBJ ADM Wheel
Each step produces exactly one document, named the same as the step.
| ADM Step | Document | Description |
|---|---|---|
| Strategy & Motivation | Strategy & Motivation | Constraints and non-negotiables that govern the entire wheel |
| Business | Business | Business case, scope, and stakeholder sign-off |
| Application | Application | Logical architecture: information systems and their interfaces |
| Technology | Technology | Physical architecture: infrastructure, platforms, and deployment topology |
| Implementation | Implementation | Approved path forward, sequencing, cost, and governance sign-off |
They have to be created, however insignificant they look in that iteration. In the next they will become much more prominent.
ADM Iterations
ADM is live and lively activity. Different roles are managing different deliverable. Is ADM step depending on previous or not does not matter, it just has to be revisited in each turn.
The wheel turns more than once. Each full turn is a cycle, and the cycle number is the document version’s whole-number part — not a free-running document revision count.
- 0.1 → 0.9 — drafts before the wheel has completed its first turn. Nothing is authorized yet.
- 1.0 — the first cycle closes: all five deliverables exist, reviewed, governance-signed.
- 1.1 → 1.9 — corrections and clarifications inside cycle 1, no re-authorization.
- 2.0 — the second cycle closes. And so on.
Of course sub version numbers do not have to be single digits. A document’s version number always names the cycle that produced it.
The five deliverables are sequential. Documents can be updated out of sync, but the iteration can not be closed if any of them is not signed off by the project.
The Visual
Not exact but very helpful. Keep in mind that efforts delivered by each role do not have to be equal at each iteration.
For example: the project manager will deliver the full plan at the last or close to the last iteration, while the business role will spend most of the effort in the opening iterations.