Legacy is alive and well

Permalink| Discussion:

Posted in Legacy, Technology, Programming, Management on January 14, 2008 at 6:25 pm

Reading Davey Winders Blog post regarding Brainstorm and its 24th Birthday got me thinking about legacy applications and in particular our in-house bespoke ERP system that I am currently caretaker and developer of. It is too easy these days to consider an application useful only if it has a graphical user interface but I imagine that there are many older applications still in active and essential use today – that is certainly the case in our business.

Originally our ERP system was an MRP package (before ERP became an all encompassing term) and started out life serving the automotive industry – until we bought the rights to develop the source code when the original development company moved on to other projects. This software was and still is developed in COBOL, originally Ace COBOL then RM COBOL and now Microfocus COBOL on AIX. The back-end file system isn’t even a database - it still utilises C-ISAM indexed files and very few are simple sequential files. File and record locking problems still occur (though less frequently these days) and new report programs have to be hard coded by hand – I sometimes still use those sheets of 80×25 grid paper for laying out screens and reports!

The thing I discovered whilst looking through some of the code recently is that quite a few of the older programs in our ERP date back to 1978 which means that this year our ERP will be celebrating its 30th birthday! Obviously parts of the software have changed a lot since those days and I’ve completely rewritten the front end and the majority of the everyday programs and added all sorts of bells and whistles to others. But not all of the code has changed and there are still programs that are relatively untouched bar minor updates to make them compile using modern compilers – there is no windows front end – in fact no graphical user interface at all - just a text based interface (though we do use colour now), no mouse control and no WYSIWYG print preview options. New users are sometimes surprised that they can’t click on menu options with the mouse and often quiz me why they have to keep CAPS LOCK on when entering data into input fields.

However, one of the strengths of our business over the years has always been quoted as being our strong ERP software which has worked with us and for us for all these years and just goes to show that legacy applications are still alive and well - after all ‘if it ain’t broke…’ – so to our ERP system I wish a very happy 30th birthday.

I wonder how many other so called ‘legacy’ applications are still out there and serving their business partners faithfully?

Next Post | Previous Post

Comments

Although I would support your decision to remain with a legacy system, especially when you have the technical people to continue servicing it, the scare for the company is if you should leave them, much of the knowledge is lost with your departure, and hence the company will probably be up s_-t creek!

Now many people still know 30 year old programming languages, and the ones that do, I am sure are commanding very large salaries.

Comment by Lake Luke - January 15, 2008 @ 9:43 am

‘Legacy’ is always used in a derogatory way yet, almost by definition, these are systems that have held their place in a business for a considerable period. They clearly meet a need and are reliable enough that they have not been replaced.

The bogeyman of there being no people left with skills in 30 year old languages doesn’t work for me, because they are still out there. I have found that the problem is normally in getting the business knowledge needed and I have seen systems under 3 years old fail for this reason – it is not a legacy system issue.

Comment by Martin Brunt - January 15, 2008 @ 11:37 am

Often there is a knee-jerk reaction that if something is more than a few years old then automatically it follows that it cannot be any good. I agree with you that this is a wrong assumption. - It sounds as if your ERP system was developed and enhanced well over the years to accomodate changing business requirements.

Your concern though about staff being suprised about the lack of mouse usage is something to watch for. Increasingly, user exepctations of systems have been moulded by the Windows environment and this can lead to frustration if users feel the system is not working for them. In some cases users may abandon the system because ‘Excel is easier to use’. If this happens then there are worries of data integrity, duplication, or completeness.

Comment by Moshe Zeidman - January 15, 2008 @ 11:51 am

I suppose it is likely that developers, especially new ones, prefer the modern languages like Java, C#, Ruby and the like - as a returning student at Uni this is very clear as students look confused when I mention that I develop in Cobol - mind you I’m not compleletely old school and I do develop in C# and Java too!

That said, we have never found a shortage of Cobol developers - this was demonstrated effectively during the Year 2000 crisis when our development team reached the heady hights of 7 programmers and we were offered many many more via agencies!

As Martin points out business knowledge is a major contributing factor - many of our staff have been with the company in its various guises as long as I have (some even longer!) and they all have valuable information in their heads and are familiar with the way the software works so they can get new staff up to speed (or is that down to speed?) very quickly.

As Moshe rightly highlights with users sometimes saying ‘Excel is easier to use’ - Spreadsheets are definitely something that we often battle with especially as it is so easy to start collecting data using them. I have always been of the view that spreadsheets should complement the core system and be used for analysis of information - not for data collection.

The opposing view is often that a spreadsheet can be set up far quicker than a program can be analysed, designed, written and tested. This worries me even more as often spreadsheets are setup as freeform entities and are often modified or amended in adhoc fashions with little regard to any analysis, design or testing.

Many a time spreadsheets have been deemed essential by a user or users only to find that when they move on or change jobs these spreadsheets are simply archived and never referred to again!

We have looked at adding a GUI front-end in the past using either thin-client cobol or screen scraping technologies but with so many other developments on the list it never really gets the attention it should (especially as something like the front end affects every 2000+ program in the system).

Comment by Jason Slater - January 15, 2008 @ 12:43 pm

Bravo, Jason!

As one who has worked with “legacy” applications since 1978 and has been involved with the development of COBOL programming tools for 21 years, I can say that your commentary is 100% accurate.

Too often, people dismiss older technologies as being “obsolete” when in fact, the word “old” actually implies that the technology is both proven technology as well as useful technology…otherwise it would never have gotten old in the first place. It would have lived a very short life and disappeared from existence.

I am also amazed at IT shops which blindly plunge into some of the newer technologies without first putting the technologies to the test in order to ensure that they will stand up to the rigors of REAL data processing requirements.

There’s nothing wrong with using a mix of old and new technologies as long as they do the job and are maintainable over the course of a reasonable span of time.

IT Managers must regard business applications as corporate assets which should be amortized across the longest period of time possible in order to ensure their cost-effectiveness.

Re-writing applications every two years for the sole purpose of using the “language du jour” is a terrible waste of corporate resources unless it can be proven that the corporation will benefit financially from the re-write.

Again…kudos to you for speaking the truth!

Comment by Bob Wolfe - January 15, 2008 @ 3:24 pm

There’s plenty of old stuff out there and tellingly it’s banks, defense, HMG,… who use it. Not because they are stick in the muds but because they can’t afford for stuff to fail so they don’t change what ain’t broke.
I develop terminal emulation software so I know! I always say old s/w is good because it is tested but bad because the UI is outdated. Hence grafting a new UI on old s/w is the best of both. You can do a lot with terminal emulation on thin clients or PC’s but I’m not a salesman
http://www.itpro.co.uk/blogs/davef/

Comment by Dave F - January 15, 2008 @ 4:22 pm

COBOL was, way before spreadsheets, databases and SQL, the language of business programming, and the lack of foresight that led to millenium bugged programming cannot be blamed on the language, other than perhaps the lack of a standard and robust data type for dates.

I can remember other langauges that had flawed date formats, even the Unix 32 bit date format is flawed, an issue that will already be hit by a 30 year term from now.