Architecture Governance That Fits Everyday Work

The starting point

The organisation, a telecommunications operator, was not new to architecture and not new to Sparx Enterprise Architect. A shared repository had been in place for years, served over Pro Cloud Server, with around forty people touching it — enterprise architects, solution architects embedded in delivery, and a rotating cast of analysts. There was also, formally speaking, architecture governance: a board, a review process, a documented operating model with swim-lanes in it. The repository and the governance had one thing in common, which is that neither quite worked, and they did not work in the same way: both had been designed as if the everyday work of delivery teams would rearrange itself around them.

What brought us in was a growing gap the CTO could measure in surprises. Solutions were reaching production that the architecture function heard about at the go-live retrospective. The repository described a landscape a couple of years younger than the real one. And the review board's queue was long enough that project managers had learned the rational response, which was to not join it. Our brief was to make governance real again — not stricter, the client was clear, but real: conventions people follow, ownership people acknowledge, and reviews that projects experience as help arriving early rather than judgement arriving late.

The governance that existed on paper

It is worth describing the inherited regime fairly, because it was built by capable people and every piece of it made sense in isolation. There was a quarterly architecture board with senior attendance. There was a solution review gate before build, requiring a design document of considerable ambition — the template ran past thirty pages. There were modelling guidelines, written years earlier, living in a document management system three clicks from anyone's daily path. And there was the repository, formally the single source of truth, informally one of several places a design might or might not be reflected.

The numbers told the story better than opinions. The board met four times a year and the average project ran nine months, so a project unlucky with the calendar could wait a quarter for a decision it needed in a fortnight. The review gate, when actually exercised, turned around in two to three weeks — mostly queue, not work. Perhaps a third of active projects had anything current in the repository. And the modelling guidelines had last been updated before two reorganisations, so they referenced teams that no longer existed. None of this was anyone's failure in particular. It was a system optimised for the comfort of the reviewing side, being quietly defeated by the schedule pressure of the delivering side, one rational evasion at a time.

Why it was being routed around

We spent the first three weeks interviewing — a dozen conversations across delivery, architecture and the PMO — and reading the repository against the project portfolio. The diagnosis that emerged was not that people disliked governance; almost everyone we spoke to wanted more architectural involvement, earlier. The complaints were structural. Reviews arrived after decisions had hardened, so feedback meant rework, so teams timed their submissions to minimise what reviewers could still affect. The thirty-page template demanded content that existed nowhere and would be read by no one, so writing it was performance rather than communication. And the guidelines asked modellers to comply with rules the tool did nothing to surface — nobody opens a document in another system to check a naming convention mid-diagram.

One interview crystallised it. A solution architect showed us, side by side, the design she maintained for her team's daily use — current, in the repository, genuinely consulted — and the review document she assembled for the gate, a translation of the first into the template's format. The governance process had achieved the remarkable feat of making the organisation's best modelling invisible to its own reviewers. Whatever we built had to collapse those two worlds back into one: the artefact teams keep for themselves had to become the artefact governance reads.

The principles we agreed before the mechanics

Before touching a single setting we agreed four principles with the head of architecture, and they governed every mechanism that followed. First: rules live where the work happens. A convention that is not visible inside Sparx EA at the moment of modelling is a wish, not a rule. Second: the model is the submission. Governance reads the repository, not documents derived from it; if the repository is not good enough to review, that is the finding. Third: review effort follows risk. A routine integration touching well-understood systems does not need what a new customer-data platform needs, and pretending otherwise taxes the routine work while starving the risky work of attention. Fourth: automation before inspection. Anything a script can check, a script checks, so that human reviewers spend their scarce attention on judgement rather than proofreading.

Stated baldly these sound obvious, and each one retired a piece of the existing regime that had felt untouchable — the template, most notably, did not survive the second principle. Getting them agreed at the top, in writing, before any tooling work, meant that later resistance could be answered with a decision already taken rather than an argument restarted. We have learned to do this in every governance engagement: mechanics are negotiable, principles are not, and confusing the two layers is how governance redesigns dissolve into tool debates.

Conventions people can actually follow

The old guidelines document was replaced by a much smaller set of conventions, chosen by one test: would a reviewer actually send work back over this? Anything that failed the test was advice, and advice went into coaching, not conventions. What survived was compact — a naming pattern for elements and diagrams; a repository structure with defined places for domain landscapes, project work and the governed baseline; a required viewpoint set per solution, four views that every design must have and any design may exceed; and a short list of required attributes on the elements that feed portfolio reporting, lifecycle and ownership chief among them.

