Architecture drift in monoliths: how dependency shape reveals design debt

At a glance

What this is: This is an architecture review showing how SonarQube can reveal module coupling, dependency drift, and candidates for refactoring in a Java project.

Why it matters: It matters to practitioners because unclear component boundaries make it harder to govern change, reduce blast radius, and maintain secure, understandable software systems.

👉 Read Sonar's architecture review of Microsoft GCToolKit and dependency drift

Context

Architecture drift is what happens when code relationships slowly diverge from the design the team thinks it has. In a small project, those shifts can remain hidden until a dependency map makes them visible. For security and engineering leaders, this is not just a design concern, because unclear module boundaries also weaken control over change, reuse, and unintended coupling.

In this case, the useful question is not whether the code works, but whether the structure still reflects the intended architecture. SonarQube is being used here as a structural lens, not as a runtime security detector. The pattern is typical of mature codebases where growth and convenience create hidden dependencies that need deliberate governance.

Key questions

Q: How should teams use dependency maps to manage architecture drift?

A: Use dependency maps to compare the codebase’s actual structure with the intended architecture. Focus on clusters, cycles, and unexpected cross-layer references, then decide whether each relationship is justified or accidental. The aim is not to eliminate every dependency, but to make boundary violations visible early enough to correct them before they become normal.

Q: What breaks when cyclic dependencies are ignored in modular code?

A: When cyclic dependencies are ignored, teams lose clear ownership of responsibilities, refactoring becomes riskier, and testing scope expands unpredictably. Cycles also make it harder to split modules cleanly because each side depends on the other. Over time, the codebase behaves more like a monolith, even if the package structure looks modular.

Q: How do teams know whether an architecture model is actually working?

A: An architecture model is working when developers can explain the allowed dependency directions and tooling can detect violations automatically. If the model exists only in diagrams, it is advisory rather than operational. The strongest signal is that new changes either fit the model cleanly or fail fast when they do not.

Q: Who should own architectural boundary decisions in a development programme?

A: Architectural boundary decisions should be owned jointly by platform architects and delivery leads, with clear accountability for exceptions. The model needs business context as well as technical logic, because some shared dependencies are intentional. Ownership matters most when teams are shipping quickly, since that is when drift appears first.

Technical breakdown

How dependency maps reveal coupling patterns

A dependency map shows which modules and packages reference one another, making structural relationships visible at a glance. Tight coupling appears when several components depend on each other in a chain or cycle, while looser coupling appears when groups depend on a shared interface or utility layer instead of one another. In architecture analysis, that distinction matters more than raw module count because it reveals whether the code can change safely. A monolith can be small and still be structurally brittle if the relationships are dense and circular.

Practical implication: use dependency visualisation to identify clusters that should stay together and boundaries that need to be formalised.

Why cyclic dependencies create maintenance risk

Cyclic dependencies are feedback loops in code structure, where one component depends on another that also depends back on it, directly or indirectly. They often signal that responsibilities are blurred or that a shared concept has been split too early. In secure engineering programmes, cycles matter because they reduce the ability to isolate change, test independently, and reason about impact. They also make it harder to enforce intended architecture rules, since the path of dependency no longer reflects a clean design choice.

Practical implication: treat new cycles as design defects that should be reviewed before they become normalised into release workflows.

How intended architecture models prevent drift

An intended architecture model defines which components are allowed to depend on which others, turning design intent into an enforceable rule set. That can be used to separate stable API layers from event-processing layers, shared utilities, and other structural roles. The value is not only organisational clarity but also control over future change, because developers can see when a new relationship violates the model. Without that explicit model, teams rely on memory and local habits, which is where drift tends to accumulate.

Practical implication: codify architectural boundaries early so that deviations are detected before they become embedded dependency patterns.

NHI Mgmt Group analysis

Structural drift is a governance problem, not just a code-quality issue. When dependency relationships become hard to interpret, teams lose the ability to explain why a component exists and what it is allowed to touch. That weakens both maintainability and control, because the architecture no longer constrains future change in a predictable way. Practitioners should treat architecture visibility as part of engineering governance.

