From ADM Artifacts to a Published Architecture Register

The ADM organises work, not readers

A repository built by following the ADM ends up structured by phase: Preliminary, Vision, Business, Data, Application, Technology, Opportunities, Migration, Governance, Change. That structure is a good record of how the architecture was developed and a poor front door for anyone who was not involved in developing it.

A delivery lead does not want Phase C. They want to know what an application depends on. A risk officer does not want Phase D. They want the controls that apply to a system. Publishing the ADM structure as the primary navigation asks every reader to learn TOGAF first.

Keep the structure, change the entrance

The resolution is not to restructure the repository. The phase-based package tree is genuinely useful for the architecture team, it maps to how the work is governed, and rearranging it would break more than it fixes.

Instead, publish the tree as a secondary navigation — available, browsable, not the front door — and lead with perspectives organised around reader questions. The same elements appear in both. Only the entry point changes.

Which artifacts publish well

The artifacts that do not survive publication

Some ADM outputs are working artifacts and should stay that way. Stakeholder maps with named individuals and their concerns, communications plans, the architecture contract's commercial terms. These were produced for the programme, not for a standing audience, and publishing them widely creates awkwardness without creating value.

A useful filter: would this artifact still be meaningful to someone reading it eighteen months from now, out of the context in which it was produced? If not, it belongs in the repository but not in the publication.

Traceability is the differentiator

The single thing a published ADM repository can do that a set of documents cannot is show the chain: driver to goal to requirement to component to verification.

This is what makes the difference between a portal that looks like a documentation site and one that demonstrably supports governance. It also exposes the breaks, which is uncomfortable and useful — a requirement with no verification case is visible to everyone the moment it is published.

Start with three artifacts

The capability map, the application catalogue, and one traceability matrix. Publish those three well — properly tagged, searchable, dated — before attempting the whole repository.

A portal containing three things people use beats a complete one nobody navigates, and the feedback from those three will tell you what the fourth should be far more reliably than the ADM will.

Handling ADM iterations

The ADM is iterative, which creates a publication question the phase structure does not answer: when the same artefact exists for three iterations, which one does the reader see?

Publishing all of them produces a portal where every question has three answers and the reader has to know your programme history to pick. Publishing only the latest loses the ability to see what changed, which is often the point.

What works: publish the current baseline as the primary content, and keep prior publications as dated archives. The reader gets one answer by default and can reach the history deliberately. This is the same mechanism as retention, doing a second job.

Governance artifacts deserve better than a list

Architecture decisions are the most under-published artefact in most repositories, and the reason is that they get published as a list of decisions.

Nobody reads a list of decisions. What people need is to arrive at an element, notice that a decision applies to it, and read that one. That means decisions have to be linked from the elements they affect — which requires the relationship to be modelled, which is the actual work.

Where that link exists, published decisions get read constantly. Where it does not, they get published and ignored, and the conclusion drawn is that nobody cares about architecture decisions rather than that nobody could find them.

Who reads a register, and what they open first

An ADM cycle produces artifacts for the people doing the cycle. A register is read by people who were not in the room, arriving with a specific question and no patience for phase structure.

Three of those four are answered by structure rather than by content. The register that works is not the one with more artifacts in it.

Building the register incrementally through the cycle

The instinct is to publish at the end of a phase, which produces a register that is either empty or stale for most of the year. Publishing continuously and marking status is better, and it costs almost nothing once the pipeline exists.

What makes it safe is a status property on everything published: draft, under review, approved, superseded. A reader who can see that an artifact is draft will treat it as draft. A reader who finds nothing at all goes and asks an architect, which is the cost you were trying to avoid.

The one thing not to publish continuously is anything with a commercial or personnel implication before it is decided — a rationalisation candidate list, for instance, reads very differently to the team that owns the system on it.

Mapping ADM deliverables onto register objects

Much of the friction here is that ADM deliverables are documents and a register holds objects. The mapping is mostly mechanical once stated.

• Architecture Vision becomes a landing page with drivers, goals and scope as motivation elements — not a PDF link.
• Architecture Definition Document dissolves. Its content is the model; publishing the document alongside the model guarantees they will disagree within a quarter.
• Architecture Requirements Specification becomes requirement objects with realisation relationships. This is where traceability comes from and it is worth the effort.
• Architecture Roadmap and Transition Architectures become baselines with dates, which is what they always were.
• Architecture Contract stays a document. It is a signed agreement between parties and modelling it adds nothing.

The general rule: if two people would need to agree on its exact wording, keep it a document. If people need to query it, make it objects.

What TOGAF does not tell you to do

The ADM is deliberately silent on publication, which teams read as permission to skip it. It is worth naming the three decisions the framework leaves entirely to you, because they determine whether the register is used.

