By Mike Rosen
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.
Mike Rosen is Director of Cutter Consortium’s Enterprise Architecture practice and Senior Consultant with its Business-IT Strategies practice. He has more than 20 years’ technical leadership experience architecting, designing, and developing software products and applications.
Mr. Rosen was Chief Enterprise Architect at IONA Technologies, PLC, where he was engaged in the development of the overall product architecture for IONA’s next generation Web Services platform and in the creation of the reference architecture for building applications on that platform. Prior to joining IONA, Mr. Rosen was Chief Enterprise Architect at Genesis Development Corporation where he provided architecture consulting on large-scale applications and infrastructure for Global 1000 clients in insurance, finance, and telecommunications. While at Genesis, he led the development and formalization of a generic Enterprise Architecture and software development practices used throughout the company.
Before joining Genesis, Mr. Rosen was a product architect, technical leader, and developer for numerous commercial middleware products for vendors including BEA and Digital. His involvement in product development includes Web Services, Java, CORBA, COM, Messaging, Transaction Processing, DCE, networking, and operating systems.
Mike Rosen è Direttore per l’Enterprise Architecture con il Cutter Consortium e Direttore editoriale del SOA Institute. La sua attuale e importante attività riguarda l’implementazione di soluzioni SOA agili e flessibili. Ha molti anni di esperienza nell’architettura e design di applicazioni e più di 20 anni di esperienza nello sviluppo di prodotti per tecnologie distribuite come DCE, CORBA, DCOM, J2EE, Web Services, Transaction Processing e Messaging. E’ uno speaker di fama internazionale e autore di molti libri, tra cui ricordiamo “Applied SOA: Architecture and Design Strategies”. E’ stato Chief Enterprise Architect alla IONA Technologies dove era responsabile dello sviluppo dell’intera architettura di prodotto della piattaforma di Web Services di nuova generazione di IONA e della creazione della reference architecture per la costruzione di applicazioni su questa piattaforma.
Presenterà a Roma per Technology Transfer i seminari “Allineare Business e IT: un approccio Business Architecture” il 5-6 maggio 2014 e “Le scelte architetturali che funzionano” il 7-8 maggio 2014.