Working in a TOGAF/ArchiMate shop

The worked example showed the product of an enterprise-architecture practice — one decision traced from goal to cloud to roadmap. This page is about the practice itself: how a real team operates the model day to day. How the diagrams stay honest, who is allowed to change them, how the work is sequenced through the ADM, and — the core skill — how one model serves many stakeholders through different views.

Everything here is exactly what this very section does. The Cadence Cycles model is one source-controlled .archimate file plus a set of jArchi view scripts; the sixteen diagrams you have seen are all regenerated from that source. So this page doubles as the method behind its own diagrams.

The one idea to take away

An architecture practice is not a diagramming habit; it is the discipline of keeping one model true, governed, and readable by whoever needs it. Tools and notation are in service of that. When a practice fails, it is almost never because the notation was wrong — it is because the model drifted from reality, or nobody could find the one view they needed.

The architecture repository — one model, many views

The heart of the practice is the architecture repository: the single, governed store of the model, its views, and the standards around it. TOGAF calls this the Enterprise Continuum and the Architecture Repository; in day-to-day terms it is "where the truth lives and how you change it."

The non-negotiable rule is one model, many views. There is exactly one set of elements — one Ecommerce capability, one Online Purchase service, one Cloud Platform node — and every diagram is a view that selects and arranges a subset of them. A view never owns an element; it borrows it. That is what makes the layered view trustworthy: change the OMS component once and every view that shows it is correct, because they all point at the same element.

This section is a working example of the repository pattern

