Technical debt is a common problem. It isn’t a question of using the latest version of a desktop operating system, but rather the gradual building up IT problems that will come back and haunt organisations in the future.
The term technical debt 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 needed as a result of the choices made
It is possible to either pay down the debt by tackling the problem head-on or keep paying the interest. Eventually, there is the point where a system becomes so expensive and/or difficult to maintain that it has a serious impact on a business.
Here are some of the common causes:
- The Vampire (leeching resources) - being tied into an outsourcing contract that no longer meets current needs and takes up a significant amount of your budget. This could even be a new contract, as poorly configured cloud services can also quickly drain resources.
- The Frankenstein Application (the monster your organisation created) - being dependent on a bespoke or heavily customised application that’s difficult to change and certainly can’t be moved to public cloud as it is.
- The Ghost of IT Past (almost forgotten will come back to haunt you) - using an application written in a language where skills are in short supply and the only expert is about to retire, or a database that’s no longer supported by the vendor.
- The Undead OS (one day it must surely die) - when the operating system has eventually reached end-of-life, but the core application hosted on it isn’t compatible with the new version.
- The Zombie (needs brains to function) - an undocumented script, work-around, or quick fix that once solved a problem has become a liability and is taking a lot of time to manage.
The solution, as with any other type of debt, is to work your way out of it slowly and steadily, while managing the risk. Start by evaluating the services your business actually needs (not that it thinks it wants), then decide what systems you need to support them and what you can consolidate, simplify, or turn off. A business and IT alignment review will help clarify what’s truly essential.
Once that’s done, consider which of the services that are draining resources is creating the most risk to your business. That’s the one to tackle first. Now it’s time to consider which services can usefully be provided via cloud and which to retain in-house. Some legacy systems may be unavoidable, but why not ask a managed service provider to look after them and take responsibility for patching, security, etc.? They will still be ‘in the cloud’, but someone else is handling the day-to-day activities. This will free up in-house time to look for a longer-term public cloud solution.
The only thing that’s certain about technical debt is that ignoring it will only make the problem worse. If you need advice, we’re here to help. And whatever your concerns, I can guarantee that we’ve seen much worse elsewhere – and found a solution!
