Use Architecture to Reduce Technical Debt

by Mike Rosen

April 2014

All the talk in the press lately about sovereign debt got me thinking about another kind of debt near and dear to an architect. That is the ‘technical debt’ that we have in our IT systems and enterprises.

So what is technical debt? Steve McConnell describes it as: “Technical Debt refers to delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules. Just like financial debt, some technical debts can serve valuable business purposes. Other technical debts are simply counterproductive.”

Another good definition comes from Martin Fowler: “Doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.”

Although these definitions focus on the development of new software, technical debt accrues in systems as we maintain and evolve them without spending the time to refactor them to accommodate the changes. Over time, this builds up fragile systems that can’t be changed, and can’t accommodate the evolving business requirements. So, the cost of technical debt isn’t simply the cost to fix it, it is also the cost to the business of inflexible and fragile IT systems that can’t be changed to meet current business needs, and the lost opportunities they presents to the enterprise. We all probably have a few systems like that.

A fair amount of work has gone on to quantify the cost of technical debt. For example, Sonar has a product that will calculate debt. (see http://www.sonarsource.org/evaluate-your-technical-debt-with-sonar/). In their calculation, debt = cost_to_fix_duplications + cost_to_fix_violations + cost_to_comment_public_API + cost_to_fix_uncovered_complexity + cost_to_bring_complexity_below_threshold. This definition is clearly focused on the cost to fix the debt, not the cost to the business in terms of lost opportunities, because of the debt. Another very detailed description of the cost of debt is provided in “An Empirical Model of Technical Debt and Interest”

Technical debt comes in two basic forms: unintentional and intentional. Unintentional debts generally result from poor coding or project management practices. Intentional debts, on the other hand, are incurred based on explicit decisions. One of the sources I saw called these ‘informed’ decisions, but I wonder how much the executives, business, or IT management really understands in terms of the impact of their decisions on enterprise technical debt.

Technical Debt includes those internal things that you choose not to do now (unintentionally, or intentionally), but which will impede future development if left undone. This includes deferred refactoring and ignoring architecture and standards. Technical Debt does not include deferred functionality.

In all the reading I did on technical debt, I didn’t see any references to architecture and I think this is a serious omission. One of the goals of architecture is to avoid unnecessary costs and complexity (and hence technical debt). How does architecture help with this? Architecture sets standards for platforms, data, security, and many other things. Not following the standards results in inconsistencies, redundancies, and additional operational costs, all a kind of debt that will either continue to incur interest, or require expenditures to pay down the principle.

Architecture helps to address complexity, especially the complexity at the enterprise level (rather than the individual project level). Enterprise complexity results in technical debt in terms of system integration, and system redundancy and inconsistency. Again, all forms of technical debt. One more example, architecture helps to ensure alignment of systems with business goals and strategies and to avoid the costs of unaligned systems.

So, architecture can help to address many of the factors that are identified in the cost calculations (duplication, violations, complexity). Or, on the other side of the coin, we can use the cost calculations of technical debt to quantify some of the value of architecture in terms of debt reduction and cost avoidance. Hopefully, we’re better at dealing with this than the government.