When architecture governance has to become real
Governance fails in one of two directions: it has no teeth and is ignored, or it has teeth and becomes a queue. Both come from the same cause — the review is a meeting about documents rather than a check against a model.
The situation
Somebody senior has decided that architecture decisions need oversight. The usual implementation is a board, a template, and a fortnightly meeting, and within two quarters teams have learned either to skip it or to write the document that gets through it.
What makes the difference is whether the standards are checkable. A principle that lives in a slide is enforced by argument, and the person who argues best wins. A principle checked against the model is enforced consistently, and the review stops being a negotiation.
The second thing that makes a difference is where the review sits. A board that reviews finished designs is a tollbooth. A check that runs while the design is being made is a tool, and people use tools voluntarily.
You are here if
- Design reviews consist of reading a document written the night before.
- The same objection is raised in every review and resolved differently each time.
- Nobody can say which designs were approved, by whom, or on what basis.
- Teams have started shipping without review because the queue is too long.
How the work gets done
Write the principles down where they can be checked
Encode the principles and policies as rules against the model, rather than as prose in a wiki. A rule that can be evaluated is one that gets applied the same way to everyone, which is the entire moral case for governance.
Start with the handful you would actually block a design over. A hundred principles with no teeth is worse than five with them, because it teaches people the whole set is decorative.
Simulate ▸ Policy & StandardsSimulate ▸ Principle ComplianceSimulate ▸ Rule Evaluation
Check naming and modelling standards mechanically
Naming, keys, nullability and the structural conventions are the part of a review that consumes the most time and generates the least insight. Have them checked automatically so the review is spent on the decisions that need a human.
Data ▸ Naming StandardsData ▸ Validate ModelData ▸ Health Report
Make the approval a record, not a meeting outcome
Route designs through an approval workflow so that what was approved, by whom, and against which version is recorded rather than remembered. This is what turns governance into something you can answer questions about a year later.
Approval rights should sit with people who did not produce the design. Otherwise the control is a formality, and everyone involved knows it.
Diagram ▸ Approval workflowDiagram ▸ Version history
Give the board something to review
Viewpoints and the scorecard let a review look at a design through the lens it is being judged against, instead of through whatever picture the team happened to draw.
Keep the outcome attached to the model. A review whose output is a document that lives somewhere else has already started decaying.
Arch ▸ ViewpointsSimulate ▸ Scorecard & Review
What you end up holding
- A small set of principles expressed as rules that can be evaluated against any design.
- Automated naming and model validation, so reviews are not spent on convention.
- An approval record naming the design version, the approver and the date.
- A repeatable review view rather than a bespoke deck per project.
Not this, if
- The organisation has not agreed that governance is wanted. Tooling does not create authority, and installing it first produces a very well-instrumented process that nobody follows.
- You need governance over things that are not modelled here — vendor contracts, hiring, budget approvals. This governs architecture.
- Governance and approval features are each enabled per organisation, so confirm what your organisation has before designing a process around it.