Technical bankruptcy - the avoidable business killer

In a provocatively titled paper Avoiding Technical Bankruptcy in Legacy Systems, analyst colleague Frank Scavo argues that as many as 20% of enterprises are either in what he terms the 'danger zone' or may already be on the verge of or in technical bankruptcy. See here for the summary.

In this context technical bankruptcy refers to a state where recovery from years of failing to keep systems up to date is similar to IT entering Chapter 11. I'm not so sure about that but I get the analogy. The most important point is that as systems age, their ability to keep up with or support business innovation diminishes.

The report provides the reader with a well laid out journey that documents how technical bankruptcy arises, its manifestation and, closes out with possible solutions.

It is important to note that nowhere in the report does the author state as fact that older systems inevitably lead to business failure although there have been many examples where even new systems have caused significant business disruption.

We only have to consider the longevity of the mainframe to know that there are use cases where the 'old' just keeps trucking along, but the crucial element is that those same systems are kept in good order which, in software terms, means having an executable policy of upgrading and patching.

What is technical debt?

This is a question that often befuddles non-technical people. You just switched on a brand new, all singing and dancing ERP and it's going to go south? In a few years? What The Actual F...?

Sorry people but it's true. All software contains unannounced features also known as bugs. These have to be fixed because they represent threats to the integrity of the system. Sometimes, bugs are sufficiently serious to require changes to large parts of a system such that the changes constitute an upgrade. Equally likely, changes in legislation and/or local regulation mean the system has to be changed. Then there's the matter of functional enhancements designed to improve user experience, make things more efficient or allow new innovation.

A failure to keep up to date with versions and/or patches leads to technical debt.

The term is well phrased because it refers to the time and effort required to implement the patches or upgrades I just described. And typically, this gets harder with the passage of time. Add in complexity through things like customizations and the financial cost alone becomes ever more daunting.

Incentives to maintain and grow technical debt

As Scavo has documented over the recent past via his company's primary research, IT departments have been under a variety of pressures. Everything from hiring freezes, to efficiency programs to the point where 'doing more with less' is almost a given. What dies this mean for technical debt?

The report succinctly contextualizes the argument this way:

Despite the negative connotation of the phrase, going into technical debt can be tempting. A CIO may use technical debt as a tactic for saving money. Just as a consumer may temporarily skip maintenance on a car to make ends meet, an IT organization can forgo system upgrades in order to live within a limited budget. In effect, the CIO is borrowing from the future to be able to fund other projects today.

Technical debt also can be attractive to business leaders. They may want new features in the latest version, but they do not look forward to spending the time, money, and effort needed for testing, rewriting procedures, or retraining users. The risk of disruption at the time of go-live is another disincentive. Since IT leaders and business leaders both have reasons for postponing system upgrades, it is not unusual to find organizations with major enterprise systems that are several versions behind the vendor’s current release.

It should be no surprise that this is the jump off point for making the technical bankruptcy argument.

Technical bankruptcy

Systems that are at the point of technical bankruptcy are said to be 'frozen in the the past' and represent true legacy. But given what Scavo says about the stop/start nature of upgrades, what are the typical range of symptoms that might be used as a diagnostic framework to identify at bankruptcy risk? I'll restrict this to a bullet point list encouraging you to read the full report for a detailed explanation:

1. Extensive modifications, extensions, and interfaces.
2. Poor understanding of the system by users and IT alike.
3. Direct involvement of IT personnel in business processes.
4. Legacy system atrophy as shadow IT emerges.
5. Upgrade or replacement hard to justify.

I'll go one step further - an erosion in the body of on hand systems experts such that upgrades and patches are much more difficult to execute than would otherwise be the case. In fairness, Scavo identifies this factor as contributing to competitive disadvantage. What do you do when the people who ran the system go away or retire?

To the point about business impact, Scavo exposes an argument you rarely find put forward with any conviction in the C-Suite: increased technical debt is a competitive disadvantage that amplifies over time.

The greatest danger to the business, however, is that the organization cannot use its legacy system as a platform for innovation. It becomes a major challenge for the IT organization to build out new systems and capabilities for mobile access, e-commerce, social business, business analytics, and automated data collection.

There is an answer

Make no mistake, avoiding technical debt means spending money but if the business is at risk, then there are opportunities. The report sets out a series of tactics some or all of which will mitigate both cost and potential business disruption. I leave readers to go get that information for themselves.

In closing, the report points to a couple of strategies that are known to work, One is the use of third party maintenance providers. Regular readers will know for example that Rimini Street is one of our partners and trades on the promise of cutting maintenance costs by 50%. The report mentions others like Spinnaker Support.

The report also discusses the role of tools like Panaya, which acts as a software discovery and risk mitigation tool along with test and dev planning in the upgrade cycle. We like Panaya because we have seen numerous cases where customers in upgrade situations have been able to focus upon the customizations that will break. Today, Panaya is owned by Infosys and from conversations with their people, we have learned that Panaya has made the difference between a 'yay' and a 'nay' in upgrade decisions.

The report also tips a nod in the direction of vendors that are actively solving for this problem.

Those seeking to get out of technical bankruptcy should consider investigating offerings that specifically serve organizations that need to upgrade or replace legacy systems. One good example is Infor’s UpgradeX initiative, which offers both cloud and on-premises options coupled with implementation accelerators to move clients on old versions of its products to new versions, or even different products in its portfolio.

Finally, no report would be complete without reference to cloud tactics. Scavo makes the practical point that not all systems will move to the cloud any time soon although he does anticipate that will be the case for all systems at some undefined point in the future. The benefits are obvious.

The cloud is your friend (of course)

Cloud systems are owned and managed by the vendor so they get to determine the extent to which systems can be molded. In the on premises world which this report primarily addresses, it was always the case that customers anticipated a level of customization. The cloud world changed that because apart from anything else, economics alone prohibit vendors from making X,000 versions of the same software. I'd equally argue that in the 27 years since ERP emerged, modern functionality is perfectly capable of handling a good 80-85% of situations. That's well within the bounds of acceptability, provided the business takes sufficient time over the change management aspects.

Scavo makes sure readers know that while cloud systems massively reduce the problem of technical debt, they do not eliminate it altogether. As customers put pressure on vendors to provide customization capabilities it will be interesting to see which route those same vendors take. My guess is that vendors who verticalize quickly will have far fewer problems than those who try to allow for customizations within a monolithic platform. That's the Infor playbook.

My take

Scavo's report is a comprehensive piece of research based work that deserves the modest investment to better understand the core issues , impact and tactics that will get customers out of the hole. None of it will be pain free but both business and IT will be equipped to make those essential C-Suite representations.