• The model is archi/cadence-cycles.archimate — one file, ~127 elements, diff-able in git.
• The views are archi/views/*.ajs — one jArchi script per diagram, which looks up elements by (type, name) and lays them out; the scripts never create or mutate model elements.
• seed.ajs is the sole writer of the model; every other script is read-only against it.
• The SVGs under img/ are build outputs, regenerated by render-all.sh.

Baseline vs target lives in the model too: the two plateaus on the roadmap — Current state (siloed channels) and Target state (omnichannel) — are the baseline and target architectures TOGAF's ADM moves between, recorded as first-class elements rather than two folders of stale slides.

Alongside the model sits the reference & standards library: the architecture principles (Single source of truth for inventory, Buy-anywhere / fulfil- anywhere), the approved patterns, and the technology standards that new work is held to. In the model these are real Motivation-layer elements, so a design can be traced to the principle it honours — or caught violating one.

Governance — how a change enters the model

A repository without governance rots. Architecture governance is the set of controls that decides what is allowed into the model and keeps designs aligned with the principles.

• The Architecture Board. A standing body (for Cadence: the enterprise architect, the VP Ecommerce, the Head of Ops, and a security lead) that owns the target architecture and the principles, and reviews significant changes. It is the human counterpart of "one model": it stops three teams quietly forking reality.
• Design reviews. Every significant project passes its design against the target architecture and principles before build. The layered view is the review aid: it makes "does this honour Buy-anywhere / fulfil-anywhere?" a question you can answer by tracing edges, not by debating opinions.
• Dispensations / waivers. Reality intrudes; sometimes a project must deviate. A waiver is a governed, time-boxed, recorded exception — "the OMS will call the ERP directly this quarter, revisited at GA" — not a silent divergence. The waiver register is itself part of the repository.
• Principles as guardrails. Principles are not decoration; they are the pre- agreed tie-breakers. When two designs compete, the one that better serves the principles wins — and because the principles are modelled, that argument is auditable.

The governance test

A healthy practice can answer, for any element in the model, who approved it, which principle it serves, and which goal it traces to. If it cannot, the governance is theatre and the model will drift.

ADM iterations — you don't do A→H once

The TOGAF ADM is drawn as a cycle for a reason: you iterate it, you do not run it once end-to-end. A mature shop runs several concurrent cadences at different altitudes:

• A strategic/capability iteration sets direction across the enterprise — the capability map and heat map, the target architecture, the roadmap. Cadence runs this roughly annually; it is where Grow D2C online revenue to 30% and the three courses of action were set.
• Per-project iterations take one slice through Phases B–D–E–F at delivery altitude. Each of the roadmap's work packages — Build D2C storefront, Unify inventory service, Roll out BOPIS — is its own trip through the ADM, inheriting the target architecture from the strategic iteration above it.
• Capability increments. The programme delivers the target state in plateaus, not one big bang. Each plateau is a coherent, releasable increment of the architecture — which is exactly what the roadmap's two plateaus and their deliverables encode.

So the omnichannel programme maps cleanly onto the method: one capability-level iteration produced the roadmap; three project-level iterations deliver its work packages; and Requirements Management sits at the hub throughout, because the requirements (real-time inventory, BOPIS, unified profile) are the throughline every iteration is held to.

Stakeholder viewpoints — same model, different views

Here is the skill that separates architects from diagrammers. Every stakeholder needs a different picture of the same model. A viewpoint is a reusable template — "for this audience, show these element types, at this altitude, to answer these concerns" — and a view is that template applied to the model.

Stakeholder	Their concern	The view they get	Viewpoint
Board / CEO	Is the bet coherent, and is it funded sensibly?	Layered view + roadmap	Strategy & motivation, low detail
VP Ecommerce	Which capabilities decide whether I hit the number?	Capability heat map + value-stream cross-map	Capability / value-stream
Head of Ops	What actually runs, and what breaks if a node dies?	Application-usage + infrastructure-usage	Application & technology usage
Enterprise Architect	Is the whole model consistent end to end?	The full model + every view	Everything
Security / Risk	Where does customer data live and flow?	Application cooperation + data-object access	Information-structure
Delivery / PMO	What are we building, in what order?	The roadmap — work packages & deliverables	Implementation & migration

The trick is that none of these are separate models. They are all views onto the one Cadence Cycles model — which is why the VP Ecommerce's heat map and the architect's layered view can never disagree about whether Order Fulfilment is hot: there is only one Order Fulfilment element, and both views point at it.

Same model, three viewpoints

The clearest way to feel this is to put three views of the same model side by side. Each answers a different stakeholder's question; each is a slice of the identical element set.

One model, three viewpoints. Left, for the Board — the Motivation view answers "why, and against what number?" Centre, for the Head of Ops — the application-usage view answers "what runs the promise, and what breaks if it fails?" Right, for the VP Ecommerce — the heat map answers "where do we invest first?" Same elements underneath; three audiences served without a single contradiction between the pictures.

Tooling — keep the diagrams regenerable from source

Good tooling is what makes "one model, many views" survive contact with a real team.

• Archi — the free, open-source ArchiMate modelling tool (the whole model here is an Archi .archimate file). It is the canonical editor for the repository.
• jArchi scripting — Archi's scripting extension. Every view in this section is a committed jArchi (.ajs) script that builds the diagram deterministically, so layout is code, reviewed and diffed like any other source, not dragged by hand.
• Model exchange (Open Exchange XML) — the ArchiMate standard interchange format. It is how a model moves between tools (Archi, a commercial repository, a documentation pipeline) without lock-in — the same instinct as keeping the model in a plain, portable file.
• Regenerable diagrams. The reproducible pipeline this section runs is the whole discipline in miniature: render-all.sh runs Archi headless and re-exports every SVG from the committed source, so a diagram can never quietly drift from the model it claims to show. If the picture and the model disagree, you regenerate; you never touch the SVG by hand.

The pipeline is the point

A diagram you can regenerate from source is a diagram you can trust. Hand-drawn boxes rot the moment the model changes; a rendered view is always current by construction. That is why this section committed jArchi scripts, not PNGs of a whiteboard.

Anti-patterns — how EA practices actually fail

Most failed enterprise-architecture efforts fail the same handful of ways. Name them so you can catch them early.

• Diagram sprawl. Hundreds of unrelated diagrams and no single model beneath them. The cure is the repository rule: every diagram is a view onto one model, or it does not belong.
• Model-vs-reality drift. The model describes a system that no longer exists. The cure is governance (changes flow through the repository) plus regenerable views (the model is close to the code that runs). A model nobody trusts is worse than no model.
• Boiling the ocean. Trying to model the entire enterprise to full depth before delivering any value. The cure is capability increments and plateaus: model the slice the next decision needs, ship it, iterate.
• Notation pedantry over decisions. Arguing whether an arrow is serving or realisation while the roadmap goes unfunded. Notation exists to make decisions precise, not to be the deliverable. Correct notation in service of a decision; never correctness for its own sake.
• One-view-fits-all. Showing the Board the full model, or the architect a cartoon. The cure is viewpoints: match the view to the stakeholder's concern and altitude, every time.

So what — the practice in one line

A working TOGAF/ArchiMate shop keeps one governed model, delivers it in plateaus through iterated ADM cycles, serves every stakeholder a fit-for-purpose view of it, and keeps every diagram regenerable from source — so the architecture is always something you can trust, not just something you can draw.

Where to go next

• Worked example — the model this page operates, walked from goal to roadmap.
• TOGAF & the ADM — the method the iterations above cycle through.
• Overview — the notation legend and the Cadence Cycles intro, if you are arriving here first.
• Capability heat-maps — the analysis a capability-level ADM iteration produces.