Why do you need to address ‘legacy’ IT?

Nick Denning, Managing Director of Policy Monitor and its subsidiary Diegesis, reflects on the use of the term ‘legacy’ in IT and how organisations should manage this

Over the past few years, ‘dealing with the legacy estate’ has been a major topic. However, the term ‘dealing’ is often too vague, and there are still important issues to consider.

What is ‘legacy’?

We define it as:

• Technology no longer supported by vendors or dependent on
  outdated APIs.
• Systems not evolving to meet future business needs.
• Open source projects that are no longer maintained.
• Programming languages that are no longer widely used.

Applying ‘legacy’ to applications is also more complex:

• New technologies, architectures, and development approaches emerge constantly.
• Cloud platforms have introduced modern ways of building and managing software.
• Migrating long-standing 4GL or green-screen systems can be difficult and costly.

Many systems can still be modernised by separating business logic from presentation, but the question is whether the effort is worth it. Despite declaring systems need ‘to be replaced’ is common, yet many persist for decades. Additionally, quick fixes can make systems fragile and harder to maintain.

A key challenge is that transformation projects often don’t deliver clear business value on their own unless they reduce costs (e.g., by moving to lower-cost technologies). Otherwise, only a wider business change can justify the time, effort, and expense of replacing ‘legacy’ systems.

Evergreen: Preventing ‘legacy’

Traditionally, systems were built using a ‘build and operate’ approach, often linked to waterfall methods. This required a large upfront investment, which frequently overran the budget and led to reduced scope. After delivery, limited maintenance funding often led to systems degrading and eventually being labelled ‘legacy’.

An alternative approach is ‘evergreen’, based on continuous evolution. Although it can appear more expensive upfront, as it assumes ongoing investment, it focuses on keeping systems current and adaptable.

This includes:

• Planned upgrades to hardware and software.
• Adoption of new standards and features.
• A modular architecture that allows parts to be replaced with minimal impact.
• Reducing vendor risk by supporting multiple suppliers.
• Separating user interfaces from core services.
• Keeping systems on current or near-current versions.
• Building in resilience through disaster recovery and continuity planning.

This approach aims to avoid systems becoming ‘legacy’ in the first place.

The people!!

While technologies come and go, there are some so well embedded that it is difficult to imagine them being abandoned. C programming, for example, underpins many products and applications that there will always be a need for it. There are even compilers for Python that convert Python to C, so it can be compiled and distributed without sharing source code.

But if young people entering the industry do not find it attractive, and there are no programmers available to code in a language, then, almost by definition, that language becomes ‘legacy’.

This is, therefore, a leadership issue. In a world where organisations are letting people go because they need that money to invest in AI, or are not even hiring new grads ‘because all coding will be using AI’, people starting off focusing on areas perceived to be unattractive yet where there is a need, will find a route into the industry that will keep them occupied for years.

The place for AI

‘We won’t need programmers because of AI’. We constantly hear this mantra, but I, for one, have not seen it put into practice, so I remain sceptical.

We suspect that we will always need great programmers who understand how to build excellent applications, effective business processes, a great UX design, a great UI interface, a robust data model that addresses high performance, locking and concurrency, logging and BCDR principles. But no hires now means no solution architects in the future!

It seems likely that required skills are going to separate into building models based on excellent understanding of technology, tools, standards and architectural principles on one hand to build models as opposed to writing specifications in a form to which the models can be applied to generate code and hence executable systems and test harnesses to prove them.

As IBM partners, we have recently been introduced to IBM Bob and plan to run a proof of concept to understand how it works (see https://bob.ibm.com for more details). We have also been using AWS Bedrock to convert ‘legacy’ code from tools such as Ingres ABF and OpenROAD, and we are now looking to convert Informix-4GL as well.

That was a big investment but to keep up we probably need to see if we can build an AI capability to reduce this significant services cost now we understand the problem.

There is a challenge as AI transformation pipelines are non- deterministic and instead statistical so we can get a different answer from each run. We want the transformation to improve as we evolve the model but not to vary once proven. We have learnt the impact of configurable controls such as Temperature, top-p and top-k for example to control this behaviour based on the RAG and inference-time tuning to manage the transformation process and the tension between deterministic and non-deterministic approaches.

Conclusions

‘Legacy’ systems only exist within a given context. Several factors should be considered before applying the label, as it is often used to suggest that a system incurs unacceptable costs or risks and must be replaced.

In reality, some so-called ‘legacy’ systems can still provide significant value and may continue to be used effectively for several more years.

Professionals seeking to enter the industry should consider working on legacy systems as a great way to understand the underlying tech in their path to becoming AI practitioners.

Please Note: This is a Commercial Profile

This work is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.