Architectural Degradation Overview

• Architectural degradation is defined as the progressive divergence between a system’s intended and implemented architecture, leading to a loss of structural integrity.
• It involves both technical causes such as technical debt and design violations, and non-technical factors like organizational issues that impact maintainability.
• Detection methods include consistency checking, architectural smell analysis, and predictive modeling, while repair strategies address both architecture and implementation.

Architectural degradation denotes the deterioration of an architecture as a system evolves or is modified. In software engineering, it is commonly treated as architecture erosion, decay, deterioration, or aging, and is framed as a progressive divergence between intended and implemented architecture, a loss of structural integrity, or a growing resistance to change; in adjacent machine-learning literature, the same term is also used for instability or performance loss induced by architectural evolution or compression (Ahmad et al., 19 Jul 2025, Li et al., 2021, Zhang et al., 2021, Xu et al., 20 Apr 2026).

1. Definitions and terminological scope

In software research, architecture erosion is refined as occurring “when the implemented architecture violates the intended architecture with flawed internal structure or when architecture becomes resistant to change” (Li et al., 2021). The intended architecture is also called planned architecture, as-designed architecture, and prescriptive architecture, whereas the implemented architecture is also called as-implemented architecture, as-built architecture, as-realized architecture, and descriptive architecture (Li et al., 2021). A later multivocal review synthesizes architectural degradation as the progressive divergence between a software system’s implemented and intended architecture, caused by repeated violations of architectural decisions, rules, and principles, cumulative code-level changes that undermine structural consistency, and socio-organizational dynamics such as insufficient architectural knowledge, lack of traceability, inadequate governance, time constraints, and staff turnover (Ahmad et al., 19 Jul 2025).

A complementary formalization treats architecture consistency as a logical satisfaction relation. If architecture is represented as a set of predicate-logic statements $\Phi$, and the implementation artifact set is $S$, then consistency is written as $S \models \Phi$; inconsistency is written as $S \not\models \Phi$; and repair can target either side through $S' \models \Phi$ or $S \models \Phi'$ (Knieke et al., 2021). Practitioner accounts add four recurrent perspectives: structure, quality, maintenance, and evolution, indicating that degradation is perceived not only as a structural mismatch but also as a loss of runtime qualities, maintainability, and evolvability (Li et al., 2021).

Context	Meaning of architectural degradation	Representative sources
Software systems	divergence between intended and implemented architecture; loss of modularity, cohesion, and separation of concerns; resistance to change	(Li et al., 2021, Knieke et al., 2021, Ahmad et al., 19 Jul 2025)
Microservice systems	progressive deterioration of the service dependency graph over releases or traces, including increased coupling and unstable centrality	(Bakhtin, 15 Aug 2025, Bakhtin et al., 9 Jun 2025)
Neural and model architectures	instability or reduced accuracy induced by architectural evolution or low-rank compression	(Zhang et al., 2021, Xu et al., 20 Apr 2026)

A protocol paper on warning signs of erosion does not introduce a new formal definition of architectural degradation, but frames it as part of the broader phenomenon of architecture erosion: an increasing gap between implemented architecture and intended architecture (Li et al., 2022). In that framing, “architectural degradation” is essentially architecture erosion in a worsening evolutionary state (Li et al., 2022).

2. Causes and drivers

The most systematic software taxonomy identifies 13 reasons for architecture erosion, grouped into technical, non-technical, and mixed categories. Technical reasons include architecture violation, evolution issue, technical debt, suboptimal design decision, increasing complexity, and lack of architecture tools. Non-technical reasons include knowledge vaporization, understanding issue, organization issue, communication issue, and environment change. Requirement issue and iterative software development process span both technical and non-technical dimensions (Li et al., 2021). A separate multivocal review recasts these drivers as architectural debt, code debt, and process debt, with major sub-categories including architectural documentation, design decisions, design issues, implementation/code quality, changes, development practices, organization/governance, and knowledge (Ahmad et al., 19 Jul 2025).

