Architecture drift in monoliths: how dependency shape reveals design debt

At a glance

What this is: Sonar’s review of Microsoft GCToolKit shows that dependency shape can expose tight coupling, accidental feedback loops, and a monolithic API module.

Why it matters: For practitioners, the point is that architecture drift becomes harder to reverse once dependency boundaries are allowed to form informally and remain unenforced.

Context

Architecture drift occurs when code relationships no longer match the structure the team thinks it has. In modular systems, dependency maps can reveal whether packages are genuinely independent or merely separated by convention, and that matters because unmanaged coupling turns design intent into ongoing maintenance debt.

This review uses SonarQube to examine Microsoft GCToolKit, a Java library set for analysing garbage collection logs. The useful lesson is not about the tool itself but about how structural visibility helps teams decide whether a module boundary is real, accidental, or overdue for enforcement.

Key questions

Q: What breaks when module boundaries are only implied, not enforced?

A: When boundaries are only implied, dependencies drift until packages start behaving like a single unit even if they are named as separate modules. That makes refactoring harder, increases change ripple, and turns architecture into an accidental outcome rather than a controlled design. The remedy is to make the intended boundaries explicit and check them continuously.

Q: Why do cyclic dependencies increase architectural risk?

A: Cyclic dependencies make change propagate in both directions, so a local edit can create unintended effects elsewhere. They also block clean extraction because the code cannot be separated without first untangling the cycle. In practice, cycles are a sign that design intent and implementation have started to diverge.

Q: How do teams know whether a module is truly modular?

A: A module is truly modular when its dependency graph shows clear, one-way relationships and minimal backflow into other parts of the system. If the map shows hubs, cycles, or repeated cross-module references, the module is carrying coupled behaviour rather than clean separation. Use the graph, not the folder tree, as the test.

Q: When should teams declare an intended architecture model?

A: Teams should declare one as soon as structural complexity starts to hide how the system actually depends on itself. The earlier the rules are written down, the easier it is to prevent accidental cross-links from becoming normal. A good model turns architecture from tribal knowledge into something the team can check and defend.

Technical breakdown

How dependency shape reveals coupling

Dependency maps show where packages call, import, or otherwise rely on each other, which is often more honest than folder structure or naming conventions. When several packages point to the same API module, the map can expose a hub-and-spoke shape that may be intentional or may conceal over-concentration. In this article, Sonar uses that shape to show that the API module carries much of the system’s shared logic. That is useful because architecture problems often start as invisible convenience patterns before they become hard constraints on change.

Practical implication: review dependency graphs before approving refactors, because structure tells you whether a module boundary is real or merely cosmetic.

Why feedback dependencies are a design smell

A feedback dependency appears when two components depend on each other in both directions, creating a cycle rather than a clean layered flow. Cycles increase coupling because each change has a chance of rippling back into the other side, which makes extraction and testing harder. The article treats the top-row chain as tightly coupled and therefore not suitable for separation, which is the right architectural reading: if components only work through mutual dependence, they are already behaving like one unit, regardless of how they are packaged.

Practical implication: treat cycles as evidence that boundaries have not yet been designed, not as minor structural noise.

Why an intended architecture model matters

An intended architecture model is the explicit statement of how modules should relate, which classes of dependency are allowed, and where exceptions are permitted. Without that model, teams tend to accept drift one edge at a time until the structure no longer reflects the original design. The article’s proposed split into separate modules shows the value of codifying intent, because the model can then flag accidental cross-links before they spread. That is governance, not aesthetics: the point is to stop structural ambiguity from becoming routine delivery risk.

Practical implication: declare and enforce the target architecture so that new dependencies are reviewed against intent, not habit.

NHI Mgmt Group analysis

Architecture drift is a governance problem, not just a refactoring opportunity. Once a codebase grows around informal dependencies, teams stop seeing the boundary they are crossing. That creates a feedback loop where convenience wins over design, and the architecture slowly becomes whatever the latest change happened to require. The practical conclusion is that structure must be governed as deliberately as access or secrets in security-sensitive systems.

Dependency shape is a better signal than module labels. Package names and directory structure can suggest modularity while the actual graph tells a different story. In this review, the dense API hub and the cyclic horizontal chain show that surface organisation can conceal a monolithic core. Teams should therefore treat architectural visibility as a control, not a reporting nicety.

The named concept here is structural drift debt: the accumulated gap between the architecture a team believes it has and the dependency graph the code actually enforces. That debt compounds because each new exception makes the next one easier to justify. The practitioner response is to make intended structure explicit and machine-checkable before the gap becomes irreversible.

Modular decomposition only works when independence is real. Splitting a system into separate modules does not create separation if the underlying dependencies still point back into the same centre. The article’s proposed refinement is useful precisely because it depends on first removing the accidental feedback edge. The lesson for practitioners is that boundaries should be designed from observed relationships, not from desired labels.

Architecture review needs to be continuous, not episodic. The article shows how a single outlier dependency can hide in a codebase until a structural review surfaces it. That is why architecture governance should be treated as an ongoing discipline alongside release and change control. The conclusion for teams is simple: keep the dependency model current, or the code will define the architecture for you.

What this signals

Structural drift debt: the longer teams tolerate unmodelled dependencies, the more expensive every later modularisation effort becomes. What looks like a tidy package layout can still hide a dependency graph that behaves like a monolith, so governance has to move from naming to enforcement.

Architecture reviews should be treated as a recurring control, not a one-time design exercise. When a codebase can accumulate one accidental reverse dependency without immediate consequence, it can accumulate many more, and the result is a system whose structure no longer reflects how teams think it works.

For practitioners

• Review dependency graphs before modular splits Use structural views to confirm which packages actually depend on each other before planning a refactor or extracting a module. Treat dense cross-links and cycles as evidence that the code is already behaving as one unit.
• Document the intended architecture explicitly Define which dependencies are allowed, which are forbidden, and which exceptions are temporary. Make that model visible to developers so the code can be checked against it during change work.
• Flag feedback dependencies as design debt Create a rule that surfaces cyclic dependencies and unexpected reverse references for architectural review. Prioritise the edges that indicate accidental flow across module boundaries.
• Separate shared utilities from domain modules Isolate classes used by multiple modules into a dedicated shared area only when that split reduces cross-coupling rather than hiding it. Keep the shared layer small and intentional.

Key takeaways

• Dependency shape can reveal architectural truth that package names and folder layout conceal.
• Cyclic relationships are a sign that code paths have drifted away from the modular intent the team believes it has.
• Declaring and enforcing an intended architecture model is the control that keeps structural debt from compounding.

Key terms

• Architectural Drift: The gradual divergence between the system structure a team intends and the structure that the codebase actually expresses. It usually emerges through shortcuts, duplicated logic, and boundary violations that accumulate over time until the code becomes harder to understand and change safely.
• Feedback Dependency: A circular relationship where one component depends on another and that component also depends back on the first. Feedback dependencies increase coupling, make extraction difficult, and often indicate that separate parts of the system are behaving as one unit.
• Intended Architecture: Intended architecture is the design a team wants the system to follow, including its component boundaries and allowed dependency directions. It becomes useful only when it is documented, enforced, and reviewed as the codebase evolves.
• Structural Coupling: The degree to which components rely on each other to function, change, or be understood. High structural coupling makes maintenance harder because a modification in one place is more likely to require coordinated changes elsewhere.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.