Technical Debt Metaphor
The essence of the metaphor is, when you are faced with a design choice with a quick and dirty solution as one option and a more appropriate, but perhaps more expensive alternative, picking the former option is like borrowing money. As with financial debt, you will likely pay interest along the way and ultimately pay the prinicple in the future. The interest is the pain the team feals each time a change must be made to the quick and dirty solution. The principle is paid when a proper solution is finally implemented.
I think most people clearly understand this trade-off. Where I find the problem lies is in valuing the debt. So, how many times will we have to change this thing? How much difference will it make? How frequently will it fail as a result? Is your proper solution really better than the quick and dirty one?
In order to make an informed decision about the trade-off between higher up front cost and the technical debt, we really do need to know the valuation. The up front cost is generally well know and expressed in dollars and time to market. The debt is expressed in qualitative terms like, error prone, hard to maintain, etc…
Applying the metaphor to Enterprise Archtiecture
Here Charles Edwards applies the technical debt metaphor to enterprise level as the Enterprise Technical Debt. He goes on to say that if you could explain this to a business executive in these terms, you’ll be well on your way to justifying investment in enterprise architecture.