Architectural Debt
Structural compromises that increase the cost of all future change, distinguished from code-level debt by being expensive and slow to repay.
Code debt is local: a badly written function can be rewritten in an afternoon. Architectural debt is structural — a wrong boundary, a shared database, a synchronous chain, a missing abstraction — and repaying it means a migration.
The distinguishing property is that the interest is charged on everything. A wrong service boundary means every feature crossing it costs coordination between two teams, forever, and the cost grows with the number of features.
Recognisable forms: services that must be deployed together; a shared database several services write to; a component every change touches; a synchronous chain where an asynchronous boundary belongs; and a framework or platform choice the organisation has outgrown.
Making it visible is the hard part, because it appears as diffuse slowness rather than as a defect. Useful indicators: change failure rate and lead time by area, the number of teams required to ship a typical feature, and the proportion of incidents traced to the same structural cause.
The management approach that works is incremental repayment attached to feature work — a strangler migration advancing with each change in that area — rather than a proposed rewrite, which competes with delivery and loses.