Architectural Degradation: How to Measure and to Remediate

1 Introduction

• Degradation accumulates through ongoing evolution, undocumented changes, architectural violations, and growing dependency complexity, making systems harder to understand, maintain, and extend.The paper also links degradation with eroded architectural integrity and threats to sustainability.Source: §1 · p. 2
• Existing secondary research leaves measurement approaches, metrics, tools, and remediation strategies difficult to connect in a unified view.Earlier work often examines isolated aspects such as metrics, recovery, or erosion detection.Source: §1 · p. 2
• The review synthesizes peer-reviewed and grey literature using an LLM-assisted pipeline with Retrieval-Augmented Generation, multi-model validation, and human adjudication.It also connects the resulting taxonomies through cross-dimensional and maturity analyses.Source: §1 · p. 2
• The study contributes a multivocal review, four evidence-based taxonomies, and an integrated analysis of research-landscape maturity.It offers researchers a structured agenda for the diagnosis–remediation gap and practitioners an evidence-based map of available techniques.Source: §1 · p. 2
• Diagnosis is mature and structurally focused, with static analysis, structural metrics, and detection-oriented tools dominating, while remediation remains fragmented and less mature.The transition from detecting degradation to acting on it is comparatively immature.Source: §1 · p. 2

2 Background and Related Works

• De Silva and Balasubramaniam classify architectural-erosion techniques as prevention, minimization, and repair, and argue that erosion cannot be addressed effectively through one strategy, instead advocating a combined approach.Source: §2 · p. 3
• Recovery reviews cover automation and software product lines, where shared assets and variability complicate applying single-system approaches.The SPL mapping study identifies gaps for systems evolved from cloned or ad hoc codebases; a separate review emphasizes automated and semi-automated recovery.Source: §2 · pp. 3–4
• Other reviews examine open-source degradation factors, practitioner perceptions, and degradation metrics, but leave aspects of causes, evidence, or metric effectiveness open.Baabad et al. identify frequent modifications, rapid evolution, and limited architectural awareness; Li et al. note the need for stronger empirical support for tools and techniques.Source: §2 · p. 4
• Prior secondary studies generally treat architectural degradation dimensions separately, leaving an integrated synthesis of measurement, metrics, tools, and remediation missing.This review combines academic and practitioner evidence and examines both the four dimensions and their cross-dimensional relationships.Source: §2 · p. 4
• Earlier syntheses include erosion, recovery, metrics, and practitioner perspectives, while the present review jointly examines how degradation is measured, assessed, and remediated.The integrated review analyzes the relationships among these dimensions across the degradation lifecycle.Source: §2 · p. 4

3.1 Goal and Research Questions

• Four research questions guide the review: they identify measurement approaches, classify metrics and tools, and identify remediation techniques.The questions aim to consolidate measurement methods and their characteristics, map the architectural properties captured by metrics, characterize tool functionality and automation, and classify preventive, corrective, and continuous remediation.Source: §3.1 · pp. 5–6

3.2 Search Strategy

• The search methodology covers source selection, inclusion and exclusion criteria, search terms, data extraction, and classification, using two LRM/LLM execution rounds.One round supported comprehensive reading and the other title-and-abstract selection; the work ran locally in a secure university supercomputer environment without cloud services or external APIs.Source: §3.2 · p. 6

3.2.1 Search String.

• The search string combined “software architec*” with wildcarded terms for degradation, aging, erosion, decay, drift, deterioration, degeneration, consistency, adherence, and conformance.Alternative terms were included because prior studies use several of them interchangeably.Source: §3.2.1 · p. 6, Search String · p. 6

3.2.2 Bibliographic Sources.

• Peer-reviewed studies were sought in five bibliographic databases, while web search engines, Google Scholar, and Stack Overflow supplemented coverage with grey literature.The academic sources were Scopus, Springer Nature, Web of Science, IEEE Xplore, and the ACM Digital Library; the supplementary sources provide access to practitioner and other nontraditional literature.Source: §3.2.2 · p. 6

3.2.3 Inclusion and Exclusion Criteria.

• Inclusion and exclusion criteria were applied to titles and abstracts, full texts, or both, as specified for peer-reviewed and grey literature.The criteria were reported separately for the two literature types in Tables 2 and 3.Source: §3.2.3 · p. 7, Table 2 · p. 8, Table 3 · p. 8

