How to check a design against architecture principles
Report a design against the principles and policies your organisation has defined, and act on the departures.
When this is useful
- An architecture review needs to be consistent rather than dependent on who is in the room.
- Principles have been agreed and nobody knows whether anything follows them.
- A design deliberately departs from a principle and you want that visible and deliberate.
Before you start
- Principles and standards defined for your organisation. The checks report against declared rules — with no rules, there is nothing to report.
Step 1: Run the principle check
Principle Compliance reports the model against the principles your organisation has defined.
Simulate ▸ Principle Compliance
Step 2: Widen it to policy and standards
Policy & Standards covers the broader rule set, and Rule Evaluation reports the individual rules. Scorecard & Review summarises the outcome for a review conversation.
Simulate ▸ Policy & StandardsSimulate ▸ Rule EvaluationSimulate ▸ Scorecard & Review
Step 3: Decide about each departure
These checks report; they do not block. A departure is a decision to make — accept it and record why, or change the design. The value is in making the choice explicit rather than accidental.
What happens next
A recorded, accepted departure is a much better artefact than a passing score. It tells whoever reviews this next that somebody thought about it.
Example
A design that broke a "no shared databases between services" principle for a documented, time-boxed reason — recorded as an accepted departure with a review date rather than argued about at every subsequent review.
Tips
- Run it early. A compliance report at the end of a design is a report on rework.
- If a principle is failed by nearly everything, the principle is the thing to revisit.
Limitations
- Checks report against declared rules and do not enforce them.
- Principle, policy and rule capabilities are separately enabled.