≡ Menu

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.


Comments on this entry are closed.

  • Vijay Narayanan May 20, 2009, 5:39 pm

    Couldn’t agree with you more. I think there are a number of challenges with maintaining rules in legacy systems:
    – lack of transparency and high cost of maintenance
    – lack of consistency/categorization of rules and possible duplication of rules across legacy systems/modules
    – mixture of presentation logic such as green screens with business rules

    Last but not least the cost of change and lack of agility/declarativeness all make legacy rules unattractive when compared to placing them in a rules engine. The rule engine per se won’t guarantee every benefit but it certainly makes it easier to achieve organization, modularity, reuse, integration for SOA-based processes, and consistency.

  • Cyrus Montakab May 22, 2009, 3:14 am

    Hi James,
    At SoftwareMining, in addition to our translaton tools, we have tools to help extract Business Rules and document the COBOL systems. Some of our BRE-QT enquires are focused on migration towards COBOL rules. Usually such enquires are looking at re-factoring a big chunk of their system, if not most of it. Such projects are already big and expensive.

    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, ….), this often is a viable possibility.

    When looking at modernization projects, one should investigate cost, risks and benefits of each option. If, as you say, only a small part of the system needs changing, then perhaps it can be done quickly with minimum changes to other areas. If it is going to be a big project, then it would make sense to also consider long term maintainance options.

    I have posted a more detailed response on
    COBOL Business Rule projects are large projects

    I look forward to your feedback there.

    Cyrus Montakab