Practitioner evidence is more granular about the relative salience of particular causes. In an exploratory study, the reported categories and counts were: Inappropriate architecture changes (22), Architecture design defects (15), Lack of management skills (13), Technical debt (11), Disconnection between architects and developers (10), Knowledge vaporization (9), Requirements change (9), Lack of communication (8), Agile development (8), Increasing complexity (7), Lack of maintenance (6), and Others (9) (Li et al., 2021). That same study emphasizes that erosion is caused to a large extent by non-technical factors, including poor management, poor staffing decisions, weak long-term architectural strategy, loss of architectural knowledge due to turnover and poor documentation, and reduced communication among stakeholders (Li et al., 2021).

Process-oriented and reconstruction-oriented studies describe the mechanisms by which these causes become structural divergence. Reported mechanisms include ad-hoc feature addition without updating the architectural description, deferring architecture refactoring until “the very last moment,” time and budget limitations that favor small local changes over structural corrections, staff turnover, inadequate understanding or documentation of the desired implementation architecture, automatic import insertion in IDEs, and changes in requirements, frameworks, and environment over time (Farid et al., 2011, Schmidt et al., 2014). Non-functional requirement changes are noted as especially destabilizing for architectural consistency (Farid et al., 2011).

Across these accounts, the same pattern recurs: immediate implementation pressure and architectural intent are frequently misaligned. Recent reviews explicitly characterize the field’s conceptual shift from a low-level technical issue toward a socio-technical concern, where degradation emerges from the interaction of architecture, code, and process rather than from code violations alone (Ahmad et al., 19 Jul 2025).

3. Symptoms, smells, and consequences

A widely used symptom taxonomy distinguishes structural symptoms, violation symptoms, quality symptoms, and evolution symptoms (Li et al., 2022, Li et al., 2021). Within that taxonomy, violation symptoms receive special emphasis: they are described as “derived from the definition of architecture erosion” and as the sufficient and necessary symptoms for erosion detection, whereas other symptom types may also appear in non-eroded systems (Li et al., 2022). Examples include violations of design principles, design decisions, requirements, layering rules, dependencies, and modularity (Li et al., 2022).

Architectural smells operationalize these manifestations at the architectural level. One predictive study models architectural decay through 11 smell types: Unused Interface, Unused Brick, Sloppy Delegation, Functionality Overload, Lego Syndrome, Duplicate Functionality, Logical Coupling, Dependency Cycle, Link Overload, Scattered Parasitic Functionality, and Concern Overload (Le et al., 2021). A visualization study treats antipatterns as the atomic units of design erosion and focuses on Circular dependencies, which violate the Acyclic Dependencies Principle, and Subtype knowledge, which is tied to the Dependency Inversion Principle; these instances can emerge, expand, split, and merge over time, and some observed antipatterns involved over 200 classes (Baum et al., 2018).

Consequences are reported at both quality and maintenance levels. The systematic mapping study identifies quality degradation, architectural defect, increased cost, failure of software projects, failure to meet requirements, software aging, technical debt, and organization disintegration as the main consequence categories (Li et al., 2021). Practitioner evidence reports the most frequent consequences as Hard to understand and maintain (20), Run-time quality degradation (13), Enormous cost to refactor (11), Big ball of mud (9), Slowing down development (5), High turnover rate (3), and Overall complexity (2) (Li et al., 2021). Reconstruction work links unhindered architectural erosion to low maintainability, poor testability, and reduced development speed (Schmidt et al., 2014).

Textual discussions by developers expose how such symptoms are recognized in practice. A code-review study collected 606 out of 21,583 review comments from four popular OSS projects and found that 10 categories of violation symptoms are discussed during code review; “inconsistent” and “violate” were the most frequently used terms, Problem Discovery was the most frequent linguistic pattern, and Refactoring and removing code were the major measures (90%) used to tackle violation symptoms, although a few were ignored (Li et al., 2022). These findings locate degradation not only in static structures but also in routine development discourse.