3.2.4 Search and Selection Process.

• In January 2026, the search retrieved 8,672 articles; after deduplication, 7,263 unique articles remained, including 6,413 peer-reviewed articles.The search covered publications accessible at that time; the supplied passage does not state the remaining grey-literature count.Source: §3.2.4 · p. 7
• A local reasoning model screened titles and abstracts using prompted inclusion criteria, with its outputs checked by three independent LLMs and researchers.Selected full-text PDFs were then provided to the model for systematic data extraction using Retrieval-Augmented Generation to retrieve relevant contextual evidence.Source: §3.2.4 · pp. 7–8
• The inclusion and exclusion criteria were pilot-tested on 20 randomly selected studies, independently evaluated by three authors.Source: §3.2.4 · p. 8
• Peer-reviewed articles were assessed with a checklist based on Dybå and Dingsøyr, using a 0–4 scale and a passing threshold of 2.The review relied on a checklist for grey literature as well.Source: §3.2.4 · p. 9
• 284 primary studies were retained from 7,263 unique papers, after title-and-abstract screening selected 421 studies for full-text assessment.Full-text assessment excluded studies that did not report an approach relevant to software architecture degradation.Source: §3.2.4 · pp. 8–9

3.3 LRM/LLM Setup

• Categorization and rating are described as laborious and error-prone, while manual coding can be resource-intensive and prone to inconsistency and judgment bias.The review positions LLMs as support for applying empirical review methods at larger scale, not as a replacement for them.Source: §3.3 · pp. 9, 11
• LLMs support multi-label, semantically rich extraction from brief sentences, consistent prompt logic across dimensions, and scaled evaluation through model agreement and sampling.Traditional NLP approaches required task-specific feature engineering, training data, and repeated tuning for each classification dimension.Source: §3.3 · p. 11
• The pipeline extracts and classifies measurement approaches, metrics, tools, and remediation strategies at scale while retaining human oversight.It integrates LLM-based semantic extraction, multi-model cross-validation, and human adjudication.Source: §3.3 · p. 11
• The five-step process covers inclusion decisions and extraction, validation by three LLMs and humans, data cleaning, LLM categorization, and co-occurrence analysis.The extracted fields were defined before extraction and mapped directly to the research questions.Source: §3.3 · pp. 11–12

3.4 LRM/LLMIntegration, Experimental Design and Validation

• Marco-o1 extracts information, while Llama, Mistral-NeMo, and Qwen validate its reasoning and output.Prompts use few-shot learning and Chain-of-Thought; deterministic decoding and a no-hallucination JSON prompt are also specified.Source: §3.4 · pp. 12–13
• RAG retrieves semantically similar labeled instances; long papers are chunked and indexed before the model produces concise JSON answers by category.The pipeline converts PDFs to text and uses embedding-based similarity search for retrieval.Source: §3.4 · p. 12
• Three human experts assess model outputs, with a third reviewer resolving disagreements through majority voting among the validators.Two experts review independently, and the third assesses cases where their judgments disagree.Source: §3.4 · p. 13

3.4.1 Data Extraction and Classification.

• The extraction form maps predefined fields to the research questions; full-paper LRM outputs become CSVs, with inconsistencies or low-confidence items manually inspected.The extracted fields cover measurement approaches, metrics, supporting tools, and remediation strategies.Source: §3.4.1 · p. 13

3.5 Verifiability and Replicability

• The replication package includes the search protocol, prompts, configurations, scripts, extracted data, classifications, and analyses, with evidence traceable to primary studies.The authors state that the package supports independent inspection and reproduction of the analyses.Source: §3.5 · p. 14

4.1 Approaches to Measure Architectural Degradation (RQ1)

• Among 277 approaches, static and structural analysis dominates (56.7%), while evolutionary and historical analysis is least represented (12.0%), reflecting snapshot-based assessment over change.The difference between these categories approaches a factor of five.Source: §4.1 · pp. 14, 16, Figure 3 · p. 17

4.2 Software Metrics for Architectural Degradation (RQ2)

• Dependency and modularity metrics lead structural metrics at 28.9%, while architectural smell metrics account for 14.4% and technical debt metrics for 13.4%.By contrast, documentation and traceability metrics appear in 2.5% of studies and testability metrics in 1.1%.Source: §4.2 · p. 18

