<< Business Rules in Legacy Modernization | Home | Happy 50th Birthday to COBOL >>


COBOL Business Rule projects are large projects

Lets do the job properly

Question is how bigger would the project become if they migrated to “maintainable” Java first? Would they have to migrate the whole thing – or just parts which is destined to be re-written as rules? Depending on the COBOL platform (IBM, ESQL, UNISYS – DMS-II, ….), it is possible to have part of the system in Java and leave the rest COBOL.

In my previous post on Business Rules in Legacy Modernization I wrote:

even for the modules that can be fitted into a business rule, is it viable to re-architect re-factor the existing COBOL code to fit into a Rule-Engine such as Blaze, or ILOG? Lets not under-estimate the project – it is going to be a major project and when finished it will result in another piece of legacy code – which very few people can maintain in 10 years time.

James Taylor responded on More on Business Rules in Legacy Modernizations

to describe a set of business rules as “another piece of legacy code” is to misunderstand what can be done with business rules. Turning the decision logic into atomic, concise, managed business rules is absolutely not the same as another piece of legacy code.

This is missing the point. If Einstein had used Latin to write his theory on Relativity, then it would still be a fantastic theory which nobody could read or understand. And other physicist would not have been able to build on that work, unless it was translated into a language that they could understand.

Going back to the present discussion, I am not against rules based system, but in order to have a maintainable system, the rules must be written in a language which others can understand.

We regularly come across organizations who suggest they now have 10 times more Java developers than COBOL ones, who say had to bring some COBOL people out of retirement to help them to “document” the system, and so on. All indicators are pointing to a gradual decrease in number of legacy developers.

So, where is the logic in spending a lot of time and money in applying a new architecture to a piece of code which is written in a dying language. Sooner or later no-one is going to be able to read or maintain it. Lets do the job properly: and address the longevity of the system along major re-architecting effort.

Also, bear in mind that the original legacy systems that we are talking about were written decades ago. Why are they still going? Is it because of the strengths of COBOL? Is it really such fantastic language? Or is it because “it is still getting the job done”. It was written properly (for the time), it is still meeting the requirement (just), and with some re-architecting it will continue to do the job for years to come. If it wasn’t doing the job, it would have been replaced by now. It is not broken, so why fix it. But now, if change is necessary, then lets do the job properly, and address the long term maintainability. Maybe it will last another few decades.

The writing is on the wall … gradually there will be no developer left to work with these systems, making them gradually more difficult to maintain and move forward.

Young and talented people study Computer-Science because they dream of future: they want to be at fore-front of computing technology, do new things, use their creativity to come up with new designs … for the web, for I-Phone or as games developers. Whether they end up with start-ups, government, or financial organizations, they will continue dreaming about developing a clever, big and important system. They won’t dream of adventures in COBOL. Finances may force a few towards the legacy languages,  but the good developers will find a way out.
The “talented” young people who want to look back, will study archaeology – not Computer Science.

Back to present topic. For projects concerning re-architecting into COBOL Rule system, James then goes on to say:

Admittedly you can’t easily compare the rules with a specific piece of COBOL code to make sure they work the same but the rules embedded in COBOL are almost certainly wrong anyway - they have been in EVERY legacy-to-rules project I have spoken to. It is simply too hard to keep rules in COBOL up to date and accurate.

Thank you James, These are not small and quick projects. Lots of re-factoring / re-coding, lots of testing. The resulting system has better architecture and maintainability, but not for long. The only way to achieve long term benefits that is to implement it in a language that new people can read. We can either do this manually – which is very expensive and risky, or use a “good” automated system to first move the code base from COBOL to a “maintainable” java system, before re-implementing part of it as rules.

Add a comment Send a TrackBack