By Paul Preiss
Many of you who read my blog will raise your hand when I ask who owns a home. But when I ask who really owns a home, most of those hands will go down. Why? Because banks and mortgage companies own homes. You are just in dept to them. And yet we dont all run around screaming about how unhealthy your mortgage is… unless it is.
If you want to understand this and other critical architectural techniques join our Architecture Core Class at https://www.iasaglobal.org/core-architecture
The thing that makes a mortgage healthy is whether a) you got it on purpose, b) you can afford it, and c) you have a repayment schedule which you meet on time. This is the concept of healthy debt. And while I believe much of our technology stack still has plenty of unhealthy debt and dangerously unknown legacy, still if we can begin framing our debt as serviced and healthy it will allow us to focus much better on the unhealthy debt.
When technical debt is inevitable, how do you ensure it’s both deliberate and prudent? The BTABoK introduces the “Technical Loan Request” framework—a brilliant approach that transforms vague “we’ll fix it later” promises into structured commitments.
Just as you wouldn’t take a financial loan without understanding the terms, technical debt shouldn’t be incurred without clarity on its implications and repayment plan.
The Technical Loan Request canvas documents:
- Business justification for the debt
- Architecture components impacted
- Specific architecture impacts (evolution, quality, maintainability)
- Debt characteristics (reversibility, effort to undo)
- Concrete “undo actions” required
- A formal repayment schedule
This approach forces crucial conversations between architects and product owners about the true cost of shortcuts. It makes technical debt visible to stakeholders and creates accountability for its resolution.
By treating technical debt as a formal loan rather than an invisible burden, we shift from reactive firefighting to proactive management. The Technical Loan Request connects technical decisions to business value, roadmaps, and risk management.
https://iasa-global.github.io/btabok/technical_debt.html
Have you implemented a structured approach to technical debt in your organization? What would change if every architectural compromise required a formal “loan application”?