Last Wednesday we had an excellent and very interactive webinar discussion with David Sisk and Scott Buchholz, Directors at Deloitte Consulting, LLC. David and Scott are experts regarding technical debt -- both at a technical hands-on level as well as the strategy and governance topics in IT. So, we talked about the symptoms and causes of technical debt in large IT environments, as well as the organization and processes that need to be put in place in order to reverse the normal trend of technical debt accrual.
One of the topics that came up a lot is how to get the business onboard. Our guest presenters gave us some very interesting approaches to making the case, even when the immediate symptoms of the debt are not evident to business stakeholders. I think this discussion by itself is valuable to listen to.
Another topic that came up a lot in the Q&A was different ways of asking how to set up a technical debt measurement program. As in our last webinar, we wound up going a couple minutes over our timeslot to address some of the questions, but we had to leave many unanswered due to time. The goal here is to try and answer some of those questions in our blog. If anyone wants to get into a more detailed discussion on any of these points, please contact us and we’ll be happy to talk to you. So, here goes:
There were a number of questions about this topic, asked in different ways. This is a topic onto itself and I believe we should organize a webinar to talk only about this -- perhaps later this year. We’ve seen some best practice already in this regard, so we could share some anonymized dashboards and reports, as well as some process examples. Suffice it to say, the outlines of such a program should include automation for consistent measurement of technical debt, a process that denotes a consistent set of points at which technical debt is actually measured, and reporting for senior IT and business stakeholders with actionable data that can be affected by management.
Quite naturally, one of the reasons we were interested in hosting this webinar is that CAST provides technology for estimating technical debt and for measuring it precisely in a continuous manner. CAST’s Highlight rapid portfolio analyzer provides a quick code-scan based estimate of technical debt, along with measures of software size, complexity, and estimated technical risk. CAST’s Application Intelligence Platform is capable of precise measurement of technical debt that can be benchmarked to industry standards and trended from release to release, knowing that the measure is reliable enough to put in a sourcing contract.
There are other tools in the market that estimate technical debt, which you should be able to find easily. The only caution I would provide is whether the measure is consistent enough for trending, and whether you can dissect the technical debt into items that are very risky vs. simple hygiene. Those of you who asked for “rigorous” and “repeatable” measures of technical debt have clearly experimented with some of the simple tools available in the open source.
There is a lot we can say in response to this question. To offer a perspective, in our experience this has to do with three key elements of the technical debt measurement program: analysis depth, prioritization, and controls.
Inherently, the total cost of ownership (TCO) of an application and its technical debt are two different things. TCO typically includes maintenance cost, operating cost, and some will also include enhancement cost. Strictly speaking, technical debt is the cost of development or architecture effort that would be required to bring an application to a healthy state. Though these are different concepts, TCO is something that is very much driven by the amount of technical debt that accrues in an application.
According to Gartner, for typical project work the cost of development is 8% and the rest of the TCO is 92%. That means for an average project, the organization spends $92 in TCO for every $8 spent on the project to build that functionality. So, if that project has more technical debt than average, then the $8 of functionality could cost much more than the $92. Some of the technical debt has higher impact on TCO than other technical debt. We have some models here at CAST that show the percent impact.
This concludes our answers to some of your questions. There were more questions asked, on which we will get back with you individually. There are also some threads of discussion, about technical debt prioritization, governance, and measurement on which I’m sure our colleagues from Deloitte will have much to contribute -- perhaps a future blog post. Please send us comments and let us know if this would be of interest.