4.3 Tools to Measure Architectural Degradation (RQ3)

• Detection and analysis tools dominate, appearing in 63.0% of primary studies.Static analysis tools account for 20.4%, dependency analysis tools 20.1%, graph-based tools 10.2%, smell detection tools 7.0%, and clustering tools 5.3%; these inspect code and structural relationships to find anomalies and group elements.Source: §4.3 · pp. 18–19

4.2 Software Metrics for Architectural Degradation (RQ2)

• Structural design metrics appear in 92.3% of studies, followed by quality and maintainability metrics (35.9%) and degradation-specific indicators (27.8%).Auxiliary and statistical indicators are the smallest category at 12.7%, so degradation is quantified mainly through structural properties and their maintainability consequences.Source: §4.2 · p. 18, Figure 4 · p. 19

4.3 Tools to Measure Architectural Degradation (RQ3)

• Infrastructure and evaluation support is the second-largest tool category, appearing in 55.6% of studies.The tool ecosystem is mature for detecting and analyzing degradation, but considerably less developed for assisting remediation.Source: §4.3 · pp. 18–19
• Recovery and reverse-engineering tools appear in 36.3% of studies, with architecture recovery tools at 28.9%, reverse engineering at 6.0%, and mining and repository analysis at 1.4%.They reconstruct architectural views and relationships when documentation is inaccurate, often recovering architecture before identifying degradation; researchers also combine specialized tools with general infrastructures, scripts, and experimental environments.Source: §4.3 · p. 20
• Detection and analysis tools account for 63.0%, compared with 9.9% for remediation-support tools; tooling supports diagnosis and reconstruction more extensively than corrective action.Infrastructure and evaluation support account for 55.6%, and recovery and reverse-engineering tools for 36.3%.Source: §4.3 · p. 20

4.4 Remediation Approaches (RQ4)

• Code-level repair includes refactoring and restructuring in 39.4% of studies, smell and violation resolution in 6.7%, and dependency and modularity improvement in 5.3%.These behavior-preserving changes include extracting methods or classes, moving elements across modules, reducing dependencies, and reorganizing package or module boundaries.Source: §4.4 · p. 21
• Process and organizational remediation appears in 49.3% of studies, including process, governance, and decision support at 33.1% and documentation and knowledge management at 15.5%.These approaches address decision-making, governance, reviews, knowledge sharing, and development processes rather than changing source code.Source: §4.4 · p. 21
• Architecture-level repair appears in 40.5% of studies, including recovery and reconstruction at 20.8%, conformance and compliance improvement at 14.1%, and migration and modernization at 5.6%.These interventions restore architectural structures, realign implementations with decisions, or replace outdated solutions.Source: §4.4 · p. 21
• Other remediation approaches appear in 10.2% of studies and collect techniques outside established code-level, architecture-level, organizational, monitoring, runtime, or quality-management categories.Their limited presence indicates convergence on recognizable remediation levels, despite variation in the techniques used.Source: §4.4 · p. 22
• Code-level repair is most common at 51.4%, followed by process and organizational remediation at 49.3%, architecture-level repair at 40.5%, and other approaches at 10.2%.The literature emphasizes corrective actions at code, organizational, and architectural levels over less conventional forms.Source: §4.4 · pp. 21–22, Table 13 · p. 22

5 Discussion

• Structural assessment dominates: Structural Design Metrics appear in more than 90% of primary studies, while runtime analysis, metrics, and remediation are underrepresented.The discussion identifies a disconnect between degradation’s evolutionary causes and methods centered on structural properties, which may detect it only after effects materialize.Source: §5 · p. 24
• Dominant end-to-end workflows converge on static analysis, structural metrics, and detection tools, then diverge during remediation.The discussion says methodological diversity is concentrated after diagnosis, shifting the challenge toward understanding how remediation strategies should interact through software evolution.Source: §5 · p. 24
• Diagnosis has reached methodological maturity, while remediation remains fragmented across code-level, architectural, and organizational interventions.The discussion argues that future advances are more likely to come from integrating corrective strategies than from proposing additional detection techniques.Source: §5 · pp. 24–25

5.1 Detection Without Action

