If you have ever used or considered using a rule engine or business rule management system (BRMS), you have given quite a lot of thought to how the rules will be written and managed. Usually that revolves around how a developer or business analyst will author the rules. But if the rules already exist, you may have wondered about how you might import, convert or migrate them.
There are three reasons why you would already have rules in hand when considering a BRMS:
- Your BRMS vendor has gone out of business or dropped support for the product you use;
- You recently completed a rule harvesting project and have a large number of rule artifacts;
- Your business has outgrown a custom rules solution based on highly structured code (e.g. stored procedures, table-based rules, COBOL, RPG, etc.). Or perhaps the people who originally wrote the solution are long gone and nobody knows how to maintain it anymore.
Yesterday I had the pleasure of attending a demonstration by our CTO, Loren Goodman, who showed some tools he recently developed for a potential customer whose current BRMS vendor is dropping support for their .NET BRMS product. That organization must now migrate to a Java-based product or move to another .NET product like InRule.
What Loren demonstrated is that some smart technology can help this prospective customer migrate thousands of rules into InRule in hours or days instead of the weeks or months it would take to do manually.
To accomplish a migration like this there are four steps:
- Collect rules from the source artifacts
- Mine phrases from the rules
- Translate the phrases for migration
- Generate the rules in InRule
Step 1: Collect rules from the source artifacts
Regardless of how you managed the rules before, the rules are your intellectual property and represent a major investment of time and effort. In this article we call the rules in a readable, electronic format “artifacts”. The goal at this stage is to collect the artifacts and read them into a phrase mining tool. If the rules came from a harvesting project or highly structured code, then it is often not too difficult to locate the necessary artifacts.
In the case of a migration from an existing BRMS, the rules are often available in one or more files from which they can be read directly. Some BRMS tools, however, will bundle rules into executable code which might come in the form of DLLs. In those situations it will be difficult or impossible to read the rules. The solution is to find a way to get the text of the rules into a non-proprietary electronic format such as an HTML report. Most commercial BRMS tools have some kind of reporting capability you can use to generate readable artifacts.
Once the rule artifacts are in place, it should not be too difficult to write code that can read them into the mining tool. If you happen to have a format we’ve handled before such as SQL Stored Procedures or output from other BRMS products, our ROAD services consultants may have already written the necessary code.
Step 2: Mine phrases from the rules
This step is where the smart tools and a subject matter expert (SME) come in. Loren developed a phrase mining tool that provides a visual way for a non-developer to go through the text from the rule artifacts and identify the phrases that make up all the rules.
The phrases are the building blocks that are combined into business rules. For example, part of a rule might say “age is greater than 21” which a SME can easily recognize as an “is greater than” phrase. That phrase can be generalized to “{field} is greater than {value}” so that the mining tool can recognize it elsewhere in the text from the rule artifacts.
The SME can go through their rules one by one and highlight these phrases in actual rules. The SME is aided by red squiggles that provide a visual cue of possible phrases. The SME’s objective then is to make the red squiggles go away. As the squiggles disappear, the phrase mining tool is able to recognize the identified patterns in all the other rules that use it. Eventually there are no more red squiggles and the entire set of rules has been converted into recognizable phrases.
Step 3: Translate the phrases for migration
If you have ever studied a foreign language, you know that there is not always a 1:1 translation of words and phrases from one language to another. This TED blog provides some great examples. If you speak Swedish you might say “Det är ingen ko på isen” which in English literally means “There’s no cow on the ice.” But the idea you want to convey in English is “Don’t worry about it.”
A developer translating phrases from one business rule solution to another faces the same dilemma. For example, the “is greater than” phrase represents a basic operator that most likely means the same thing in both solutions. But something like “applicant is a minor” implies there is an age and that the age value must be greater than some other value that will vary by jurisdiction. Because of this ambiguity, we don’t try to automatically translate phrases but, instead, each phrase becomes something the developer maps into the generated rules. This provides an escape hatch for the developer where he or she has the necessary flexibility to handle the translations that aren’t straightforward.
Step 4: Generate the rules in InRule
At this point much of the hard work is done. All that’s left is to generate the rules and verify that everything went smoothly. InRule’s authoring API, part of irSDK, makes it possible to do in code anything that can be done in irAuthor. So the mechanics of generating the rules in InRule are the easiest part of the entire process.
To verify that the generated rules are correct, the SME will want to review them in irAuthor. One of the big innovations Loren introduced to help with this task is the presentation of the original rule text and phrases alongside the newly generated InRule rule in irAuthor. This allows the SME to quickly compare an incorrect rule to the original source, identify the likely cause and propose a solution to the developer. Once necessary adjustments are made, the rules can be regenerated. The process can be repeated until the SME is satisfied with the end result.
What Next?
The tools described in this post are currently available as part of a Rule Harvesting Accelerator Program that includes consultation by one of our ROAD Services consultants. The consultant will help your team through the process of harvesting rules from an existing source.
So if your BRMS vendor has recently dropped support for the product you use or you have outgrown your current rules solution, we would like to help you explore your options. One of our ROAD consultants can perform a migration feasibility analysis at no charge. Please leave a comment below if you would like to find out more.
