TOGAF Is Not Just the ADM
A 2,500-person logistics company has just appointed a Head of Architecture. The CIO has funded a 'TOGAF programme' that, in practice, means running Phases B, C and D for the order-to-cash domain. There is no Architecture Board, no endorsed architecture principles and no shared repository; models live in personal Visio files and are circulated as PDFs. Eight weeks in, the Phase B business architecture is rejected by the sales director, who says nobody agreed the scope with him. The CTO separately asks why none of the target architecture work connects to the annual budget and investment cycle. The team has spent roughly £400k and has a fixed six-month deadline. The Head of Architecture must decide whether to restart, continue, or treat the current work as input to a short re-launch.
1. The CIO treats TOGAF as synonymous with the ADM. Take the three symptoms - a scope the sales director disputes, models living in personal files, and no connection to the investment cycle - and say which part of the framework would have prevented each, and by what mechanism.
Read the worked answer
Disputed scope. The ADM's Phase A output is a Statement of Architecture Work agreed with and signed by the sponsoring stakeholder, plus an Architecture Vision and a stakeholder map. Underneath it, the Preliminary Phase establishes architecture principles and the Architecture Board, which give someone the authority to arbitrate when two executives disagree. Here scope was never a negotiated artefact owned by the sales director, so it was always contestable. The ADM Guidelines and Techniques on stakeholder management and business scenarios are the practical mechanism for getting that agreement.
Personal Visio files. The Architecture Content Framework defines the deliverables, artefacts and building blocks a phase must produce, and the Enterprise Continuum and Architecture Repository give a governed place to keep them - the Architecture Landscape, Reference Library and Standards Information Base. Without those, every model is a private artefact and reuse is impossible.
No link to the budget. Architecture Governance - the Board, architecture contracts and compliance reviews - is the bridge between the architecture and the investment cycle. In TOGAF terms the target architecture has no route into portfolio decisions because there is no governance body receiving it.
The ADM is a method; it assumes the surrounding capability, content and governance structures exist. Running B–D in isolation is the ADM stripped of the parts that make its outputs binding.
2. Restart from the Preliminary Phase and Phase A, or carry on into Phase C? Argue both and give a decision with the criteria you would use.
Read the worked answer
For continuing: £400k is sunk, architecture capacity is scarce, and a formal restart looks like failure to the CIO who funded it. Some Phase B work is probably reusable, and restarting risks another eight weeks of process with nothing to show.
For restarting: the failure is not in the content, it is in the mandate. No agreed scope, no engaged sponsor, no principles and no governance mean Phase C will produce application and data architectures that the sales director can reject for exactly the same reason. Continuing compounds an unbounded risk: every downstream phase inherits an unvalidated baseline.
Criteria to decide: (1) Is there a named, engaged sponsor with authority over order-to-cash? (2) Is there any agreed statement of scope and success criteria? (3) Is the existing Phase B work usable as a baseline description? (4) What does rework cost if the business architecture is rejected again?
Likely decision: a time-boxed re-launch of about four weeks - a focused Preliminary (principles, Board, request for architecture work) and Phase A (vision, stakeholder map, Statement of Architecture Work) that reuses the existing business models as input to describing the baseline. That restarts the governance, not the content. Continuing into Phase C without it is the higher-risk option, deadline or not.
3. A colleague tells the CIO: 'we are doing TOGAF, therefore we have an architecture.' Untangle that for the CIO - distinguish architecture, architecture description and architecture framework, and say what this organisation actually has today.
Read the worked answer
The three terms answer different questions and the funding conversation depends on keeping them apart.
Architecture is the fundamental organisation of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. It is a property of the enterprise, not a document.
Architecture description is the work product - models, catalogues, matrices, diagrams - that expresses an architecture for a purpose. It can be good or bad, current or stale.
Architecture framework is a structure for organising the content of an architecture description; TOGAF is one. Adopting a framework says nothing about whether the architecture has been described, agreed or is being used.
Applied here: the company has partially adopted a framework and has some architecture descriptions of variable quality, produced without agreed scope. It does not have a validated target architecture, nor agreement that any description represents the enterprise. The practical consequence for the CIO is that the next spend buys two different things: capability and governance to make descriptions authoritative, and content to describe the target state. Funding only the second will reproduce the current failure.