• The literature offers many ways to identify degradation but considerably less support for deciding what to do next, and detection tools outnumber remediation-support tools.Studies cover structural metrics, rule checking, smell detection, and analysis tools, while comparatively fewer investigate how to address degradation after detection.Source: §5.1 · p. 25
• Code-level, architecture-level, and organizational remediation are rarely studied as complementary interventions, and recovery tools reflect a reactive focus on lost architectural knowledge.A considerable portion of the literature reconstructs knowledge after it has been lost rather than preventing degradation during software evolution.Source: §5.1 · p. 25
• Machine Learning and Prediction are among the least represented measurement approaches, and AI/ML tooling occupies only a limited share of the landscape.Studies rely predominantly on structural indicators and threshold-based reasoning, with comparatively little work forecasting degradation trajectories before symptoms appear.Source: §5.1 · p. 25
• The discussion describes remediation as fragmented across technical, architectural, and organizational perspectives, while predictive approaches remain relatively unexplored despite their potential for proactive prevention.Together, these gaps leave degradation management oriented more toward reactive recovery than prevention.Source: §5.1 · p. 26

5.2 Research Attention and Technique Diversity

• The catalogue contains 78 static and structural approaches compared with seven evolutionary and historical approaches, leaving changes across versions less examined.The discussion identifies connecting structural observations across releases as an opportunity to investigate when architectural change signals deterioration.Source: §5.2 · p. 27
• Remediation includes 66 code-level, 64 architectural, and 65 organizational strategies, but the catalogue does not establish which combinations suit particular conditions.The discussion calls for studies linking diagnosed problems to intervention rationale, costs, and outcomes over subsequent releases.Source: §5.2 · p. 27
• The catalogue includes 51 runtime and operational metrics and 45 evolutionary and change metrics, but their value depends on whether they inform actionable decisions.Execution behaviour and architectural change provide different evidence, and neither alone establishes how degradation develops.Source: §5.2 · p. 28

5.3 Implications for Practice and Research

• Structural indicators such as coupling, complexity, or smells do not by themselves establish degradation; assessment must consider architectural intent and consequences for evolution.Recovered views may reproduce the dependencies under investigation, so the discussion recommends distinguishing recovered structure from intended constraints before corrective action.Source: §5.3 · p. 29
• The discussion recommends comparing technical repair alone with repair accompanied by architectural guidance or development-practice changes to test whether they prevent recurring violations.Refactoring may remove an unwanted dependency, while rules, decision documentation, and review responsibilities may help prevent its reintroduction; comparisons should assess whether benefits justify costs.Source: §5.3 · p. 29
• Changes in coupling or complexity do not necessarily imply worsening maintainability or greater change effort, so metric changes should be evaluated against violations, cross-component effects, costly modifications, and legitimate evolution.Such evidence could clarify when a measurement warrants intervention and whether an apparent improvement reflects successful remediation.Source: §5.3 · p. 29
• The discussion identifies explicit links between degradation symptoms and corrective actions as a research priority, including tools that explain intervention rationale and trade-offs.Evaluations should test whether recommended actions address the diagnosed problem without shifting dependencies or maintenance burdens elsewhere.Source: §5.3 · p. 29

4. Architectural degradation should increasingly be managed as a continuous architectural governance

• Architectural degradation should be treated as an ongoing activity rather than a periodic assessment task.Source: §4 · p. 29
• Future research should prioritize runtime-aware assessment and decision-support for remediation.Source: §4 · p. 29
• Predictive architectural governance should complement the mature ecosystem of structural analysis and detection techniques.Source: §4 · p. 29

6 Threats to Validity

• Overlapping terminology and differing treatment of architecture conformance may affect how studies operationalize degradation and the resulting taxonomy.Source: §6 · p. 30
• The team mitigated LLM-related threats with RAG, three-model validation, iterative refinement, and independent human adjudication.Source: §6 · p. 30
• LLM prior knowledge, reasoning, and alignment policies, along with prompts and category consolidation, may influence ambiguous classifications; Qwen showed lower agreement on several tasks.Source: §6 · p. 30
• The dataset covers English-language publications indexed by selected sources at search time; some industrial practices, non-English work, or emerging trends may be underrepresented.Grey literature also varies in reporting quality and methodological rigor.Source: §6 · p. 30
• The review synthesizes recurring patterns across 284 studies, so reported frequency does not establish causal relationships or superior effectiveness.The synthesis does not establish statistical relationships, adoption, or methodological maturity.Source: §6 · p. 30
• Different models or execution environments may produce minor variations, so reproducibility is considered at the level of taxonomies, categories, and aggregate findings rather than exact outputs.Source: §6 · pp. 30–31

