APPLYING THE BRAKES TO THE RUNAWAY TRAIN OF TECHNICAL DEBT

In 2008 the hubris of the financial sector that we serve finally caught up with itself.  Mountains of consumer debt that had been packaged, re-sold and deferred turned out to be unserviceable and the whole edifice came tumbling down.  Now commentators are asking whether any lessons have really been learned as consumer debt in some western economies starts to climb again.

I think there are parallels in the technology business that underpins financial services.  In the years after 2008, many financial institutions deferred system upgrades and application refreshes as they struggled to rebuild capital.  But it is clear that technical debt compounds over time just like financial debt.  The compounding of technical debt leads to ever increasing costs of maintenance and compliance, reducing the money available for new business change.

However, at the same time as the technical debt increases, financial institutions face increasing competitive pressure that forces them to manage change in their business systems at ever increasing speeds.   The only way to fund that business change is to defer yet more technical debt.  I do not believe that this is sustainable.

At the same time as they accelerate change to achieve competitive advantage, these organisations are aware that high profile system failures increasingly cost them huge sums, both in lost revenue and in the negative impact on market capitalisation.

These failures occur because organisations defer testing to meet deadlines, thereby accepting an ever-increasing technical debt due to their inability to properly test their business systems. Parasoft published statistics gathered over a 6 year period that showed average impacts on market capitalisation of system failures.  (https://blog.parasoft.com/continuous-testing-business-value) These drops in valuation are increasing steadily….

In the medium term, the resolution to this technical debt requires the replacement of 20 year old applications designed for the pre-internet era.  But to be able to make such replacements, in the short term, organisations must regain control of their applications and mitigate the risks associated with their technical debt.  The short-term objective must be to improve the “real stability” of the application through improved quality assurance processes.

This is different to the “perceived stability” that is used to reassure CEOs, which is based on freezing or minimising application change.  Instead, “real stability” is when an organisation can confidently change its application and release it to production with confidence that the new release will function as planned.

Only when “real stability” is achieved can an organisation begin to contemplate the long sequence of change programmes associated with the replacement of a mission critical application.

Organisations should act now and begin addressing their technical debt, to avoid the impending crash.