Then we did the part that made it governance rather than literature: we pushed the conventions into the tool. The viewpoint set became a model pattern — a small starter package copied in by script at project intake — in the repository's template package, so a new solution model starts from the required views rather than a blank canvas. The required attributes became tagged values with defaults. The naming and completeness rules became checks — of which more below — and the whole convention set fits on two pages that live inside the repository itself, in the model's root package where nobody has to go looking for them. The two pages have been read more in a year than the old guidelines were in five, for the unglamorous reason that they are two pages, and they are where the work is.

Ownership made explicit

Figure 1 shows the shape that made ownership discussable: the repository reorganised so that every package answers to somebody. Domain landscapes — network, customer, billing, enterprise IT — each carry a named owning architect, responsible for that area staying current and for reviewing what projects propose to change in it. Project workspaces belong to their solution architects for the duration and are archived at closure. The governed baseline, the layer that feeds management reporting and the board, is writable only through review. We wired the ownership into the tool with security groups aligned to the domains, group locks applied on each domain package, and lock-to-edit switched on, so the permission model and the responsibility model are the same model — an alignment that sounds cosmetic and is anything but, because it means the tool itself answers "who do I talk to about this?" for every element in the estate.

Ownership also got a maintenance rhythm. Owners review their domain quarterly against a generated exception report rather than from memory, and ownership transfers are a deliberate handover with the report as the agenda, not a name change in a spreadsheet. The first quarter's reports were long and mildly embarrassing, as first reports are; by the third quarter they were short, which is the entire point of making decay visible early.

Reviews sized to risk

The single review gate became three lanes, and the lane assignment is decided in five minutes at project intake using a short risk screen: does the work materially change what customer data is held or how it is protected, introduce a platform, cross domain boundaries, or bind the company commercially for years? Routine work — the clear majority — takes the light lane: the owning domain architect reviews the model in the repository, asynchronously, against the conventions and their domain knowledge, typically inside two days. Significant work takes a scheduled review session with two architects and the model on the screen — the model, not slides of it. Only the genuinely consequential lane goes to the board, which now meets monthly for an hour instead of quarterly for an afternoon, because its agenda finally contains only decisions worthy of it.

Two details of the flow in Figure 2 carry most of its value. Every lane starts with the automated checks, so no human ever spends review time on what a script already caught — a submission with open convention violations simply is not in review yet, and the submitting architect sees that themselves before anyone else does. And every lane ends the same way: the approved change is merged into the governed baseline by the domain owner and a baseline is taken, labelled with the review reference and the approving reviewer, so approval is not a meeting outcome that evaporates but a recorded, attributable state of the model that reporting, and any later dispute, can point at. The approval is the baseline. That one equivalence quietly ended the era of designs that were approved in slides and never landed in the repository.

The intake screen itself deserves a closer look, because it is where the whole system either earns trust or leaks it. It is seven questions, answerable by a project manager without an architect present, and each question is phrased about the work rather than about architecture — "does this change what data we hold about customers?" rather than "does this affect the information architecture?". The screen deliberately over-triggers on ambiguity: any unclear answer routes the project to a fifteen-minute triage call with a domain architect, which costs almost nothing and has twice caught work that the answers alone would have waved into the light lane. The screen's results are recorded in the repository against the project element, so the lane assignment is itself governed — visible, dated, and revisable if scope changes mid-project, which for about one project in ten it does.

Automation instead of inspection

The checks themselves are ordinary Sparx EA machinery, which is rather the point — none of this requires exotic tooling, only the decision to use what is there. Standard model validation covers the structural rules. A set of scripts over the automation API covers what validation cannot express: naming pattern conformance, required attributes populated, the required viewpoint set present for a submitted solution, elements in the governed baseline that no diagram displays, relationships that cross a domain boundary without the owning domain's element being current. The scripts run nightly, from a scheduled command-line EA session on the automation server, against the whole repository and on demand against a single package — the on-demand run is what a solution architect triggers before submitting, and it reports in a minute what used to surface as review comments a fortnight later.

The nightly run feeds two artefacts. Package owners get their exception list, scoped to what they own, short by design. The head of architecture gets a one-page trend: violations by type over time, review turnaround by lane, and the age of the oldest unreviewed submission. That last number had been invisible under the old regime and painful under the new one for exactly one month, after which it stopped being painful because it stopped being large. We have yet to meet a governance metric that improves behaviour faster than a queue-age number with a name attached.

