IBM’s Operational Decision Manager (ODM) uses Action Rules and Decision Tables to describe decisions, and Ruleflows to orchestrate those decisions at a higher level. It is important that the “look and feel” of the authoring styles are understood before investing in a Business Rule Management System (BRMS). This post will give examples of all three rule “artifacts.”
Rules are generally described using two types: Action Rules, and Decision Tables. The two have many similarities in what they do, but each has its own uses.
An Action Rule is an expression given in a language that can be read by both humans (including non-programmers) and by ODM.
To most business users, this example would be perfectly readable, just as it would be to ODM. Of course, the rule author has a large vocabulary available. Additional vocabulary elements can be modeled and used in rules (for example, a borrower may also have a credit score, an address, an account, etc.). Other operators can be used as well to meet most needs – some of which will be shown below.
The Action Rule example above does not account for the fact that in some states, an applicant is not legally an adult until they are 19 or 21. Certain states could have its own rule variance, for example:
Each state with a different age value would need its own rule, and the default value should also be changed to account for these variances.
Any time a state has a variance added or removed, both the rule for that state as well as the default must be changed. Imagine a business scenario where there are more complex situations, and they change often – not particularly easy to manage, right?
This is where a Decision Table is useful. A Decision Table is similar to an Action Rule, while giving an at-a-glance view of multiple parts of a decision to improve maintainability and readability.
In this table, the rule author can see all parts of a decision at once, and the “Otherwise” row makes maintaining the default situation much easier, and there is less clutter from having multiple Action Rules.
When appropriate, a Decision Table can also make sure that your values are contiguous, with no gaps or overlaps. Looking at the table below, you can see that an overlap was detected, and the rule author has an opportunity to fix it.
Many people will look at a Decision Table and think “database” or “spreadsheet.” A Decision Table is a table, yes, but that is the only real similarity. Data is not selected as it would be from a database, nor are indexes used, so massive tables with thousands of rows are less than ideal. There is no way to use a complex formula using other cells of a Decision Table as is common in a spreadsheet. But when you need to make multiple similar decisions, a Decision Table has plenty of power and flexibility available to the rule author.
In many cases, one would need to define the order, or “orchestration” of rule execution. Some rules should execute only after others have completed, or only in certain situations. Business readability is just as important in rule orchestration as it is in describing rules so the rule author can understand how and when a rule will be processed.
To orchestrate rules in ODM, a Ruleflow (similar to a flowchart) is used. This example is quite simple: A borrower’s eligibility for a loan is determined, and if they are eligible, the details of the loan itself are calculated. If the borrower is not eligible, there is no further need to evaluate the conditions of a loan, so the path skips to the end to avoid wasted time spent processing a loan for which the applicant is not eligible.
Many organizations may find it best to have the IT staff maintain the ruleflows, especially in the initial phases of development. However, if business users are comfortable with the ODM platform and would like to consider making these changes on their own, recent versions of ODM do support this capability.
ODM’s strength as a BRMS compared to others is in the business empowerment it brings. However, for direct business involvement to be a reality, the rules must be easy to work with and understand. Unlike a code-driven BRMS, we can see that the most common rule artifacts used by ODM can present the rules to the business in a clear way that needs very little deciphering, so rule authors can “hit the ground running” when they start using it. The Action Rule, Decision Table, and Ruleflow can be used to do just that. (READ: WHAT IS ODM RULES?)