4. Detection, measurement, and visualization

Detection research spans several method families. The systematic mapping study groups approaches into consistency-based, evolution-based, defect-based, and decision-based categories (Li et al., 2021). Consistency-based work includes Architecture Conformance Checking (ACC), Reflexion Modeling (RM), Design Structure Matrix (DSM), and Light-weight Sanity Check for Implemented Architectures (LISCIA). Evolution-based work includes ADVISE, ARCADE / MORPHOSIS, runtime monitoring and interaction validation, and Variant Analysis (VA). Defect-based work includes defect-fix history analysis, architectural smells, PHM, and design pattern grime and rot analysis. Decision-based work captures adopted architectural patterns, tactics, and design rationale (Li et al., 2021).

Measurement is broader than any single detector. A multivocal review identifies 54 metrics and 31 measurement techniques, with metrics concentrated on smells, cohesion/coupling, structural modularity, dependencies, growth, and evolution (Ahmad et al., 19 Jul 2025). Explicitly named metrics include Architecture erosion degree, Architectural smells, Cohesion, Coupling, Dependency Cycle, Structural modularity, Normalised Cumulative Component Dependency, Total Incoming Module Dependencies, Total Outgoing Module Dependencies, cyclomatic complexity, Active hotspots (change proneness), Cross-Module Co-Changes, and Inner-Module Co-Changes (Ahmad et al., 19 Jul 2025). Tool support is extensive for detection but uneven for remediation: the mapping study lists 35 tools, including Lattix, Structure101, Axivion, Sonargraph, ArCh, ConQAT, SAVE, ARCADE, Dclcheck, JArchitect, SonarQube, Sotograph, NDepend, and Getaviz (Li et al., 2021).

Practitioner reports underscore that dedicated architecture-erosion detectors remain uncommon. Developers typically identify erosion indirectly through symptoms, heuristics, and general architectural analysis practices, using tools such as Lattix, NDepend, Sonargraph, Structure101, Architecture-Quality-Evolution, JDepend, Designite, SonarQube, SonarLint, Archie, Glasnostic, CodeScene, and CAST (Li et al., 2021). The practices mentioned include DSM, Software Composition Analysis, ACC, architecture monitoring, code review, architectural smell density trend analysis, and architecture visualization (Li et al., 2021).

Visualization work makes the temporal and structural character of degradation explicit. Getaviz uses a two-dimensional Recursive Disk metaphor, Tarjan’s algorithm for strongly connected components, min-max-normalized betweenness centrality computed with Brandes’ fast algorithm, and a 50% overlap criterion to track whether an antipattern instance across versions is the continuation of an earlier one (Baum et al., 2018). In four case studies with ten participants, the visualization was found useful for assessing which versions reduced quality the most, tracing where an antipattern started, following its evolution, and identifying likely refactoring targets (Baum et al., 2018).

5. Prediction and early warning

Predictive work turns degradation from a retrospective diagnosis into a forward-looking signal. In a study of 10 Apache open-source Java systems—Camel, CXF, Hadoop, Ignite, Nutch, OpenJPA, Pig, Struts2, Wicket, and ZooKeeper—across 466 versions and 1,398 architectural models, current architectural smells were used to predict future issue-proneness and change-proneness (Le et al., 2021). For issue-proneness, the average precision/recall was 76.2% / 74.4% with ACDC, 76.6% / 75.9% with ARC, and 69.4% / 67.4% with PKG; for change-proneness, the averages were 74.7% / 71.6% for ACDC, 73.6% / 73.5% for ARC, and 65.3% / 63.5% for PKG (Le et al., 2021). The high issue-proneness class under ACDC reached 79.6% precision and 85.9% recall, and even cross-system models trained on unrelated systems remained about 50% better than the balanced three-class random baseline of 33.3% (Le et al., 2021).