7 Conclusion

• The review integrates architectural degradation research across measurement approaches, metrics, tools, and remediation strategies.It covers 284 primary studies.Source: §7 · p. 31
• Detection is mature, with static analysis, structural metrics, and detection tools dominating; remediation remains comparatively immature and fragmented.Remediation spans code-level, architectural, and organizational interventions, while tools offer extensive diagnostic support but little help deciding or executing corrective actions.Source: §7 · p. 31
• The authors identify closing the diagnosis–remediation gap as a research priority, including decision-support frameworks.They call for shifting emphasis from developing more detection techniques toward addressing what happens after detection.Source: §7 · p. 31
• The synthesized evidence gives practitioners an actionable map of available approaches and remaining blind spots.The conclusion also points to remediation selection and prioritization, runtime-aware and predictive approaches, and continuous architectural governance.Source: §7 · p. 31
• The taxonomies, maturity analysis, and conceptual framework are intended as a reference for research and a practical foundation for future degradation-management systems.The authors describe the next generation as intelligent, continuous, and automated.Source: §7 · p. 31

Data Availability Statement

• The complete raw data are available in the replication package to support replication of the study.Source: Data Availability Statement · p. 31

• ChatGPT was used for textual-clarity suggestions; the authors created the research design, data analysis, interpretations, and manuscripts.Source: Declaration on the use of generative AI · p. 31

• 0.46–0.71 for Cohen’s Kappa and 0.46–0.78 for Gwet’s AC1 were the pairwise agreement ranges during title-and-abstract screening.Source: §A.1 · pp. 54–55
• K = 0.71 and AC1 = 0.78 were the highest values, both between the LRM (Marco-o1) and V1 (Mistral).Source: §A.1 · pp. 54–55
• K = 0.46 was lowest between V1 (Mistral) and V2 (Qwen), while AC1 = 0.46 was lowest between V1 and V3 (Llama).Source: §A.1 · p. 55

A.2.1 (RQ1) Approaches to measure degradation

• −0.06 to 0.32 was the reported Cohen’s Kappa range for approach extraction, while Gwet’s AC1 values ranged from 0.80 to 0.88.Source: §A.2.1 · p. 55

A.2.2 (RQ2) Metrics for measuring architectural degradation

• 0.35 to 0.56 for Cohen’s Kappa and 0.68 to 0.80 for Gwet’s AC1 were the pairwise agreement ranges for metric extraction.Source: §A.2.2 · pp. 55–56

A.2.3 (RQ3) Tools to support architectural degradation analysis

• 0.26 to 0.51 for Cohen’s Kappa and 0.77 to 0.91 for Gwet’s AC1 were the pairwise agreement ranges for tool extraction.Source: §A.2.3 · pp. 56–57

A.2.4 (RQ4) Remediation Approaches

• 0.23 to 0.41 for Cohen’s Kappa and 0.62 to 0.86 for Gwet’s AC1 were the pairwise agreement ranges for remediation extraction.Source: §A.2.4 · pp. 57–58

A.3.1 (RQ1) Approaches to measure architectural degradation

• K = 1.00 between V1 (Mistral) and V3 (Llama) was perfect agreement in approach classification, while the LRM had K = 0.00 with all three raters.Source: §A.3.1 · p. 58

A.3.2 (RQ2) Metrics for measuring architectural degradation

• K = 1.00 and AC1 = 1.00 between V1 (Mistral) and V3 (Llama) marked perfect metric-classification agreement, while LRM–V1 and LRM–V3 had K = 0.00 but AC1 = 0.84.Source: §A.3.2 · p. 58

A.3.3 (RQ3) Tools to support architectural degradation analysis

• K values ranged from 0.00 to 0.48 for tool classification, while AC1 ranged from −0.57 to 0.58, including −0.57 for the LRM–V2 pair.Source: §A.3.3 · p. 59

A.3.4 (RQ4) Remediation Approaches

• K = 0.71 between V1 (Mistral) and V2 (Qwen) was the highest remediation-classification value, while AC1 = 0.85 was highest between the LRM and V3 (Llama).Source: §A.3.4 · p. 60