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 is based on the TOGAF ADM
The DBJ ADM reduces the nine TOGAF ADM steps to five. Each step produces at least one written artifact. Business following the DBJ ADM, reviews artifacts, not conversations.
There is of course implied mapping to DBJ Taxonomy.
| DBJ ADM | Level of Abstraction (DBJ Taxonomy) |
|---|---|
| Strategy & Motivation | Conceptual |
| Business Layer | Conceptual |
| Application Layer | Logical |
| Technology Layer | Physical |
| Implementation & Migration | 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
The DBJ ADM is (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 step count to what a real organization can sustain; perhaps without a dedicated architecture team.
With the organization at the CMM Level 3 or above, ensuring the organization capability to “follow the ADM motion”.
This document describes the structural logic of an DBJ ADM wheel.
The DBJ ADM wheel produces much distilled architecture artifacts v.s. TOGAF. The wheel authorizes delivery.
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 ADM step. Each DBJ ADM wheel calls out the minimum 5 required artifact at each step.
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 Layer | Business Layer | Business case, scope, and stakeholder sign-off |
| Application Layer | Application Layer | Logical architecture: information systems and their interfaces |
| Technology Layer | Technology Layer | Physical architecture: infrastructure, platforms, and deployment topology |
| Implementation & Migration | Implementation & Migration | Approved path forward, sequencing, cost, and governance sign-off |
Five deliverables are sequential.But can be updated out of sync. 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.
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.
A document’s version number always names the cycle that produced it.
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: project manager will deliver the full plan at the last or close to the last iteration. While the business role will sped most of the effort in opening iterations.