Fordway Blog

Solving the problem of technical debt

Written by Richard Blanford | Oct 2, 2018 11:32:48 AM

 

Is your IT team battling technical debt? I don’t just mean that you’re not using the latest operating system, but whether you’re gradually building up technical problems that are going to come back and bite you in the future.

Technical debt occurs when you implement technology in a way that might get you closer to your goal now but creates problems that you’ll have to pay for later. It was first used by agile development expert Ward Cunningham. He pointed out that doing things the ‘quick and dirty’ way might provide an immediate fix but will incur ‘interest payments’ in the future in the form of the extra development effort you have to make because you’ve made those choices.

We can either pay down our debt by improving the design or keep on paying the interest. Eventually, if you don’t address it, you’ll get to the point where a system becomes so expensive and/or difficult to maintain that it has a serious impact on your business. At that point, you have some major choices to make.

For most organisations, a key source of technical debt is the accumulation of individual business decisions taken over many years. Each was valid on its own but was made without considering its effect on the existing systems. The result is complex integration requirements and an unnecessarily complex IT infrastructure which limits performance, scalability and particularly agility.

This requires a vast amount of internal resource and cost to maintain and manage. We’ve carried out benchmark studies across a range of organisations and found that an optimised infrastructure can save organisations in excess of 25% of their annual IT infrastructure budget

The solution, as with any other type of debt, is to work your way out of it slowly and steadily. This means you should consolidate, standardise and simplify where possible. Start by evaluating the services your business actually needs (not that it thinks it wants), and then decide what systems you need to support them and what you can consolidate, simplify or turn off from what you have at the moment. Once that’s done, see which services can usefully be provided via cloud and which to retain in-house.

SaaS and PaaS may be helpful by providing you with a black-box service with a level of configuration that you can control, without getting into the infrastructural detail. You can then focus on the applications that really add value to your business, while a cloud provider looks after the infrastructure on your behalf.