We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

James Taylor's Decision Management

James Taylor

Modernizing COBOL with business rules

Vote 0 Votes

This article on modernizing COBOL Code Rebuilding the legacy -- modernizing mainframe code caught my eye recently. While there was much to like, a number of comments made me think about how different it would be if the companies worrying about COBOL maintenance and modernization would think about business rules. For instance...

"With a shortage of Cobol programming talent looming in the next decade and a clear need for greater software agility and lower operating costs, IT organizations have begun to make transition plans for mainframe applications. The trick lies in figuring out which applications to modernize, how to do it and where they should reside."

Now if you knew about business rules, you would know that not all parts of an application are created equal when it comes to agility and maintenance work. Some pieces of an application have lots of rules, complex rules, rules that change often or rules that need business expertise to understand. These pieces need to be modernized if you are going to deliver agility and reduced maintenance costs. Others do not - they can probably be left just as they are. The question then is not "which applications to modernize" but "which pieces of which applications are giving me pain and costing me maintenance dollars" and should therefore be upgraded to reduce my TCO.

"An increasingly common strategy for these applications is to leave the Cobol in place while using a service-oriented architecture (SOA) to expose key interfaces that insulate developers from the code."

Well maybe. SOA has lots to recommend it but most legacy applications are absolutely not structured so as to make good services. You probably don't need to reuse the whole application. Often the piece that needs to be shared is the business decisioning piece so why not modernize that, expose that as a service and go on from there?

"very few of his clients have been successful at completely rewriting large-scale applications."

Well duh! Everyone has seen this in action. The bigger the project the harder the problem. So why not reduce the size of the modernization project and only focus on the pieces that will show an ROI - the high maintenance, high change pieces?

"Doing a rip-and-replace is a big thing. There are things you can't afford to re-engineer, and they will probably always sit in the place where they were developed."

Absolutely. But just because the application needs to stay where it is, it does not mean you have to tolerate huge maintenance costs for making changes. Find the pieces that need changes often, make them easier and cheaper to maintain with business rules and go from there.

"While there is a shortage of highly trained mainframe programmers, many existing Cobol applications are very stable and don't require much maintenance"

But what about the ones that AREN'T stable and do require maintenance? I need to modernize those don't I? But why would you want to replace legacy code with the next generation of legacy code by simply re-writing them on a new platform? Wouldn't I want to change them to require less maintenance work, to empower the business to collaborate effectively with IT in the change of thoese systems, to build them, in other words, to change rather than to last? I would. Wouldn't you?


James, thank you for the great observations above.

I would like to add a point. Firstly, since shortage of Cobol programming talent looming, sooner or later people will have to get out of such systems. We also acknowledge that manual re-implementation of these systems tend to be risky and expensive. A viable solution is through an automated “intelligent translator�. I am putting together a the desirable characterstics of such translator. I am not going into too much technical detail here, for more information please visit:
Semantic translation - requirements for generation of "Maintainable" Code


Cyrus Montakab

Hi James,
BTW, with respect to my previous comment, I have also added some of the information to my own blog and created a link to this page also. Please see:

Business Rules in Legacy Modernization

Cyrus Montakab

James Taylor blogs about decision-management technologies such as predictive analytics and business rules, discussing how they deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics.

Sponsored Links



Recently Commented On

Recent Webinars

    Monthly Archives