1. Cadence. Nothing in the ADM says how often the register regenerates. Monthly is a defensible default; anything slower and readers learn not to trust it.
2. Audience scoping. The framework has viewpoints and stakeholders, but no notion of who may see what. That is an authorization decision and it has to be made outside the method.
3. Retirement. The ADM is a cycle with no instruction for removing what a previous cycle produced. Without one the register accumulates superseded artifacts until search becomes useless.

The register outlives the engagement

Most ADM cycles are run by a team that will be reassigned. Consultants leave, programmes close, the architect who understood the whole picture moves to another division. What remains is whatever was written down in a form someone else can use.

This is the strongest practical argument for publishing a register rather than filing deliverables, and it is worth making explicitly to whoever funds the cycle. A set of documents in a shared drive has a half-life of about eighteen months: not because the files disappear but because nobody remembers which of the four versions was the approved one, and the person who could have said is gone.

A register with baselines, decision references and traceable relationships survives that turnover, because the questions it answers do not depend on institutional memory. Someone arriving two years later can find what was approved, when, by whom, and what changed since — without needing to have been there.

The cost of building it that way is almost entirely front-loaded into conventions: naming, mandatory properties, and the discipline of recording decisions against objects rather than in minutes. None of that is expensive during the cycle. All of it is impossible to retrofit afterwards.

Requirements traceability, and where it usually breaks

Traceability is the part of the ADM that publishes best and is hardest to sustain. The chain from a driver, through a goal, to a requirement, to the application component that realises it, is genuinely valuable and genuinely fragile.

It breaks in three predictable places. The first is at the requirement boundary, where architecture requirements are captured in the model and delivery requirements live in a separate tool, and nobody links them — so the chain runs cleanly from driver to architecture requirement and then stops just before anything was built. The second is at retirement: a component is decommissioned, the realisation relationship goes with it, and a requirement is silently left with nothing implementing it. The third is at refactoring, where one component becomes three and the original relationship is redrawn to whichever of the three seemed closest.

Each has a cheap detection: requirements with no realisation, requirements whose realising element was deleted, and relationships changed without an accompanying decision record. None of them is worth a workflow. All three are worth a monthly report that goes to one person.

Publishing decisions, not just structures

Registers overwhelmingly publish the what — elements, relationships, layers — and omit the why. Six months later the why is the only thing anyone wants, and it is in a minute nobody can find.

Architecture decision records solve this and are usually kept somewhere else, which defeats the purpose. A decision that lives in a wiki is a decision that will not be found by someone looking at the element it constrains. The decision should be an object in the register, related to the elements it affects, so that opening any component shows what was decided about it.

What a published decision needs is short: the question, the options considered, the choice, and the consequence accepted. The consequence field is the one that earns its keep — it is where you write down what you knowingly gave up, and it is what stops a future team relitigating a trade-off that was made deliberately.

Decisions also need a status. A superseded decision must remain readable, because understanding why the current architecture looks the way it does often requires reading the decision that was later reversed. Deleting them is the one mistake that cannot be undone.

The register's first review meeting

The register proves itself not at launch but the first time a governance body uses it live, and that meeting is worth engineering rather than awaiting. Pick a forthcoming architecture board, and instead of the usual pre-circulated deck, send links: the three artifacts on the agenda, in the register, as they will be discussed.

The meeting runs differently in ways the attendees will name afterwards. Questions get answered by clicking rather than by promising follow-ups — what depends on this platform, when was this principle last revised, which requirements does this building block satisfy — each a traceability link that used to be an action item. The perennial "is this the latest version" evaporates, because the register's version is the version, dated on the page. And decisions land somewhere: the approval minuted in the meeting becomes a named baseline the same afternoon, linked from the register, which means the next meeting starts from recorded state instead of from reconstructed memory.

Expect one uncomfortable discovery: live navigation exposes gaps that decks concealed. The dependency view with a hole in it, the artifact whose owner field is blank, the requirement tracing to nothing — visible to the whole board, in real time. Resist the instinct to curate around these; they are the register doing governance's actual work, which was never to present architecture attractively but to make its true state undeniable. A board that has once seen the gaps live will not go back to decks, and that ratchet — more than any mandate — is what makes the register the ADM's public face permanently. One well-chosen meeting converts it from a publication the architects built into a venue the governance runs in, and venues, unlike documents, get defended by their occupants.

The ADM gives a practice its working rhythm; the register gives that work an audience. Keep the method's structure for the architects, build the reader's entrance for everyone else, and the framework's most persistent criticism — that it produces documents nobody reads — quietly stops being true in your organisation. The artifacts were always worth reading; the register is simply the first time they were published as if that mattered.

Method and register, in the end, need each other: the ADM without publication produces rigour nobody benefits from, and a register without the ADM's discipline publishes noise attractively. Run them as one system and each covers the other's classic weakness.