Architecture
Technical Debt vs. Architectural Debt
Distinguishing local code friction from system-level constraints helps teams invest in the changes with the greatest leverage.
Different debt changes work differently
Technical debt often appears in a bounded implementation: duplication, missing tests, confusing code, or outdated dependencies. Architectural debt affects system boundaries, ownership, deployment, data flow, and the ability of multiple teams to change software safely.
Prioritize constraints, not aesthetics
Debt matters when it increases risk, slows valuable change, creates operational incidents, or makes essential knowledge scarce. Measure its effect on delivery and operations instead of treating every imperfect implementation as equally urgent.
Match the intervention to the level
Local refactoring can address technical debt. Architectural debt may require new boundaries, migration sequencing, interface changes, or organizational ownership decisions. A useful roadmap makes these dependencies explicit.