Architecture erosion is the slow gap that opens between the design as described and the system as it now is. Nobody decides to cause it. It accumulates from changes that were each individually reasonable: a shortcut across a boundary because the proper path was slow, a component that grew a second responsibility, a dependency added in a hurry, a queue bypassed by a direct call. Each is small, none is announced, and the diagram stops being true without anyone noticing. Because the drift is invisible per change, catching it needs something scheduled rather than something noticed. Two things catch it. A cadence: a periodic review that compares the current system against the decisions of record and asks which of them are still true, which have quietly been reversed, and which assumptions have expired. And a trigger: events that oblige a review out of sequence, such as load passing the figure the capacity plan assumed, a new quality requirement, an incident, or a dependency being deprecated. The output is not a document; it is a short list of differences, each either accepted and written down as the new decision, or scheduled for repair. You can now say when a design will next be checked, and what would force that check to happen sooner.
Software architectural degradation is the deviation between prescriptive architecture (a system's designed structure) and descriptive architecture (its actual, as-built structure), classified along a…