The recent collapse of Carillion reminded all of us of the dangers of debt. Apparently, its debts grew by more than 50 percent in its last four months of trading, and it also had a huge pension deficit. However, another type of debt can be just as insidious – technical debt for IT systems and services.
We hear about examples in the NHS, where systems that hadn’t been upgraded for years were caught up in last year’s ransomware attacks, and we see it regularly at customers who have minimised IT investment over the past few years or are tied into outsourcing contracts supporting outdated IT systems that no longer meet their needs.
I was interviewed by a journalist on this topic a couple of weeks ago – incidentally while away on holiday, illustrating that when you run a business you’re never out of reach.
The interview reminded me that it’s becoming a growing problem, as most businesses are now dependent on technology for critical business functions. But, like financial debt, it’s something that people don’t want to talk about, as they don’t want to admit that their organisation might be falling behind.
For most organisations, technical debt is the accumulation of a series of business decisions, normally taken in isolation. Each was perfectly valid at the time but was frequently made without considering its effect on other systems and an organisation’s overall IT architecture, creating an unnecessarily complex IT infrastructure.
This limits performance, scalability and particularly agility – a major problem in today’s fast-changing digital world. It also takes a lot of internal resource and cost to maintain and manage.
Organisations are frequently dependent on bespoke or heavily customised applications that do the job but are complex and difficult to change and become ‘part of the way we do things round here’. They don’t make it onto the radar until they fail spectacularly, or you try to migrate them to your new operating system, by which time the person who implemented them is long gone and you find that they’re written in outdated code on an obsolete platform.
Another aspect of avoiding technical debt is spotting where an undocumented script, work-around or quick fix could become a liability, by ensuring well-enforced change control and management processes.
We’ve benchmarked this across a range of organisations and found that by optimising their IT infrastructure, replacing or upgrading outdated legacy systems and managing licensing and capacity most organisations can save up to 25 per cent of their annual IT budget. It’s a significant saving, and something well worth exploring.
As with financial debt, the first step is to understand the problem. Your IT team and systems are there to serve the needs of the business – they are not an end in itself. Review and work out what services your business 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.
Once that’s done, understand which services can usefully be provided via cloud, which are better off outsourced to a third party, and which to retain in-house.
As a replacement for a bespoke system running on an outdated operating system, which was costing them a considerable sum in both third party maintenance and in-house staff to support it, one of our customers took the approach of asking us to implement a replacement based on commercial, off the shelf software as much as possible.
Whilst they had to make minor changes to existing business processes to fit the way the new application worked, they gained significantly increased functionality, plus easier, simpler and cheaper integration with complimentary applications.
They have also minimised their potential for complications and made it much easier to keep up to date as well as ensuring it can easily be supported by third parties. Minimising the need for bespoke IT is a very effective way to reduce the risk of technical debt.
Another customer, an engineering joint venture working on one of the enabling contracts for HS2, decided that cloud was the best route to take. Each of the companies in the joint venture had different IT systems, making collaboration difficult.
Rather than create something bespoke, which would have to be maintained and updated, they decided to have a dedicated Office 365 domain for the project in the Microsoft cloud. They simply have to pay for what they use, while users always have access to the latest version of all the Office applications and receive updates as soon as they’re released.
Every organisation will have different business needs and require different IT solutions. Some legacy systems may be unavoidable, but the more you can standardise and simplify, the lower your risk of falling into technical debt.