Using business rules to renovate old applications

In this article - Tough Decisions for Old Apps by Stephen Swoyer - there's a great summary of the problems of integrating legacy applications into an SOA:

Web enabling or exposing mainframe applications to new and different constituencies—including non-mainframe applications—is supposed to be easy, provided organizations have prepared by separating their app’s business logic from its presentation logic.

Unfortunately, some industry watchers claim, that's not the case for many mainframe apps, forcing enterprise service-enablement initiatives to negotiate some fairly difficult roadblocks.

This is indeed a common problem with legacy systems. One example of how to address this can be found in this great case study from the California DMV - http://www.edmblog.com/weblog/2005/08/license_fee_cal.html. The basic process they followed can be used by anyone facing the issue of how to expose the core logic of a mainframe system as a service:

1. Identify the services that are hidden in the legacy system
2. Figure out the rules implemented in these services - perhaps by analyzing the code but perhaps by reading the regulations or policies that are supposed to be implemented in the code.
3. Author these rules using the various metaphors for business rules - rule syntax, template-driven rules, decision tables, decision trees, scorecards, ruleflow etc.
4. Deploy these rules to the mainframe - either as a Java service or using COBOL generators like those for Blaze Advisor.
5. Use legacy modification/analysis tools to hook up these mainframe components to the rest of the (untouched) code.
6. Use the business rules management system to redeploy those same rules as a service in your SOA.

So what does this give you? It gives you the ability to expose the rules in a legacy application as a service without having to make your mainframe part of your SOA. Essentially you let your business rules management system act as the bridge between your mainframe and your SOA.

Have fun.