When it comes to IT strategy, defining and embracing legacy IT value is at the heart of finding the right solution, argues Derek Britton

Advice Abounds

IT glitches make for good press stories, and there is a seemingly regular supply. Santander took their turn recently to make the headlines for the wrong reasons.

Other recent articles share their perspectives on core IT systems - and how they fit in a digital future. The IEEE publication “Inside the Hidden World of Legacy IT Systems” (2020) includes examples of the challenges facing organizations maintaining or changing “legacy systems”. Information Week’s “How to optimize legacy systems for forward looking change” (2021) takes a practical look at technical possibilities for “legacy system” change. While each piece has its merits, I want to explore some details missing from either piece.

Defining Legacy

I was lucky enough to talk to one CIO who, when I referred to some of his application set as his “legacy systems”, he brusquely responded, “these are not legacy; they are my core business”. Therein lies the core challenge: what might be a legacy system to an outside observer may in fact represent crown-jewel core business functionality to the organization. What makes an IT application that calculates interest rates, provides insurance quotation, manages critical stock control algorithms for a retailer, provides healthcare benefit processing, manages governmental benefits processing for millions, books parcel shipments, haulage logistics, travel schedules “legacy”? What makes any of those things a legacy system if that is what the organization does as a core activity, except perhaps the perceived “age” of the system?

Is legacy a label of tenure? If is it, it is truly on shaky ground. If an IT system responsible for revenue generation, for example, has operated for 2 years, you could argue that its value to the organization has been the revenue collected over that time, minus the cost to build and manage the system. If so, an older system starts to look more valuable, the older it gets – there is more revenue, and typically lower cost of management.

More critically, presuming the age of a system determines its level of risk to be fit for purpose is also on thin ice. How many of us have thrown our old iphone5 into a drawer at home, never to re-emerge? It was on the market for less than a decade, yet today there are no apps built for it, no OS updates. It is a dead platform. How many new-age technologies have gone the same way? It seems evident that a simple time axis is not a fair reflection of what constitutes legacy (or moribund) technology.

Legacy Modernization or Replacement Projects

The IEEE cites various real-world examples of the dangers of legacy by citing projects that have failed. It is a sobering chart of the frailties of IT project risk. What it attempts to do, however, is suggest that – because these were all legacy system related – that somehow their legacy status was the cause of the issue. I would contend that is inaccurate.

The RBS issue was ultimately, according to reports, put down to human error to do with the IT scheduling processes. Someone simply ignored protocol, and deleted the wrong file. An innocuous error, with vast consequences. That has nothing to do with technology, per se. It is an internal processes and governance question.

The TSB online banking project was reportedly an ambitious effort by the new owners to impose a consistent online system across all its business units. Important integration efforts failed to enable such a project to succeed. The core challenge was project and risk management of technology integration - the age and status of the incumbent systems were incidental.  

A widely reported recent example, State of New Jersey, cited a shortage of skills, rather than a technology problem. The most challenged area – it later transpired – was nothing to do with the then-reported culprit, COBOL. 

Who’s In Charge Here?

Too often, technology discussions overlook a question about the business suitability of strategic change. Customer experience, and business viability should be items 1 and 2 on any IT strategy, yet all too often the commentary and critique overlooks this. This has a huge bearing on legacy IT consideration: customer experience and business viability should dictate continued investment in core systems. Avoiding them failing into peripheral IT resourcing or funding categories will stop them becoming “legacy”, where the next step is a retirement plan. Often, these systems cannot afford to break, nor be under-funded. IT decision makers need to recognize value, and invest accordingly.

Micro Focus’ 2020 survey found that 92% of respondents regarded their core IT applications as strategically important. Strategy should align to focus.

The Truth is out There

The truth about IT modernization projects needs a more careful, systematic approach to what the projects were, how big, what was involved, what happened. Superficially concluding that projects to change older tech demonstrate that older tech is the big problem is entirely unsound.

By contrast, the remarkable work of the Standish Group, who have been surveying the IT industry across 3 decades on this very topic. Their results are as illuminating as they are considered. First, they looked at the types of change, because the level of ambition (and risk) – they hypothesises – may have a bearing on the results. Second, they looked at thousands, not a few, projects. To use real-world facts as the basis for any conclusion, the Standish Group is as close to an objective truth as you can reach. They found that incrementally updating incumbent systems (what they refer to as Endless Flow modernization), is significantly more likely to yield positive results than large-scale replacement or rewrite projects.

Read about the Standish group findings to help you redefine the truth about legacy IT.

Learn how sensible, systematic modernization of valued IT systems can help your IT strategy.

We'd love to hear your thoughts.  Make sure you are logged in and leave us a comment or like.