Feedback dependencies are the clearest sign that design intent has blurred. A loop between components usually means responsibility is shared in the wrong place or a boundary was drawn after the fact. In practice, those loops create refactoring friction and make impact analysis less reliable. The right response is to isolate the dependency cause, not to accept the cycle as harmless technical noise.

Intended architecture only works when it is enforced, not documented. A model that lives only in a diagram will drift as soon as delivery pressure rises. The useful pattern is to define the boundary, then monitor for violations continuously so the design stays legible. That makes architecture review part of ongoing engineering control, not a one-time design exercise.

Modularisation should follow responsibility, not just package shape. Splitting a project into more modules does not improve architecture unless the new boundaries reflect real functional separation. If a shared utility layer is truly shared, it should remain shared. If a vertical processing chain has no reason to depend on the horizontal chain, that boundary deserves to be explicit. Practitioners should optimise for clarity of ownership, not for module count.

Architecture analysis can surface security-relevant coupling even when security is not the topic. Hidden dependencies complicate change control, testing, and future hardening because the scope of impact becomes wider than developers expect. For identity-heavy or control-heavy systems, that matters because access patterns and trust assumptions often follow the same structural shortcuts. Teams should read architecture maps as early warning for both maintainability and governance risk.

What this signals

Architecture governance is increasingly about making structural intent visible before delivery pressure erodes it. The practical signal for teams is whether dependency rules are simple enough to explain, enforce, and audit without relying on tribal knowledge.

Boundary entropy: when the number of informal exceptions grows faster than the number of explicit architectural rules, the design stops guiding change. Teams should watch for that pattern because it usually precedes maintainability debt and control failures.

Where architecture review is already part of engineering quality, the next step is to connect it to change management and release governance. That turns structural drift into an observable risk rather than a stylistic concern.

For practitioners

• Define intended dependency boundaries Document which packages may depend on which layers, then treat any cross-boundary dependency as an exception requiring review. This is most effective when the model is simple enough for developers to remember during daily work.
• Track cyclic dependencies as design defects Add cyclic dependency checks to code review or quality gates so feedback loops are visible before release. If a cycle is unavoidable, isolate the reason and record the exception rather than letting it spread.
• Separate shared utilities from domain chains Keep truly shared classes in a dedicated utility module, but do not use that module as a dumping ground for unclear responsibilities. Shared code should reduce duplication without obscuring ownership.
• Review architecture drift during routine change Revisit the dependency map whenever new features are added to see whether new links preserve or erode the intended structure. This keeps architectural governance close to delivery rather than postponed to later redesign.

Key takeaways

• Dependency shape tells you whether a codebase still matches its intended architecture.
• Cyclic relationships are not cosmetic, because they reduce clarity, increase refactoring risk, and blur ownership.
• Architecture only stays useful when boundary rules are explicit, enforced, and revisited as the code evolves.

Key terms

• Dependency Mapping: Dependency mapping is the process of identifying which systems, services, and workflows rely on a given identity or secret. It is critical for NHI rotation because teams need to know what will fail before they change credentials. Without it, security teams often delay remediation to avoid outages.
• Cyclic Dependency: A cyclic dependency occurs when two or more components depend on each other in a loop. It usually signals blurred responsibilities, creates refactoring friction, and makes it harder to isolate change without affecting multiple parts of the system.
• 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.

What's in the full article

Sonar's full article covers the structural walkthrough this post intentionally leaves at the analysis level:

• A package-by-package dependency review of the GCToolKit architecture and where the coupling clusters appear
• The specific feedback dependency that looks accidental and why it stands out in the dependency graph
• The proposed module split into API, event, and utility boundaries and how that would reshape the design
• The reasoning behind declaring an intended architecture model so future drift can be flagged early

👉 Sonar's full post shows the dependency graph, the coupling pattern, and the proposed modular refactor.

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.