Dependency-based anticipation addresses an even earlier stage. A link-prediction approach models the module structure as a dependency graph $DG(V,E)$ and uses topological features such as Common Neighbors, Adamic-Adar, Resource Allocation, Sørensen, Kulczynski, Relative Matching, and RusselRao, together with content-based Cosine Similarity, to predict likely future package dependencies with an SVM with RBF kernel (Díaz-Pace et al., 2018). These predicted dependencies are then filtered to infer likely future instances of Cyclic Dependency and Hub-like Dependency, enabling smell anticipation one version ahead in Apache Derby and Apache Ant (Díaz-Pace et al., 2018).

Text mining offers another early-warning channel. A protocol for automatically identifying architectural violation symptoms from textual artifacts—code comments, issues, commit messages, and code reviews—proposes ML, DL, and NLP pipelines and reports a pilot on OpenStack code reviews using SVM, Logistic Regression, Decision Tree, Linear Discriminant Analysis, Bernoulli Naive Bayes, and k-Nearest Neighbor (Li et al., 2022). With a pre-trained software engineering word embedding model based on Stack Overflow, SVM and Logistic Regression tied for the best pilot performance at $F1 = 0.842$, $P = 0.889$, and $R = 0.800$, supporting the feasibility of automatic warning detectors from developer text (Li et al., 2022).

Microservice studies make temporal evolution explicit. A temporal-network summary paper argues that microservice architecture should be analyzed as a service dependency graph observed across releases, commits, or traces, and points to temporal centrality, temporal community detection, temporal state detection or interval clustering, temporal clique mining, and SIS diffusion simulation as relevant methods (Bakhtin, 15 Aug 2025). Its strongest empirical constraint is data scarcity: the most complete temporal network available had only 7 time instances and 42 microservices (Bakhtin, 15 Aug 2025). A companion study on train-ticket reconstructed 7 releases and derived Centrality Change Proneness from normalized First-Order Mover quartiles, finding 7 size metrics and 5 complexity metrics with consistent correlation to temporal centrality, while Centrality Change Proneness did not affect the software metrics, thereby providing “yet another perspective” and an early indicator of microservice architectural degradation (Bakhtin et al., 9 Jun 2025).

6. Repair, prevention, and governance

Repair strategies differ in whether they target architecture, implementation, or both. An architecture-centric evolution model structures control into four phases—Evolution Analysis and Validation, Architecture Evolution, Change Implementation, and Architecture Assessment—and requires consistency checks both before and after change implementation (Farid et al., 2011). It also defines a risk/urgency matrix whose prescribed actions are explicit: indices 1A, 1B, 1C, 1D, 2C, 2D, and 3D require first updating architecture and then modifying implementation; 3C requires decision according to business and mission goals; and 2A, 2B, 3A, and 3B require first modifying implementation and then immediately performing architecture evolution (Farid et al., 2011).

A more general proposal argues that implementation-only repair is insufficient and advocates joint architecture and implementation repairing (Knieke et al., 2021). Its workflow comprises Violation Cause Detection, Cause Repair Action Planning, and Repair Action Execution, all supported by a project-specific knowledge base that stores generic architecture knowledge, past violation patterns, underlying causes, successful repair action sequences, and system-specific exceptions and refinements (Knieke et al., 2021). The key principle is cause-based repair: recommendation is not made from a raw violation alone, but from the inferred underlying cause and the associated repair sequence (Knieke et al., 2021). The same work explicitly allows backtracking, architecture repair through $S$0, implementation repair through $S$1, and iterative learning from accepted or rejected recommendations (Knieke et al., 2021).

