COBOL Rules for Documentation or Rules for rete-type inference engine
Here at SoftwareMining, we get two types of interest in Business rules. In the first instance there are projects who simply want to re document the system or re-produce a functional specification for the purpose of rewrite. The 2nd set of interest is from organizations who would like to re-implement their system within a “rule-based” system. This COBOL rule-systems is the topic of my dicussion today.
James Taylor, writes an interesting blog on "Modernizing COBOL with business rules" :
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.
This is great observation, business rules are not applicable to all parts of an application. Data-entry screen would benefit less than a claims-processing piece of code which is full of rules.
But 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.
I would have thought it would be a better approach to translate to a legible/maintainable java code, get it up and running (test and baseline), then refactoring parts of java programs into Rete type/ inference engine type rules. This would avoid retro-fitting COBOL into an architecture which it wasn’t designed for.