The decision that kept being made
The client was a research organisation — a network of institutes sharing a central IT function, with an architecture group of about eight people serving projects that ranged from laboratory instrument integration to long-running data platforms. The engagement traces back to a single meeting the head of architecture described to us with some weariness: the third time in two years the organisation had debated, at length and from first principles, whether institute data platforms should standardise on a shared storage service. The decision had been made twice before. Nobody in the room could produce either decision, and one participant had been present at both.
Everyone recognises this meeting. Decisions had been recorded, in the sense that minutes existed somewhere and slide decks summarised outcomes for steering groups. What did not exist was any way to encounter a decision at the moment it mattered — which is not when someone searches the minutes archive, but when an architect is looking at the affected part of the estate and about to change it. The organisation already maintained its architecture in Sparx EA. The ask was to make decisions part of that model: linked to their options, their rationale, their approvals and, above all, to the elements they affect, so that a decision would be found by the people standing where its impact lands.
Where the decisions actually lived
We began with an inventory of how deciding actually worked, and found four parallel habits. Steering-level decisions lived in minutes, well written but filed by meeting date, which is the one attribute nobody remembers. One software team had adopted architecture decision records in its Git repository — the best-kept log in the organisation, and invisible to everyone outside that team. The architecture group's own decisions lived in slide decks whose filenames ended in version numbers and adjectives. And a fourth category, the most consequential, lived nowhere: precedents everyone operated by which had never been written down at all, discovered only when a newcomer innocently violated one.
The repository itself was in decent condition — the estate modelled, ownership recorded, diagrams maintained. Reading it, however, told you what the architecture was but never why. A retired integration pattern sat alongside its replacement with nothing to say which one represented policy. The model described a landscape shaped by hundreds of decisions while remembering none of them, and every architect leaving the organisation took a private copy of the reasons with them.
A decision element, defined precisely
The core of the engagement was a small profile — a handful of stereotypes and tagged values, agreed in two working sessions and packaged so that they appeared naturally in the modellers' toolbox. A «Decision» element carried the decision statement in one sentence, with tagged values for status, the date decided, the deciding forum, and a review-by date for decisions that were explicitly provisional. «Option» elements captured the alternatives considered, linked to their decision, with the chosen one marked; the rationale lived on the decision itself: why the chosen option won, closed with the answer to "what would make us revisit this". Association relationships with an «affects» stereotype connected the decision to the application components, services, nodes and interfaces it governed — and those links, not the text, were the point of the whole design.
We resisted two enrichments, both requested early. The first was capturing full option analysis — cost models, scoring matrices — inside the model; that material belongs in the papers a forum reads before deciding, and the model links to it rather than absorbing it. The second was decomposing rationale into structured sub-elements, force by force. There are methods that do this, and in our experience they produce decision records nobody writes twice. One decision element, one option set, one honestly written paragraph of rationale, and real links to the estate: that is a discipline architects will actually sustain, and a sustained plain log beats an abandoned sophisticated one in every organisation we have seen.
Packaging the profile as an MDG Technology
A profile that lives in one repository as loose stereotypes decays the first time someone types the stereotype name from memory and gets it nearly right. So once the definitions had survived two weeks of real use, we packaged them as an MDG Technology: the stereotypes with their tagged value definitions, a toolbox page offering Decision and Option directly, and shape scripts giving decision elements a consistent, deliberately modest appearance — a small amber-edged card that reads clearly on a crowded diagram without competing with the architecture it annotates. Superseded decisions rendered grey through the same shape script, driven by the status tag, so a diagram told you at a glance which of its governing decisions still governed.
The packaging details are mundane and consequential in equal measure. The technology file was deployed from a shared location that every Sparx EA client picked up on start, so all eight architects had the same version without anyone copying files; version and release notes lived in the technology itself. Quick-linker rules steered what an «affects» association could target — steered rather than policed, since a determined modeller can always draw a link by another route, which is why the weekly script checked targets as well. And because tagged values were defined in the profile rather than added ad hoc, every decision carried the same fields spelled the same way — the property the reporting scripts depended on, and one that hand-applied conventions never keep for long. We wrote about the general technique in our guide to custom toolboxes with MDG Technologies; this was that technique at its smallest useful size.
Decisions live next to what they affect
The organising principle — the one the engagement's title comes from — was placement. A conventional decision log is a list somewhere, and lists somewhere are exactly what the organisation already had. Instead, decisions surfaced in three places at once. Structurally, each decision element lived in a decisions package within its domain, keeping governance material from cluttering the estate model. Visually, the diagrams of affected areas carried the decision element, styled small and consistently, so that anyone opening the storage architecture diagram met the standardisation decision on the page itself. And navigationally, the «affects» links meant that from any element, the decisions governing it were one traceability step away — the repository's element browser shows the connected decisions the way it shows any other relationship.
That third surface is the one that changed behaviour, because it inverted the effort. Finding the decisions about a component stopped requiring anyone to remember that decisions existed; the component itself disclosed them. An architect assessing a change to the sample data pipeline saw two governing decisions before drawing anything — one about the storage service, one about an interface convention — and could read, in a minute, what had been decided, by whom, and what would justify reopening it. We wrote up the search patterns behind these views in the same spirit as our automation API guide: unglamorous queries, disproportionate value.
A worked example: the storage decision
The storage standardisation question — the one that had been decided three times — became the profile's proving ground, and walking it through shows the mechanism at working size. The decision element stated, in one sentence, that institute data platforms use the shared storage service for new datasets unless a documented instrument constraint prevents it. Three option elements hung off it: the shared service, per-institute storage, and a hybrid with local ingest and central archive. The chosen option was marked; the rejected ones kept short notes on why — cost of operating nine storage stacks for one, the high-rate instruments the hybrid was invented for.
The rationale paragraph did the profile's hardest work. It recorded why the shared service won — one operating team instead of nine, predictable cost, one backup regime — and then named the conditions under which the decision should be revisited — a substantive change in the shared service's pricing, or an instrument generating data faster than the network path to central storage could carry. Fourteen «affects» associations connected the decision to the storage service itself, the institute data platforms, and two ingest interfaces. When one institute later procured a detector that genuinely met the documented constraint — writing data faster than the link to central storage could sustain — the architect involved did not reopen the standardisation debate; she invoked the documented exception, linked her design to the decision, and the board noted it in ten minutes. The decision worked exactly as a good precedent should — not by forbidding thought, but by recording which thinking had already been done.
The lifecycle and the board
Decisions moved through a deliberately short lifecycle: proposed, under review, accepted, superseded — with rejected for declined proposals, and withdrawn for an established decision retired without a successor. Rejected was recorded rather than deleted, because knowing what was considered and declined spares the next proposer the same journey. The fortnightly architecture board became the forum where transitions happened, and the model became the board's paperwork. A proposal arrived as a decision element with its options and affects-links already drawn; the board's pack was generated from the repository the day before; and the outcome was recorded by changing the status tag and filling in the forum and date, in the meeting, on the projected model.
Between boards, the process bent without breaking. Proposals could be circulated for asynchronous comment when a project could not wait a fortnight, with the board ratifying at its next sitting; the status stayed at under review until ratification, so the model never claimed more authority for a decision than it actually had. Twice in the first year a genuinely urgent call was made outside the process entirely — production incidents do not consult governance calendars — and both were entered into the log retrospectively within the week, options and all. We count that as the process working: a decision log that cannot absorb reality's exceptions gets abandoned by them.
Supersession earned its place as a first-class transition rather than a euphemism for deletion. A superseded decision kept its element, its links and its history, gained a link to its successor, and appeared greyed in the diagram styling. The chain of supersessions turned out to be the organisation's institutional memory in its most honest form: the storage standardisation question, once backfilled, showed as a decision made in one form, superseded eighteen months later for stated reasons, and superseded again — which is not indecision but evolution, finally visible as such. The next time the question surfaced — after the backfill, with the chain finally visible — the discussion took twenty minutes, because it began from the recorded rationale rather than from first principles.
Backfilling forty standing decisions
A decision log that starts empty governs nothing, so a third of the engagement went into retrofit. With the head of architecture we listed the decisions the organisation currently operated by — trawling two years of minutes, the one team's decision records, the slide decks, and the unwritten precedents the architects could name when asked directly. The list stabilised at around forty standing decisions, which we worked through in five half-day workshops: for each, a one-sentence statement, the options as best anyone could reconstruct them, the rationale as currently understood, links to the affected elements, and a status.
The reconstruction was imperfect by design. Where nobody could recover why a decision had been made, the rationale said so — "reconstructed; original reasoning not recorded" — and carried a review date, on the theory that a decision whose reasons are lost is due for re-examination rather than quiet obedience. Half a dozen "decisions" dissolved under scrutiny into habits nobody would defend, and lapsing them explicitly — as withdrawn — was as valuable as recording the rest. The workshops also settled who owned each standing decision going forward, which mattered more than we anticipated: an owned decision gets maintained, an unowned one becomes archaeology within a year.
Practically, each workshop ran to the same shape: six to eight decisions per half day, the head of architecture in every session, plus whichever architects the domain demanded, with one of us modelling live and another keeping the group honest about the difference between what was decided and what people wished had been decided. The distinction came up more often than expected. Several reconstructed rationales began as justifications of the present arrangement and had to be walked back to what the record could actually support — minutes have a way of being remembered as more decisive than they read. Where memory and minutes disagreed, the minutes won and the discrepancy was noted, because a decision log that launders hindsight into foresight teaches its readers to distrust it from the first entry.
Scripted checks that keep the log honest
Structure that depends on discipline erodes, so we finished by making the discipline partly mechanical, in the spirit of model validation in Sparx EA. A scheduled script checked the decision estate against a short list of rules: an accepted decision must have at least one considered option, a non-empty rationale, a deciding forum and at least one affects-link; an under-review decision older than two board cycles is flagged; a superseded decision must link to its successor; and any element accumulating more than a handful of governing decisions is reported, since that usually signals decisions written too broadly. The weekly report went to the architecture group's channel, and was mostly, pleasingly, short.
The rules are deliberately about form, not wisdom. A script can insist that a decision has options, rationale and a place where its impact lands. Whether the decision is any good remains the board's problem — as it should be.
Publishing decisions beyond the architecture group
Eight architects were never the only audience. Institute IT leads, project managers and the occasional principal investigator all had reasons to know what had been decided, and none of them would ever open a modelling client. So the decision estate was published outward on a schedule: a read-only HTML export of the repository for those who wanted to browse, and — more used in practice — a generated decision index, produced by a script from the model searches, listing every active decision by domain with its one-sentence statement, its date, its forum and a link to the detail. The index was regenerated weekly and lived on the intranet page people already visited.
The effect showed up in the architecture group's inbox. The steady trickle of "are we allowed to" and "did we ever decide about" emails thinned noticeably within a quarter, replaced in part by a more interesting correspondence: people citing decisions back at the architects, occasionally to challenge them. One institute lead built the quarterly IT briefing for his directorate around the index's recent-changes section. We would caution against measuring adoption too eagerly here — page views on an intranet prove little — but emails that stop arriving are their own kind of evidence, and the group noticed.
Publication also imposed a useful discipline inward. Knowing the one-sentence statement would appear on a page read by non-architects pushed authors towards statements a non-architect could parse, and the worst jargon was edited out at proposal stage rather than after. A decision that cannot be summarised for its own audience is usually a decision that has not finished being made, and the index made that visible early.
What changed in practice
The observable changes arrived within the first few months. Board meetings shortened, because proposals arrived in a common shape and the pack generated itself. The re-litigation meetings — the ones that had launched the engagement — did not entirely vanish, but they changed character: they now began from the recorded decision and asked whether its stated revisit-conditions had been met, which is a legitimate governance question rather than an expensive memory failure. Two newcomers who joined the architecture group that year onboarded against the decision estate and described it as the most useful induction material they were given, ahead of the architecture itself.
The subtler change was in the quality of proposals. Knowing that a decision would be recorded with its options and rationale, in a place where colleagues would encounter it for years, proved to be a quiet forcing function on how carefully options were actually considered. One architect put it to us directly: writing the rationale paragraph is where he now discovers whether he has one. We have built architecture capability in enough organisations to say that this effect — the record improving the deciding, not just remembering it — is the real return on the work, and it does not show up in any metric the first quarter.
What a repository cannot decide for you
The limitations deserve their own section, because decision modelling is oversold more often than most practices. Sparx EA is not a workflow engine: nothing in the repository compels a proposer to seek review, and the status tag records that approval happened rather than making it happen. The board's authority remained social, backed by the head of architecture, and the model merely made exercising it cheap. Decisions about things outside the model's scope — tooling choices, team structure, budget lines — fit the profile awkwardly; we allowed them into the log with lighter linking rather than pretending the estate model could anchor them, and that compromise has held without becoming a loophole.
And the mechanism is only as alive as its board. In an organisation that stopped holding the fortnightly review, statuses would go stale within months and the log would begin its slide back into the minutes archive. We said this plainly in the handover: the profile, the placement and the scripts remove the friction from remembering, but they do not remove the need to keep deciding in the open. Eighteen months on, the board still meets, the weekly check report is still short, and the storage question has not been debated from first principles again — which is, by the standard the engagement was set, the result that matters.
If your organisation keeps re-making its own decisions, or is about to lose the reasons for them to a retirement or a reorganisation, this approach transfers well. Our Sparx EA consulting covers the profile design, the backfill workshops and the board process described here, and you can reach us through our contact page.
This case study describes a representative engagement pattern. Organisational details are illustrative and do not identify a specific client.