More on Business Rules in Legacy Modernization

Cyrus Montakab posted on Business Rules in Legacy Modernization recently in response to a post of mine and I wanted to respond to it. I wanted to respond in particular to his comment that:

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.

Now I take issue with this, as regular readers will be able to guess. Let’s take the second piece first – 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.

Organizations who look at their legacy code, identify the decisions being made within it and then document the rules for those decisions using the legacy code in conjunction with the policy/regulatory documents that the code is supposed to implement it manage this quite well. The COBOL code helps you find the decision points and establish which bits of the code are calling the decision. It also helps you see what changes were made in the system relative to the original intent – some will be wrong but most will be practical adaptions of the original policy. Of course if you just take the legacy COBOL and try and auto-generate rules for each IF THEN ELSE statement then you will get a mess and frankly you will deserve it.

Once the rules are found and built into a Decision Service then COBOL code can be regenerated (see COBOL Lives! In the business rules space at least) and integrated back into the legacy application. This enables most of the code to be left untouched. Of course you can redo the whole application and replace the non-decisioning pieces with a BPMS, reporting tools and, if all else fails, Java code.

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.

He goes on to say that he

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 … rules

Well you could do that but now you are committed to changing the whole application rather than just some of it. Higher risk, higher cost. And anyway, why would you want to replace COBOL rules with Java rules anyway? You can see my opinion of this in Why don’t you replace COBOL with something useful (not Java).

So I stand by my original suggestion – turn the decisions in your COBOL code into rules-based Decision Services and then decide if you need to refurbuish the rest or not.