Hands up everyone still using legacy systems

While waiting for a seminar to start I had an opportunity to catch up reading some articles I had torn out of various publications. One particular article caught my attention as it was talking about why business should be looking at replacing legacy applications. This may come as a shock to some people but parts of our ERP (Enterprise Resource Planning) application are 41 years' old which, I guess, make it a legacy application.

Imagine you became really good at your job – and at your appraisal you were told “You are doing really good and have served us well so we are letting you go.”

There can be tremendous pressure from industry to renew, replace, re-engineer, refresh, modernise, facelift, whatever you want to call it, legacy applications. Several times we have been visited by keen salespeople with a vision to replace our apparently ‘ageing’ system with something new. Some of these systems are fantastic with every possible bit of functionality a business like ours simply does not need.

Instead of feeling pressured to push aside legacy investments should we be recognising years of loyal service?

Many applications, especially ERP, rely on several layers to operate successfully. Firstly, there is the information schema describing the data itself and how it should be stored and accessed. Then the business logic layer which describes the decisions a business needs the computer to make. On top of this usually comes the supporting layers including the presentation layer and reporting layer showing how to display information and extract information appropriately. Tying these together is usually some form of code syntax – in our case Cobol.

I have always believed the saying which goes “80% of a software application is in the design – the other 20% includes the syntax”.

I once explored the notion of recoding our entire ERP suite using C# and a SQL back-end. I even built a test framework as a proof of concept but you know what – other than window dressing we would have gained little extra business benefit. After all, this is a software application with a 40-year-plus pedigree – the syntax and presentation layer may change but the underlying business logic which is at the core of the system would remain unchanged.

By leveraging our investment the system may have to remain text based, running Telnet from an RS/6000, have a limited ASCII colour scheme and use an indexed data file system for data storage, but the most important factor is that it does the job – and it does it well. There are things our ERP system can do that no standard system is capable of and it gives a fantastic level of ‘fit’ for us.

‘Fit’ is a measurement often given by suppliers to describe how well matched a software application is to the requirements of a particular business.

A number of reasons were given, in the article, for business reluctance to change from a legacy application; two in particular were interesting:

“It is too risky” – When replacing an ERP you are also replacing many of your established business practices so it is always going to be risky. This is often where ‘fit’ plays an important part.

“A replacement is too expensive” - Compared to what we have in place– any system would be too expensive requiring investments not only in software, but also in hardware, communications, awareness, training and ongoing support.

I do try and keep an open mind on the subject and keep up with technologies and techniques which could help us - including the various modernisation tools available for our application. A couple of years ago we looked at migrating from one Cobol platform to another but we had to ask ourselves whether it was fundamentally required at that time. We have done this in the past, which could be described as re-engineering, in fact we have moved twice – from ACE Cobol to RM/Cobol to Micro Focus Cobol.

We have a close relationship to the code in our ERP and we know our system inside out. Quite a few years ago two of us had just one weekend when we had to migrate from RM/Cobol to Micro Focus Cobol. This was a major undertaking and we had just one shot to get it right. Over a thousand programs later and - as a well known chef is fond of saying - “job done”. Another time we made a business acquisition and had to incorporate entirely new business processes into our system. We had a very short window to make this work effectively and there is no way we could have achieved this, on our budgets, had we not understood our application.

I often hear the message “Cobol programmers are hard to find”, I have to say we have never found this to be a problem – what we have struggled with however is people who can quickly get up to speed with our business logic. Trying to figure out what a bunch of code is supposed to be doing is both a challenge and a reward.

We constantly re-factor our code, pulling parts of it into re-usable code libraries. The code libraries can then be used to make application development more agile - you don’t get any more agile than two developers. We are often reviewing function points in the code to ensure they perform the job required.

I am often reminded of the Lyons' LEO project. When Lyons operated LEO, the first business computer, it was never about technology for technology sake – it was about business logic and that is where the emphasis should remain.