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?
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 a lack of accessibility. This is because interfaces are dated, 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 been developed and maintained over many years. They are 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 ’80s and 90s, give the impression of obsolescence. We can though “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. This will ensure that vital functionality or data is not lost in the process of replacement. A business-as-usual (BAU) team probably does not have that understanding. A big bang migration to a new platform means reverse-engineering the design of the system or having a detailed knowledge of the functionality utilised by the data in the current system. This may take many person-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. This is often 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 and separate the GUI from the business logic. It 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. Give priority to the processes most frequently used and continue with old applications where there is no business case to re-write.
Reveal the gems
Progressively service enabling systems and developing web interfaces often reveals business functions use just a small part of the system. Logging use of legacy GUI applications might help identify redundant components. Of course, do not forget the applications that run as overnight background tasks. However, the analysis of the logic used is generally relatively straightforward.
Over time, code will need to be changed. The choice is to continue developing services in proven and efficient 4GL programming tools. Alternatively, replace component by component, with services in a new language. This progressively exploits the highly reliable existing business logic that works. It also provides 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 as techies of a certain vintage reach retirement age. We often find on projects in large enterprises that there might be 20 technologies in use. Yet, there are often only a couple that are considered legacy. Once our highly able staff realise that committing to learning 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 several 10s of lines of Java/JDBC code.
Timing is always tricky
Although there may be compelling reasons to build new systems, there is always a 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, such as 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.” 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.
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 www.diegesis.co.uk
