A board that reviewed everything and settled nothing
The organisation behind this engagement runs services for a mid-sized city: permits, civil affairs, public space, social support, and the shared systems that hold all of it together. Its IT department maintains a portfolio of a few hundred applications, and for several years it has had an architecture board — seven people, meeting every two weeks, with a mandate to review project designs before they proceed to build.
On paper the board worked. In practice, everyone involved had quietly stopped believing in it. Sessions ran to two hours and regularly overran. Project architects presented decks of fifty or sixty slides, prepared in the two evenings before the meeting, and reviewers saw the material for the first time as it was being presented. Discussion drifted towards whatever a board member happened to notice — a naming issue on slide twelve, a technology preference on slide thirty — while the questions the project actually needed answered were never reached. Decisions, when they happened at all, lived in minutes that nobody could find three months later.
The head of architecture asked us a narrow question: could the repository they already maintained in Sparx EA be used to prepare reviews, so that sessions spent their time on the things that genuinely required a room full of senior people? Not a new governance framework, not a new board — the same board, prepared differently.
What eighteen months of minutes told us
We started by reading. The board's secretary kept minutes going back years, and we worked through eighteen months of them, tagging every agenda item and every recorded outcome. We also sat with each board member and with half a dozen project architects who had presented recently — around a dozen conversations in total, each under an hour.
The minutes told a consistent story. The secretary's minutes were thorough enough to record timings per agenda item, and roughly a third of session time went to material that was purely descriptive: context the presenter felt obliged to give, and the board felt obliged to sit through. Another recurring pattern was the revisited dependency — the same integration between the permit system and the document platform was discussed, with the same concerns, in three separate sessions over a year, because nothing connected one discussion to the next. And the outcome most often recorded was not a decision but a deferral: more information requested, item returned to a future session.
The interviews added the human side. Board members told us they could not prepare because the deck arrived late and the repository, which they nominally had access to, gave them no way to see what was new or contentious about a submission. Project architects told us they padded their decks precisely because they could not predict what the board would ask. Each side was reacting rationally to the other, and the format punished both.
One more finding mattered. The repository itself was in reasonable shape — the organisation had invested in conventions and structure, and models were genuinely maintained. The raw material for better reviews existed. What was missing was any distinction, inside the model, between the settled and the unsettled: an assumption looked exactly like a fact, and a decision that had been taken looked exactly like one still pending.
Deciding what a review actually needs to see
Before touching the tool, we agreed with the board what a review session is for. That sounds like a workshop exercise, and it was — one afternoon, all seven members, with the minutes analysis on the table as evidence. The output was three questions that every submission would be required to answer, and that the session would be structured around.
First: what is being asked of the board? A review exists to obtain decisions, so the decisions requested have to be explicit, named, and few. Second: what is unresolved? Open dependencies on other projects or teams, assumptions the design rests on that nobody has confirmed, questions the project could not settle on its own. Third: what has changed? For designs returning to the board, the session should spend time only on the delta since the last visit, not on re-presenting the whole.
Everything else — context, background, the parts of the design that are conventional and carry no risk — would still exist, in the repository, available to any reviewer who wanted depth. It just would not consume session time by default. In our experience of architecture governance in larger programmes, this separation between what is available and what is presented is the single change that does the most work, and it is an editorial decision before it is a tooling one.
Giving assumptions and open questions a home in the model
The three questions only work if the model can answer them, so the next step was a small set of modelling conventions — deliberately small, because every convention we added was one more thing project architects had to learn and maintain.
We introduced three stereotyped element types, packaged so they appeared in a dedicated toolbox page: an Assumption, an Open Question, and a Decision Request. Each carries a handful of tagged values — an owner, a status, a date raised, and for assumptions a short statement of what happens if the assumption fails. Each is linked with a dependency connector to the design elements it affects, which is the part that matters most: an assumption floating in a package is a note, but an assumption wired to the two application components whose integration depends on it is something a reviewer can reason about.
Dependencies on other projects were handled with the conventions the organisation already had, plus one addition: a tagged value marking a dependency as unconfirmed until the other party had agreed it in writing. Decisions taken by the board became Decision elements — the request re-stereotyped once resolved, with the outcome, the date and the deciding body recorded in tagged values, still linked to the same affected elements. Over time this builds something the minutes never provided: standing in front of any element, a reviewer can trace back every decision that shaped it.
We wrote a short validation script, run from the automation interface, that checks submissions for the obvious failures — assumptions with no owner and decision requests with no linked elements, which block scheduling; unconfirmed dependencies older than a threshold are flagged prominently in the pack instead of blocking, since an aged dependency is exactly what the session needs to see — the same approach we describe in our work on model validation in Sparx EA. A submission that failed validation simply was not scheduled.
Building the review views
With the conventions in place, the review views themselves are mostly a matter of searches. We built a set of saved model searches, most of them SQL-based, scoped to a project package: all open assumptions, all open questions, all unconfirmed dependencies, all decision requests, and — using a comparison against the baseline taken at the previous review — all elements added, modified or removed since the board last saw the design, connector changes included — a deleted integration can matter more than an added one. Baselines gave us the delta without asking anyone to maintain a change log: the preparation script baselines the project package at the same moment it generates the pack, so pack and baseline capture the same state and nothing can fall between them. Changes made after preparation belong to the next review by rule, and the next preparation's diff runs against the baseline its own pack was built on.
On top of the searches sit the review diagrams. For each submission, a script assembles a single diagram — one, not sixty slides — showing the elements the session needs to discuss: the decision requests with the design elements they affect, the unconfirmed dependencies with both ends visible, and the changed elements highlighted. The script places elements rather than leaving layout to hand-arranging, and the result is not beautiful, but it is consistent, and consistency is what lets a board member read the third such diagram as quickly as the first.
A word on the mechanics, because they are less glamorous than the idea and they are where the effort went. The searches run against the project tables directly — elements, connectors and tagged values joined by package scope — and the delta search leans on the baseline comparison the tool already performs, exported through the automation interface rather than read from the comparison dialog. Getting the queries to return clean rows took longer than writing them: elements moved between packages mid-project, connectors crossed package boundaries, and every such case had to either resolve sensibly or fail loudly. We kept each search under a second on the organisation's repository, which matters because the preparation script runs all of them for every submission on the agenda, and a facilitator will not run a preparation that takes coffee-break time twice per session.
We resisted the temptation to generate more. Early drafts included capability context views and full application landscapes per submission, and the pilot sessions taught us that every additional view diluted the three questions. The supporting depth stayed one click away in the repository, reachable through element links, for the reviewer who wanted it.
From views to a review pack
Not every board member opens the modelling tool, and we did not try to change that. Instead, the preparation script generates a review pack: a short document produced through Sparx EA's document generation, using a template whose sections are driven by the same model searches. Page one lists the decisions requested, each with its rationale and the affected elements. Page two lists open assumptions, open questions and unconfirmed dependencies, each with an owner and an age in days. Then the review diagram, and nothing else. The packs came out at four to six pages, and the template took perhaps two days of work to get right, most of it spent making the SQL fragments return exactly the rows the board cared about.
The pack is generated three working days before the session and sent with the agenda, which is itself just the list of decision requests across all submissions. Three days proved to be the workable compromise — early enough to prepare, late enough that the model state it captures is still current on the day.
The cycle closes inside the model. During the session, the facilitator records each outcome directly on the decision request — agreed, declined, or deferred with a named reason and a return date. Within a day, the resolved requests are re-stereotyped as decisions, and the project package is ready to accumulate the next round of changes — everything since the pack's baseline will surface in the next preparation. The minutes still exist, but they are now a formality; the model is where the outcomes live, attached to the elements they govern.
The first focused sessions
We ran the new format as a pilot with two volunteer projects before asking the whole portfolio to adopt it. The first pilot session was uncomfortable in an instructive way: the submission had passed validation, the pack was four pages, and the session was over in thirty-five minutes — and several board members reported afterwards that it felt too fast, as if they had not done their job. The habit of equating review time with review quality took longer to unwind than any technical part of the work.
The second pilot surfaced a real gap. A decision request asked the board to approve an integration approach, but the pack gave no view of the alternative that had been rejected. The board was being asked to ratify, not decide. We adjusted the convention: a decision request must link not only to the affected elements but to the options considered, even if an option is a single element with three lines of description. This cost presenters a little more modelling and repaid it immediately in the quality of discussion.
Rollout to all projects took about three months, paced by the board's own calendar. We trained project architects in two half-day clinics — the conventions, the toolbox, and the discipline of writing a decision request as a question that can be answered — and sat in on the first sessions of each newly onboarded project. The validation script did quiet work here: architects learned quickly that an unowned assumption meant an unscheduled review, and the quality of submissions rose without anyone having to police it in person.
What changed for the board
By the end of our involvement the sessions had settled at around forty-five minutes for a typical agenda of two submissions. The board takes more decisions per session than it did per month under the old format, and — the measure we care most about — the deferral rate dropped sharply, because the material needed to decide is in the room the first time. The revisited-dependency pattern from the minutes has not recurred: a dependency discussed once is either confirmed or sits visibly on the open list with an owner and an age, and ageing items get chased between sessions rather than rediscovered in them.
The deck did not survive. Nobody banned it; the pack simply made it redundant, and presenters stopped making one within the first months. The preparation time they recovered — two evenings per review, by their own account — went partly into better models, which is exactly the trade the organisation wanted.
There were quieter effects, too. Because decisions are recorded on elements, other teams reading the repository see them in context — a solution architect reusing a component finds the board's ruling on its intended scope attached to the component itself, rather than buried in a document store. And the assumptions register, which began as review plumbing, turned out to be useful between reviews: the head of architecture now scans the open-assumption search monthly across all projects, and treats clusters of related assumptions as an early signal that two projects are about to collide.
The relationship between the three questions, the model and the pack ended up simple enough to put on one page of the working agreement, and it is worth reproducing because the simplicity is the point:
| The board asks | The model holds | The pack shows |
|---|---|---|
| What is being decided? | Decision requests linked to affected elements and options | Page one: the requests, with rationale |
| What is unresolved? | Assumptions, open questions, unconfirmed dependencies | Page two: the open list, with owners and ages |
| What has changed? | Baseline per session, diffed at preparation | Highlighted elements on the review diagram |
Running it without us
A review process propped up by consultants stops working the day the consultants leave, so the last stretch of the engagement was deliberately about our absence. The scripts and the document template moved into the organisation's own version control, with a named owner in the architecture team who had pair-worked on every change during the rollout months. The toolbox profile — the stereotypes, tagged values and the toolbox page they appear on — was packaged so it deploys with the standard client install, and adding a new board member's machine is not a special event.
Two habits were written into the board's own working agreement rather than left to goodwill. The first is a quarterly look at the conventions themselves: which tagged values are actually filled, which searches return noise, whether the decision-request discipline is drifting back towards ratification. The first of these reviews retired a tagged value nobody used and tightened the ageing threshold on dependencies, which we took as evidence the habit works — a convention set that only ever grows is a convention set nobody is reading critically. The second is onboarding: every new board member gets the same ninety-minute introduction the pilot board got, run by the architecture team from the same materials, because the format only feels natural to people who know why the deck went away.
Eighteen months on, the numbers we hear are steady — sessions still under an hour, packs still generated on schedule, and the scripts still maintained by the same person, who reports the burden as a few hours per quarter. The parts we worried would rot, mostly, have not. The part that needed active defence was scope: twice, other governance bodies asked to bolt their own reporting needs onto the review pack, and twice the board declined, on the grounds that a pack serving two masters would soon serve neither. We think that instinct, more than any script we wrote, is why the thing still runs.
What Sparx EA does and does not solve here
It is worth being honest about the boundaries of this. Sparx EA gave us everything the mechanics needed — stereotypes and tagged values for the conventions, baselines for the delta, SQL searches for the lists, document templates for the pack, and the automation interface to tie it together. None of it required extensions beyond a toolbox profile and scripts, and any organisation with a maintained repository could build the same. Our Sparx EA consulting work is often exactly this: not a bigger platform, but a sharper use of the one already paid for.
What the tool does not provide is the discipline. Nothing in Sparx EA prevents an architect from marking their own assumption confirmed, or a facilitator from skipping the baseline, and the workflow holds only because the board enforces its own rules — validation failures genuinely block scheduling, and unowned items genuinely do not get discussed. We were also honest with the client about a technical limit: baseline comparison in Sparx EA is package-scoped and can be slow on very large packages, which is one of the reasons submissions are structured as reasonably sized project packages rather than review views over the whole repository. A project that sprawls across the model defeats the preparation, so package hygiene became part of the submission rules.
The last limitation is the one we flag whenever this pattern comes up: a review process this lean depends on the repository being trusted. Where models are stale or conventions are decorative, the pack will faithfully summarise material nobody believes, and the board will go back to asking for slides. Review views are the final step of repository quality, not a substitute for it.
If your architecture board spends its time watching presentations rather than taking decisions, and you already maintain a repository that could feed it better, we are happy to compare notes — 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.