By Stuart Dee
IT Architects are constantly confronted with legacy, whether as a result of poor lifecycle management, sweating the assets, a change in standards, policies, principles, or strategic direction. The impact is commonly referred to as “Technical Debt” but as with everything in architecture, it means different things to different stakeholders.
Senior stakeholders, particularly those without an IT background, often become disinterested when they encounter the term “technical” or respond as if it is a subject that does not concern them. For the IT literate, everyone has their own ideas on what it means and Enterprise Architects who sit between the business and technology have difficulty quantifying the cost of the debt and obtaining the budget to address the issues.
This is understandable given the term’s historic definition and if you look at the Wikipedia entry, for example:
“Technical debt is a concept in Software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.”
Since Ward Cunningham coined the term “technical debt” in the 1990s and from the definition we can deduce it is talking about code debt that developers had to create due to market and delivery pressures. Also, code review tools are sophisticated enough to calculate the technical debt ratio, but the point is code debt is only part of the story.
So initially, how do we address the “Technical” part of “Technical Debt”?
Perhaps we should rename it Architectural Debt or even Organisational Debt? From an Enterprise Architecture standpoint, we talk about “People, Processes, and Technology,” all of which contribute to the debt over time and form a more holistic view of the real debt. It does not matter what it is called as long as there is consistency within the organisation and it has been defined, agreed and communicated.
We have briefly discussed one aspect of technology, namely software, but what about infrastructure: outdated hardware, operating systems, firmware, patches, data, and so on?
Data is important in everything we do, but it is often overlooked. The absence of master data management, quality, data lineage, and data validation all contribute to data debt.
People debt is caused by having to support out-of-date assets (software and/or infrastructure), the resulting deskilling over time and missed opportunity to reskill which all potentially leads to employee attrition.
Processes requiring modification can become dependent on technology due to the high cost of change, or the alternative of adjusting the design to accommodate poorly designed processes. While Robotic Process Automation (RPA) can provide a rapid solution in such cases, it raises the question of whether the automation simply perpetuates flawed processes without addressing the underlying issue. That is a topic for another time.
It is even possible to go a step further and consider other types of debt, such as application debt, documentation debt, test debt, and requirement debt.
I often hear stakeholders say, “Ah yes, we have technical debt and it is difficult to quantify it” and that normally ends the conversation with everyone frustrated as there is no simple answer.
I read this book called “How to Measure Anything: Finding the Value of Intangibles in Business” by Douglas Hubbard which led me to believe with a bit of time and thought one can put together high-level models for calculating debt. As it happened as part of my work, I was asked to provide a debt model against architectural dispensations to track the costs at governance and use in business cases.
Project managers know their costs, whether implementing the correct solution or an architecturally non-compliant solution. If you know those costs you can add some general factors for people and process debts. The final piece of the puzzle is to use an interest rate formula that considers debt growth over time.
The most common question I get about this is, “How do I quantify the time period to calculate the debt?”
Three scenarios can be used to apply a time period to the calculation:
- A strategic replacement program implemented on a future date will remediate the debt
- A dispensation period granted through governance will provide the time until remediation
- Use of an arbitrary period, such as three to five years
When you tell stakeholders you have a model for calculating debt, it is amazing how quickly they become interested and to some extent, relieved. It is the fact that they finally have a financial way of expressing debt when it seems so intangible!! In the worst-case scenario, they have a key indicator: rising debt, which they can compare to the cost of short-term delivery gains. Additionally, it provides some indicators for future enterprise portfolio planning.
A McKinsey survey on tech debt (50 CIOs surveyed from Financial Services companies with revenues greater than £1 Billion – July 2020) stated: –
” CIOs reported that 10 to 20 percent of the technology budget dedicated to new products is diverted to resolving issues related to tech debt. More troubling still, CIOs estimated that tech debt amounts to 20 to 40 percent of the value of their entire technology estate before depreciation.”
With the continual focus on costs in organisations as architects, we should be considering them from a solution and remediation perspective. When calculating the total cost of ownership, if debt were included it would give a more accurate figure on how much something is costing and provide a stronger case as well.
When creating a model for debt, it is all about setting expectations and I always begin with the following:
- It is a starting point for discussion
- It is a simplistic model that can be improved over time
- It is subjective and the assumptions can be stated in the model
I believe it is better to have something committed to paper whether a diagram or textual or both, rather than just talking about it because it can always be modified and it is a focal point for stakeholders.
In helping to provide information for budgeting to address debt remediation, as architects, we are unlocking the ability to continually innovate and provide a competitive advantage. On many occasions, I have heard the term “Shackled by debt.” This will stop innovation dead in its track if left long enough resulting in the cost of change becoming prohibitive and the impacts of any risks increasing. To summarise and coin a phrase:
“Debt remediation enables innovation”
If you are not already calculating debt, it may be worth considering constructing a model and like all things it will take some time to mature. However, it is possible to calculate the current and future debt position and help persuade stakeholders to adopt a more comprehensive view and understand its impact on the organisation.