Robert Stowe

Architecture decay research is strong on detection, weak on repair

Looking up at the Sky Tower beside a glass-fronted building and construction scaffolding against a blue sky.
Architectural Degradation: How to Measure and to Remediate
Context. Architectural degradation undermines software maintainability, evolvability, and quality. However, existing research remains fragmented across measurement approaches, metrics, tools, and remediation strategies, limiting our understanding of how these elements relate across the degradation lifecycle. Aim. We consolidate the state of the art on architectural degradation by examining how researchers measure it, which metrics and tools support its assessment, and how existing approaches address remediation. Method. We conducted a Multivocal Literature Review of 284 peer-reviewed and grey-literature studies. We supported screening, data extraction, and classification with a locally executed LLM-assisted pipeline combining Retrieval-Augmented Generation, multi-model validation, and human adjudication. We then analyzed the resulting taxonomies and their cross-dimensional relationships. Results and Conclusions. We identified 277 measurement approaches, 357 metrics, 238 tools, and 395 remediation approaches. Research strongly concentrates on static and structural analysis, structural metrics, and detection-oriented tools. In contrast, remediation spans heterogeneous code-level, architectural, and organizational interventions and shows substantially less consolidation. Overall, the field has developed a mature diagnostic apparatus but has made less progress in connecting degradation detection with effective remediation. Our results provide a structured view of the available techniques and identify the diagnosis-remediation gap as a key direction for future research.
arxiv.org

Researchers counted 238 tools for detecting architectural degradation and found that the field still has little to say about fixing it. A new literature review on arXiv covering 284 studies catalogued 357 metrics and 395 remediation approaches, and concluded that diagnosis is mature while the link to repair is not.

I think that gap is not mainly a research problem. Detection is something you install. Remediation is a decision: who pauses feature work, for how long, and which boundary gets redrawn. The paper notes that fixes range from code changes to organizational ones, and the organizational ones are where most teams stall.

So my view is that most teams do not need another metric. They need fewer findings, each with an owner and a date, and permission to treat an architecture fix as planned work instead of something squeezed in around features.

In years of maintaining front-end architecture standards, I have come to believe that a degradation report nobody is scheduled to act on does more harm than no report. It teaches a team that the warnings are noise.

How does your team decide which architecture warnings get an owner, and which ones quietly become noise?

Photo source: https://photos.robertstowe.com/new-zealand