COBOL Lives! In the business rules space at least

Well I guess it had to happen – ILOG joined Fair Isaac in releasing a COBOL code generator for its flagship rules product. I have not yet seen it in action (I am sure I will at DIALOG next week) but I have talked with product management at ILOG and seen the public information. The press release is here and there is a datasheet too. It seems a very similar product to Fair Isaac’s Blaze Advisor for COBOL (information on their site here). Both companies offer the same basic functionality:

• Generate COBOL code for sequential execution of rules
• Same rule syntax and metaphors as the flagship products (decision tables, decision trees)
• Ability to read data from COBOL copybooks
• Ability to call COBOL subsystems and functions

It is not 100% clear if the rules for .NET, Java and COBOL are all stored in the same repository using the same syntax. It looks like they are but I will have to confirm it when I see the product.

So why is this even interesting? Why is a fairly up-to-the-minute technology like business rules being extended to support an old language like COBOL? With both Fair Isaac and ILOG supporting it, and a few others like CGI’s Strata product, more than 2/3 of the business rules market now supports COBOL. For an answer we need to consider two things – the core markets for business rules and decision management and the use of rules in legacy modernization.

Market first. Usage of business rules and decision management is currently focused in financial services – particularly retail banking, mortgage and insurance. Not only are these very decision-centric industries, they are also heavy users of COBOL systems. It makes sense, then, that the customers of leading rules products would push for COBOL support. If I have COBOL systems and I am trying to get control of critical decisions by managing the rules that drive them, clearly I need to be able to deploy the rules back into my COBOL systems – otherwise I don’t centralize the management of my rules across ALL my systems. While it is true that you an deploy Java code on mainframes, most companies find that bulk movement of data from the COBOL environment to the Java environment causes performance bottle necks and so the kind of core decisioning being executed using business rules needs to have a native deployment.

The role of business rules in legacy modernization and SOA is also a driver for this COBOL support. A classic legacy modernization scenario is to take a core decision within a legacy application, replace it with a business rules-driven decision and then expose that decision as a service (a decision service) for other services and applications to use. It is often the case that the piece of a legacy application that must be exposed as a service is a decision and that exposing the whole application is not helpful. However, if you want to have only one version of the rules (and you do), this means either generating COBOL (so that the legacy application can access the rules in its native tongue as it were) or service-enabling your old mainframe application. Clearly the first is easier.

With these COBOL-generating business rules management systems you can have the best of both worlds:

1. Find the core business logic and high value decisions (pricing, underwriting, eligibility) in your legacy applications
   These are almost certainly the cause of most of your change requests and maintenance cost in those applications
2. Replace this hard-to-maintain logic with business rules managed in a BRMS
   Bringing the logic under business user control and making it easy to change and update
3. Generate COBOL to replace the old logic and hook up the now largely stable legacy application to use it
   Most of the code runs exactly as before but your maintenance burden drops enormously
4. Use the BRMS to deploy a decision service to your SOA
   Allowing all other processes, systems and services to access the business logic through a well-defined service interface.
5. Maintain the rules in one place, easily and cheaply
   No need for COBOL programmers to maintain the logic, consistent rules across multiple systems on different platforms even though some are not yet service-enabled. Fair Isaac had a great example of this – the California DMV – and the case study is available here.

Considering this in the context of articles like this one – The resurgence of COBOL – that talks about the importance of keeping COBOL-based systems up and running while integrating them with new systems or this one – The looming day of reckoning – where the need to modernize old COBOL applications is shown clearly, and you can see what this is a good idea.

COBOL LIVES!
Edited after getting an ILOG briefing.