Description
A change arrives. The syntax is immaculate, the logic is sound, the tests are green and the reviewer is satisfied. One line in it inverts a dependency the architecture forbids and closes a cycle the design rules out, and nothing in the pipeline reacts, because the boundary was never in the build. The code was not bad. The rule was not there.
For decades that gap was covered by a person. A senior engineer held the boundaries in their head and caught breaches in review, and it worked because of a ratio nobody had to think about: one human could read roughly what one human could write. That ratio is what changed. The rules did not get weaker and the reviewers did not get worse. The share of changes passing under an informed eye simply fell.
Two things make the erosion hard to see. It is cumulative rather than dramatic: studies following structural problems such as dependency cycles across many releases of industrial systems find they accumulate and entrench, and that practitioners were frequently unaware of the state of their own systems without tooling to surface it. And working and conforming are different properties. In controlled work, generated implementations passed their tests while violating the architectural pattern they had been given, because only one of those two things was being checked.
The response is not a better diagram or a stricter review culture. It is a check that runs and fails, scoped deliberately to the rules that matter rather than every rule anybody could state, because a check people switch off enforces nothing. What this dimension scores is whether your architecture is executable, or whether it is an intention that survives on attention.
The five levels
One question decides which rung you are on: does the system itself act on this, or does a human have to choose to? Each rung carries a tell: the thing that would settle it, so the score is something you checked rather than something you agreed with.
- 1
Blind
The architecture is not written as rules anywhere. There is possibly a diagram, and it describes an intention rather than a constraint, so what may depend on what is decided change by change, by whoever is writing it that afternoon.
The tellOpen your architecture diagram and try to write the same thing as a list of forbidden dependencies. If you cannot, or two people write different lists, nothing is stated firmly enough for anything to enforce.
- 2
Tacit
The rules live in a few reviewers. They know which direction dependencies are supposed to run and they push back when they spot a breach. The protection covers exactly what they read. That was most of the code once. It is now a shrinking fraction.
The tellAsk what proportion of merges a boundary-aware reviewer actually reads now, against two years ago. If it fell and nothing replaced them, protection fell with it.
- 3
Visible but inert
Something measures structure: a dependency report, an architecture linter in warning mode, a periodic review of cycles. Nothing blocks. The violations are listed, the count grows, and a change that adds one merges exactly as easily as a change that removes one.
The tellFind your list of architectural violations and check whether it is longer than last quarter. If it is, and every one of those changes merged, the scan is only counting.
- 4
Acted on
The rules are executable. A scoped fitness function runs in the pipeline and fails the build when a change breaks a boundary, and it is deliberately narrow, covering the rules that matter rather than every rule anybody could state. Conforming becomes a property of the change rather than of the reviewer.
The tellFind the last change that broke an architectural rule. The build refused it and named the rule, rather than a reviewer catching it, and the rule was one somebody chose rather than a default from a tool.
- 5
Durable
The checks track the architecture as it changes. A deliberate architectural change comes with the change to the rule that enforces it, new modules arrive inside the same checks, and exceptions carry an owner and an expiry instead of accumulating quietly at the top of a configuration file.
The tellRead the exception list in your architecture check. If every entry has a name and a date, and the rules changed the last time the architecture did, this is maintained rather than inherited.
What this dimension rests on
The five levels are observed, from client engagements, and no paper produced them. What the research below establishes is why this dimension is worth scoring at all. No links: the citations carry enough to find them, and they stay findable after a link would have rotted.
Sas and Avgeriou, On the Evolution and Impact of Architectural Smells: An Industrial Case Study (Empirical Software Engineering, 2022)
Followed structural problems such as dependency cycles across many releases of industrial systems and found they accumulate and entrench. Developers were frequently unaware of the erosion in their own systems without tooling to surface it.
Slater, Quantitative Analysis of Technical Debt and Pattern Violation in LLM Architectures (2025)
In one small controlled study, generated implementations passed their tests while violating the architectural pattern they had been asked to follow. Working and conforming are different properties, and only one of them was being checked.
Where this came from
This dimension has a published article behind it, written from client engagements rather than from a greenfield repository.
Read the article on Architecture enforcement in CI →
How to climb this dimension is not written yet. It is the next thing this page grows, and saying so is more useful than a paragraph of generic advice.