For the review sessions themselves we prepared dedicated review views — diagrams generated for the occasion rather than maintained, showing the submitted design with its points of contact highlighted: which existing elements it touches, which conventions it stretches, which decisions it leaves open. Producing these by script costs seconds and changes the meeting's physics. A review that opens on a neutral, generated view starts from shared facts; a review that opens on the author's own diagram starts from the author's framing, and reviewers spend half the session reconstructing what they are looking at. The views are disposable by design — regenerated when the model changes, never edited — which keeps them honest and keeps nobody maintaining presentation artefacts, the disease the second principle was written to cure.

How it landed

We introduced the whole arrangement through one domain rather than by decree. The billing domain volunteered — its owning architect had been the loudest critic of the old regime, which made her the most credible ambassador for the new one — and for six weeks billing ran the conventions, the lanes and the checks while the rest of the organisation watched it not hurt. The visible facts did the persuasion: billing's reviews turned around in days, its exception list shrank weekly, and its architect spent the saved time in project rooms rather than reading submissions. The remaining domains came across in pairs over the following two months, each seeded with a half-day working session and two weeks of drop-in clinic hours rather than classroom training — governance sticks through early wins in people's actual work, not through slideware about the operating model.

The board needed its own landing. Losing the quarterly afternoon and the thirty-page template read, to some members, as losing oversight, and we took the objection seriously rather than dismissing it: oversight was exactly what they had not been getting from a queue of stale documents. What settled it was the first monthly session run against the live repository — the landscape on screen, the month's significant decisions with their baselines, the exception trend — which gave the board more genuine visibility in an hour than the old cycle had given it in a year. Boards do not resist losing ceremony; they resist losing sight, and the distinction is the difference between governance redesigns that survive their first quarter and those that do not. Our work on connecting governance frameworks to Sparx EA goes deeper into that translation.

The clinics were the sleeper success of the rollout, and we now budget for them by default. Two afternoons a week, one architect from our side and one from the client's, no agenda: bring your model, bring your review finding, bring your confusion. Attendance told us where the design was rubbing — a cluster of questions about the naming pattern in week three produced a clarification to the two-pager; repeated confusion about when project workspaces get archived produced an automation. Clinics also did something training sessions structurally cannot: they let people expose half-finished work without ceremony, which is precisely the state in which conventions are cheapest to apply. When the formal rollout ended, the client kept the clinics running with their own people, which we take as the strongest adoption signal an engagement can leave behind.

What changed for the client

A year on, the measurable changes held. Review turnaround in the light lane runs at two days against the old two to three weeks, and — the number we watch most — the share of active projects with current models in the repository moved from roughly a third to nearly all, because the model is now the submission and there is nothing else to maintain. The go-live surprise, the incident class that started the engagement, has not recurred; the intake screen is wired into the PMO's mandatory project intake — no lane assignment, no funded project — so the architecture function may still disagree with a project, but it no longer discovers one. The repository's governed baseline has become what the old operating model always claimed the repository was: the place management reporting actually draws from, with baselines behind every approved state.

The unmeasured change is tone. Architects describe review as something they do with projects rather than to them, and delivery teams have started requesting the light-lane review early, voluntarily, because it is fast and it catches things while they are cheap. Governance that is experienced as a service gets used; governance that is experienced as a toll gets routed around — the entire engagement is that sentence, mechanised.

Limits and lessons

The honest limits. Sparx EA enforces none of this by itself: validation advises, scripts report, but nothing in the platform prevents a determined modeller ignoring both, so the real enforcement is the review lanes refusing unclean submissions and the exception lists keeping decay visible — social mechanisms, tool-assisted. The risk screen is a judgement call dressed as a checklist, and twice in the first year it under-classified work that deserved the heavier lane; both cases were caught late in the light lane, and both fed a revision of the screen's questions. And the arrangement has a bus-factor: it leans on domain owners being present and engaged, and when one left mid-year, their domain's turnaround visibly sagged until the handover completed. Governance that fits everyday work inherits everyday work's fragilities.

What we would do differently is mostly timing. The nightly checks went live in week eight; they belong in week two, before the conventions are even final, because nothing sharpens a debate about proposed rules like seeing the violation counts each rule would generate. And we would put the board session on the live repository from the very first month, rather than easing it in — the old format's gravity is strong, and every month it survives, it recruits defenders.

If your architecture governance exists mainly in documents, and your delivery organisation has learned to route around it, the path back is shorter than it looks and it starts inside the tool your architects already use — 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.