Magazine Button
Why CIOs should be discussing the potential of technical debt

Why CIOs should be discussing the potential of technical debt

InsightsTop Stories

Richard Blanford, Managing Director, Fordway, discusses the risks of technical debt and the effect it can have on your business. He talks about the importance of standardising and simplifying IT systems to avoid the detrimental effects of technical debt.

We often hear about the problems of financial debt, but in business another type of debt can be just as insidious – technical debt. This occurs when some of the key IT systems and applications that an organisation relies on every day become increasingly out of date but are not replaced as long as they continue working. Although the rapid pace of IT development means that it is affecting an increasing number of organisations, technical debt is rarely discussed by business leaders as nobody wants to admit that their organisation might be falling behind. However, the risks of remaining in technical debt are substantial and the longer it is ignored the worse they become.

How technical debt arises

Technical debt can arise for many reasons. We regularly see examples at organisations that have had limited IT investment for several years, or are tied into long outsourcing contracts for outdated systems that no longer meet their needs. In extreme cases, the cost of upgrading is so great that a decision is taken to keep running the old system as long as possible, which is what happened with many Point of Sale systems that relied on the Windows XP operating system.

Another common cause is when an organisation has become dependent on bespoke or heavily customised applications, or uses an application written in a language where skills are in short supply, such as COBOL, or a database that is no longer supported, like Ingres. Sometimes we find that a department ran its own tender and chose a specialised solution independently from the IT department, which was best of breed at the time, but came from a small software company which no longer exists. These applications continue to run, unchanged and unchallenged, until they either fail spectacularly, or the organisation tries to migrate them to a new infrastructure or to cloud, which either fails or is much more difficult than anticipated. By this time, the team who wrote or implemented the application are long gone and a closer look shows that it is written in outdated code on a proprietary, obsolete platform and documentation is either non-existent or has been lost.

However, technical debt is also a consequence of the speed of developments in the IT industry and this can take organisations by surprise. We think of technical debt as associated with ‘legacy IT’, but legacy no longer means old. Systems which once could have been relied on to last 10 years can now be out of date in just five. Take the Windows operating system: it is less than 10 years since Windows 7 was launched, but already many new laptops are not certified for Windows 7. This means that if the organisation uses an application developed in the last eight to 10 years which is coded to run on Windows 7, it has to carry out compatibility testing to ensure users with new laptops running Windows 10 can actually run the application.

The risks of technical debt

Continuing to rely on out of date systems and operate an unnecessarily complex, out of date IT infrastructure is both risky and expensive. Problems include reduced efficiency, because the system takes more effort to keep running and is unable to support new capabilities and changes, and incompatibility problems between existing and new hardware and software. If the debt is associated with bespoke code or obsolete hardware, the organisation may become dependent on an individual or small vendor, who can effectively hold it to ransom.

For organisations relying on software which is no longer updated or supported by the vendor, there is an increased risk of security breaches. An example is the WannaCry ransomware attack, which attacked a Windows XP vulnerability several years after Microsoft had stopped supporting and updating that operating system. It had a major impact on organisations around the world and particularly on the NHS. Its impact was so great that Microsoft actually wrote and delivered a patch for an unsupported OS – but this is unusual.

There is also a risk from the use of shadow IT, where staff bring in products and services not sanctioned by the organisation – and potentially insecure – in order to accomplish a routine task that official in-house systems will not support.

Tackling and preventing the problem

Ideally organisations should try to avoid falling into technical debt. Hence one of the key roles of a CIO is to constantly scan the horizon for changing technology and maintain a roadmap for future change, taking guidance from external experts and key suppliers. However, some problems cannot be foreseen, such as a major change in business direction, or a small specialised supplier being bought out and its products discontinued. Almost all of us will have to deal with it at some point.

This raises the issue of whether to use challenger brands, whose products may offer new capabilities or better value, but who may be at risk of takeover. Fordway has recently had to address this after a company whose product is important to delivering our Desktop-as-a-Service (DaaS) offering was taken over by a large corporation which owned a rival product and discontinued the product we had successfully used for many years and provided real value to our users and ourselves. It requires a considered decision to balance potential risk against reward.

The first step in tackling technical debt is to analyse the problem. CIOs need to work out what IT services their business actually needs, remembering that IT is not an end in itself, but is there to support the business and enable it to operate successfully. They can then decide what IT systems and applications are needed to support those services, what needs to be upgraded and what can be consolidated, simplified or even turned off. We are currently helping a public sector organisation define its upgrade roadmap and potential journey to cloud, helping it work out which services it can retire, which can be migrated to Software-as-a-Service (SaaS) or comparable services and which need to be upgraded or repurposed to make them suitable for cloud hosting.

One effective way to reduce the risk of technical debt is to minimise the need for bespoke IT and aim for standardisation across the organisation. This was the decision made by one public sector organisation we work with. It was running a bespoke system on an outdated operating system which was costing a considerable sum in both third-party maintenance and in-house staff to provide support. It asked us to help it implement a replacement based as much as possible on commercial, off the shelf software. Whilst it had to make minor changes to its business processes to fit the way the new application worked, it gained significantly increased functionality, plus easier, simpler and cheaper integration with complementary applications and considerable operational, and ultimately cost, savings. It has also minimised the potential for complications and made it much easier to keep up to date, while ensuring that its IT can easily be supported by third parties.

Reducing customisation also makes it easier to move applications to public cloud, as many application providers either already offer or are developing their SaaS strategy. At present, these may only support the latest version of their software, but legacy applications can be configured to run in private cloud, enabling an organisation using an older or customised version of an application to keep services running while they plan how best to upgrade.

Another organisation we work with, a joint venture between several large companies, chose cloud to avoid customisation. Each company had different IT systems, making collaboration difficult. Rather than create something bespoke, which would have to be maintained and updated, it decided to have a dedicated Office 365 domain for the project in the Microsoft cloud, with all other core applications provided as SaaS services. It simply pays for what it uses, while users always have access to the latest version of applications and receive updates as soon as they are 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 in the future.

Browse our latest issue

Magazine Cover

View Magazine Archive