I read an article recently that talked about a mobile app that was failing to realise its potential as it was saddled with a large amount of technical debt; a term used to describe the consequences of poor architecture or design decisions within the codebase of an application. Quite often these arise as a result of time or cost pressures that lead to quick fixes or short cuts being taken in the coding process, which may meet the immediate need but can create problems in the future. And so, just like financial debt, technical debt incurs interest in the form of the extra time and cost required to support and develop the application in the long-term.
The financial analogy continues as you can choose to pay down the debt through proper design and re-coding of the application or you can continue with the interest payments of additional support and development costs. And, as with money, some technical debt is not necessarily a bad thing, if it helps you achieve a certain goal at a price that is worth paying, and you have the means to pay it off at some stage in the future.
In the case of the mobile app, the development team tasked with making it work had no choice but to pay down the debt by rebuilding the app from the ground up. An expensive option but in their view the only viable one, as the ongoing cost of servicing the technical debt was just too high.
The concept of technical debt doesn’t just apply to applications; it can also be applied at an organisational level. A history of under-investment, no strategy or roadmap, poor prioritisation, etc. lead to short-term and tactical solutions becoming the norm and create technical debt on an enterprise scale. And just like the application example above, enterprise technical debt also compounds, the ongoing development and support of a dated platform or one that has evolved in a piecemeal way, becomes increasingly complex, risky and expensive.
Delaying an upgrade or the replacement of a platform doesn’t just delay the expenditure; it increases the cost and risk of change. As both cost and risk increase, organisations are more likely to delay the investment further thereby compounding the problems and further increasing the debt. Faced with an ageing infrastructure, systems based on dated technology, tactical quick solutions can actually become more attractive and so the enterprise technical debt level escalates.
The concept of debt can be extended to the wider organisation. Failure to invest in your people, for example, will create a skills or capability debt. Having failed to develop new skills, attitudes and behaviours, change initiatives are more likely to fail, prompting tactical management action or quick fixes (usually through measures such as additional controls, increased checks or just plain telling people what to do).
If IT departments do not invest in new skills or acquire knowledge of new technologies they are likely to come up with the same type of solutions, based on the same technologies as they have done in the past. This could in itself create technical debt. In an organisation where technical debt already exists it will compound this further; different forms of debt combine together and if left unchecked can very quickly create a debt crisis. And in my experience IT organisations that have one type of debt are very likely to have the other.
It’s worth restating that technical debt, whether at an application or enterprise level, is not necessarily a bad thing. During a economic downturn it becomes a useful and in some cases an essential way of controlling or reducing costs. The same is true for the various forms of organisational debt; training is usually one of the first things to be cut when budgets get squeezed.
But the decision to incur this debt should be a conscious and considered one, taking into account the hidden costs, additional risk and potentially higher cost of a delayed investment. This is something CIOs should be working to quantify and explain. Budget freezes or cuts are inevitable, IT expenditure cannot continue to rise year-on-year regardless of how the organisation or economy is performing. At such times CIOs and their teams should be identifying areas where technical debt can be incurred in a manageable and sustainable way, including the maximum period for which that debt can be serviced before it becomes uneconomic and the delayed investment necessary.
More challenging though is when technical debt is caused by a lack of business strategy, making an IT strategy and roadmap impossible, or where poor governance results in excessive demands or the wrong investments being prioritised. This is where the CIO’s leadership and influencing skills are called upon. In my post What do you mean you don’t have a strategy? I explained why the absence of a business strategy can be an opportunity for the CIO to prompt, facilitate or even lead their C-suite colleagues in developing the business strategy. Given the long-term impact of enterprise technical debt it could be argued that it’s the CIO’s duty to take this opportunity so that their organisation does not face a debt crisis.