Automatic realignment has also been explored as a proof of concept. A reconstruction-and-refactoring framework for Java distinguishes conceptual architecture, physical architecture, and their reflexion-model relation, reconstructs a layered conceptual architecture using greedy initialization and steepest-ascent hill climbing, and then migrates code using Move Method, Move Constant, and Exclude Parameter transformations (Schmidt et al., 2014). In its Solution Quality function, dependencies that can be resolved automatically are weighted by 0.25, whereas non-resolvable violations are weighted by 2.0 (Schmidt et al., 2014). On a small self-developed Java MVC system with 15 implementation units and 10 injected violations, the migration process reduced architecture violations over the first five generations, although the reported quality metric did not show a clear improvement trend (Schmidt et al., 2014).

Preventive practice extends beyond technical repair. The systematic mapping study identifies architecture conformance checking, architecture monitoring and evaluation, establishing traceable mechanism, evolving architecture as changes occur, and explicitly defining architecture as preventive measures; architecture maintenance and architecture restoration as remedial measures; and architecture refactoring, visualization, and management optimization as both preventive and remedial (Li et al., 2021). Practitioner studies add architecture assessment, periodic maintenance, architecture simplification, architecture restructuring, organization optimization, and, in severe cases, restarting a project or rewriting architecture from scratch (Li et al., 2021).

7. Broader uses in computational and physical systems

Outside software architecture, the term is used for degradation induced by architectural change in machine-learning systems. In recurrent spiking neural networks, architectural evolution is explicitly treated as risky because structural changes and synaptic weight changes may be misguided due to discontinuity in the search space and limited training data, which can lead to overfitting, instability, and reduced accuracy (Zhang et al., 2021). The proposed response is a modular Sparsely-Connected Recurrent Motif Layer and a Hybrid Risk-Mitigating Architectural Search procedure with a two-step alternating optimization process: gradient-based updates of architecture variables and weights, followed by intrinsic plasticity as a “self-repairing” mechanism (Zhang et al., 2021). On TI46-Alpha, the HRMAS-optimized 800-neuron SC-ML RSNN reached 96.44% accuracy; removing intrinsic plasticity reduced it to 95.20%, removing inter-motif connections reduced it to 95.73%, removing motifs reduced it to 88.35%, and a fully connected RSNN achieved 94.10% (Zhang et al., 2021).

Low-rank transformer compression uses “degradation” in a related but more quantitative sense. A 2026 study defines compression-induced architectural degradation at the matrix level and identifies the interaction term $S$2—compression ratio times layer-aggregated stable rank—as a robust predictor of accuracy degradation (Xu et al., 20 Apr 2026). Under leave-one-out cross-validation, this predictor achieved Pearson correlations of 0.890 for attention layers and 0.839 for MLP layers, and the analysis attributes the difference to distinct error-composition mechanisms: matrix-product perturbation bounds dominate in attention, whereas Hadamard-product interactions make MLP degradation more data-dependent (Xu et al., 20 Apr 2026). In this usage, architectural degradation is not divergence from a prescriptive design but predictable performance loss under architectural compression (Xu et al., 20 Apr 2026).

A contrasting interpretation appears in degradable morphing devices. “Degrade to Function” defines a design strategy in which environmentally triggered sequential degradation is the operating logic of an eco-friendly, self-contained morphing device rather than a failure mode (Lu et al., 2024). Responsive components are intended to degrade faster than substrate components, and transformation occurs when the degrading constraint can no longer withstand the resilience force of the energy-storing substrate (Lu et al., 2024). Here, controlled degradation is architected deliberately, showing that the term can refer either to unwanted deterioration or to programmed functional change, depending on whether the architecture’s purpose is preservation or transformation (Lu et al., 2024).

Across these domains, architectural degradation remains a temporal phenomenon. In software systems it is primarily a divergence and sustainability problem; in neural systems it can be an instability and performance problem under architectural evolution or compression; and in degradable physical systems it can be a programmed sequence of transformations. The shared research problem is not the mere presence of change, but how change alters structural integrity, function, and the ability to evolve.