James Taylor's Decision Management

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?