There are those who think mission critical business applications should be replaced just because they are based on old technology. Indeed, there can be reasons for adopting this approach and replacing systems built on older platforms. Surely, a complete re-write using today’s hot new software must be better than the tangled spaghetti of interdependent legacy systems, code and databases? It’s true that the potential impact of a small change to spaghetti code can make systems expensive to test and to maintain. In many cases though, these old core systems are mature, reliable and robust. They contain extensive business logic, have been thoroughly tested and contain a valuable history of business data.

The frustration with legacy systems can be lack of accessibility because interfaces are dated and clumsy and integration with other business applications is missing. However, history is littered with failed migration projects based on a rip and replace strategy. It is often lower risk, cheaper and faster to add a new “wrapper” to older platforms to rejuvenate the diamond at the core, than to chuck out much-loved operational systems of record. It just needs a bit of know-how.

Here are five reasons to love and cherish your legacy systems

First class databases
Many of the RDBMS products we refer to as legacy have actually been developed and maintained over many years to make them leading technology platforms, supporting mission critical systems. They continue to provide excellent availability, performance, storage, analysis and security. However, they get labelled “old” because the 4GL green screen and Windows development tools, created in the 80’s and 90’s, give the impression of obsolescence. We can “sweat this asset” by refactoring code to add a web interface that exploits the robust business logic.

Get to know your code
To replace mission critical systems while continuing to exploit the data they contain, you need an understanding of the current environment and code to ensure vital functionality or data is not lost in the process of replacement. A business-as-usual (BAU) team probably does not have that understanding, so for a big bang migration to a new platform it is necessary to reverse engineer the design of the system or to have a detailed knowledge of the functionality utilised by the data in the current system. This may take many man-years to acquire while keeping reliable systems running. Further data migration headaches occur when the replacement system isn’t able to take on the existing data because fields are missing from the new data model. The level of testing of new code to achieve the same level of integrity as the well tested and robust business logic, which does exactly what the business wants, can consume significant resources. A simple alternative is to refactor the legacy code to separate the GUI from the business logic, which can then be service enabled with a replacement revitalised web GUI. Think of it as redecorating a room in your house.

The key to success is to do this process by process, or perhaps role by role giving priority to processes most frequently used and continuing with old applications where there is no business case to re-write.

Reveal the gems
Progressively service enabling systems and developing web interfaces is likely to reveal the business functions actually used, possibly only a small part of the system. Logging use of legacy GUI applications might help identify components that are redundant and hence, never need to be web enabled or considered for future migration. Of course, do not forget the applications run as overnight background tasks, but the analysis of the logic used is generally relatively straightforward.

Overtime, as code needs to be changed, there is a choice of continuing to develop services in proven and efficient 4GL programming tools or to replace component by component, with services in a new language. This progressively exploits the highly reliable existing business logic that works while also providing a future and safe migration route to development in new languages and architectures.

If ultimately a bottom-up strategy moves much of the logic into stored procedures and a top-down approach replaces all the original 4GL code, the effort to re-platform to an alternative RDBMS has been reduced given tools exist to convert stored procedures from one database to another. However, there is seldom a business case for this, so why bother? The real gem in this strategy is the ability to “sweat the asset” at minimum cost and risk while creating APIs for exploitation across the business.

A surprising availability of skills
Skills availability is often cited as a reason to move to new systems because techies of a certain vintage are reaching retirement age. We often find on projects in large enterprises that there might be 20 technologies in use and perhaps only a couple that are considered legacy. Once our highly able staff realise that committing to learn legacy systems earns them the “right” to programme the replacement web front-ends they can see opportunities opening-up. Organisations engage with us because they benefit from the rapid increase in the number of staff with the 4GL skills needed to support their applications in the short and medium term. What we now need is for the product vendors to bring forward web development environments based on their 4GL languages. A single statement in these 4GLs replaces several, perhaps even multiple lines of Java/jdbc code.

Timing is always tricky
Although there may be compelling reasons to build new systems there is always risk. One option is to continue to run the existing systems which effectively support certain functions in the business while running a new system in parallel for new products and services. However, this throws up a different class of problem i.e. managing master data such as customer details, when there is scope for duplication across systems creating inconsistent data. This can be avoided by implementing Master Data Management (MDM) to ensure a single view of the truth. If MDM is implemented at the core of an architecture, linked to elastic search with queries that can navigate the links through MDM gold nominal records to the underlying individual database records; then adding new systems to an architecture or removing redundant ones becomes a perfectly viable approach.

Conclusion
“Time in reconnaissance is seldom wasted” therefore conduct a risk assessment looking at all the factors and options. You may be surprised to find there is still life in your legacy systems. In a difficult business environment, things which are proven and reliable gain a new premium and could be worth reviving. A light touch on the tiller may be all that’s needed to keep you on course to effective mission critical business systems for many years to come.

Nick Denning is CEO of Diegesis Limited, a business technology and IT systems integration company and Nick is an acknowledged relational database expert.

ENDS

About Diegesis Limited
Diegesis is a business technology and IT systems integration company that specialises in delivering outcomes using RDBMS, integration and data analytics technology. The company has a proven track record delivering successful projects that provide tangible business value to large and mid-size organisations through the effective combination of people, process and technology. Diegesis specialises in helping organisations to release the hidden knowledge and wisdom from within their entire range of diverse sources of information (documents, emails, core business systems and applications, databases, intranet, internet and presentations) to support swift and effective decision-making. For more information, visit Diegesis

Press contact: Mary Phillips
PR Artistry Limited
T: +44 (0)1491 845553
E: mary@pra-ltd.co.uk