As we continue to while away the hours in lockdown, we have been provided with the opportunity to reflect on some of the indirect issues revealed by COVID-19, including where the need to implement rapid business transformation has been hindered by the unforeseen consequences of historical IT technical management. One area that is very much worth discussing is ‘technical debt’.
An intro to technical debt
In computer programming, technical debt is “the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. This cutting of corners usually comes about as a result of decisions made under technical or time constraints, and while it can solve a particular problem at one point in time, the knock-on effects can build up huge gaps in the system or the code which have costly consequences further down the line.
Similarly, when it comes to the general evolution of your software estate, without proper attention to implication detail or if upgrades have been passed over one too many times, technical debt can accumulate massively. Indeed, businesses that rely on outdated systems – which can no longer be supported or properly secured by vendors – will find themselves with a huge bill to pay as the costs of maintenance and upgrades add up, and the gap between what an infrastructure should be and what it is in actuality continues to widen.
The implication of this technical gap is often not widely understood or quantified sufficiently to senior leadership, leading to the prospect of risk being insidiously generated through a lack of clear understanding across IT and business management. Surprisingly in many cases, the maintenance cost of software is being paid, but without the upgrade benefits being deployed and used.
A valuable lesson
The ultimate example of technical debt would be the 2017 WannaCry cyberattack on the UK’s National Health Services (NHS) which left a £73m IT bill in its wake and put thousands of patient records at risk. Here, hackers exploited a vulnerability discovered on the woefully out-of-date Windows XP system, which was still being used across NHS hospitals even though Microsoft had ended its technical support and security updates three years before.
They key problem was that many of the systems affected were not centrally managed, nor were they visible within any of the security or asset management platforms. Importantly there were no governance processes or functions assessing the ongoing technical and maintenance state of the application system dependencies, regardless of what management systems were being used from a central IT perspective.
Hopefully, a valuable lesson has been learnt because of this far-from-best practice, but it continues to serve as a reminder of the problems technical debt has in store and the implications attached. The impact to the NHS was massive. Overlay the further management constraints that COVID-19 has created and the impact could have been devastating.
Running out-of-date software can also have unfavourable consequences when it comes to commercial planning and vendor negotiations when your agreement is up. If you’re running – or plan to continue running – aging applications, but know that you may have a major infrastructure migration to complete such as cloud, legacy technology dependencies are often the major reason that migrations fail to complete on time and create more management disruption and overhead as the organisation struggles to remediate the issue in a timely fashion. One of the biggest areas we focus on when optimising customer agreements is to drive out assumptions in deployment planning. This is one of the most commercially impactful areas and it all comes about because assumptions are generally built upon poor data.
The consequences of this will be felt financially. You’ll be unable to optimise the commercial deal that you had with the vendor because you cannot deploy as planned, or you start to move outside of permitted licensing benefits such as Azure Hybrid Use Benefit for Microsoft which has a 180 day dual running cloud migration window for SQL server. Either way, this has financial implications due to licensing risk, both in terms of added cost and failure to make the most out of the benefits you have already paid for. Nobody looks good if costs and disruption escalate.
Putting off upgrades and accumulating technical debt at some point stops the operational deficiency being resolved through upgrades, and instead requires a transformational approach and wholesale change and review. Compliance with application level support contracts, regulation and other interrelated dependencies can suddenly require a rapid need to upgrade to the latest software versions. Ultimately a large gap leads to higher costs, more management overhead and the potential for greater disruption risk overall.
Paying off your debt
The key to getting yourself out of the red is to track and review your technical debt as part of a continual software portfolio review process. Granted there are often other factors that prevent upgrades being administered, but the implications of this not being tracked and the accumulative impact assessed and reviewed can have major ramifications over time. Importantly to system and application administrators, ensuring your leadership has a trustworthy report of the implications helps ensure that the correct management decisions can be made when required.
Always keep in mind from the outset that the decision you make to use a certain software is one you’ll have to manage for many years and that it can be extremely difficult to extricate yourself from a vendor or technology once you’ve signed on the dotted line and deployed. Continual assessment of your software and cloud portfolio with an understanding of the commercial, operational and technical risks is critical to good and effective IT governance.
Mapping what you have in place and understanding dependencies as you parse through your systems, applications, users and contracts is critical to good portfolio management. Modelling the impact of system changes and upgrades will allow you to understand the commercial, operational and technical risks.
By having trustworthy information, you’ll not only make it easier further down the line when it comes to management and commercial planning but also to contract re-negotiations as you’ll have a better idea of what new technology you need and when you’ll need it. Stop paying for things you don’t need and have a better understanding of when to invest in things that you do.
ABOUT THE AUTHOR
Author: Chris Gough, Chief Strategy Officer
Chris has worked in the IT Industry for over 20 years, starting as a consultant he then took on more senior practice management roles, focusing on networking, security, data centre and unified communications and in recent years specialising in data centre optimisation and particularly in software licensing. Having worked with large enterprise organisations, Chris understands the challenges faced in data centre licensing and the lack of expertise in the marketplace.
Having founded the Derive Logic business until its acquisition by the Carlyle Group in April 2019, Chris is now on the senior executive board for the world’s largest independent IT Transformation Assurance and Software/Cloud Risk Management business, Livingstone Group.