Ztech Blogs

take our word for it

IBM ODM Rule Implementation Standards and Best Practices

Software products and code are used and edited by large number of people within the organization for many years, therefore following standards is extremely important in software development. IBM Operational Decision Management (ODM) rule development is no exception.  Following IBM ODM rule development standards and best practices is crucial for implementing a readable, reusable, robust and efficient rule application.

1.   Action Rules

     i.        Atomicity of the Rules

Atomicity applies to logic, not implementation. Because of performance considerations, rules might not be implemented ‘as is.’ Here are few tips on how to make rules atomic:

  • To make action rules atomic, look for multiple action statements as a result of the same condition. Look for AND on the right side of the rule or after THEN: IF A THEN do(B) AND do(C) must become IF A THEN do(B) and IF A THEN do(C).
  • Another clue that a rule is not atomic is when there are multiple conditions joined with “OR.” For example, IF A OR B THEN do(C) would become IF A THEN do(C) and IF B THEN do(C).
  • Break down the nested “If”. ODM action rules do not support nested “if”s, therefore it is a must-do item regardless.
  • Avoid using “else” statement.
“OR” in Conditions if (C1 or C2) then A

(C1 and C2 being mutually exclusive

if C1 then A

if C2 then A

“AND” in Actions if C then (A1 and A2) if C then A1

if C then A2

Nesting if C1 then (A1; if C2 then A2) if C1 then A1

if (C1 and C2) then A2

Use of “else” if C then A1 else A2 if C then A1

if not C then A2


     ii.        Standards for Rules with Multiple “AND” Conditions

Here is an example of different implementations of the same rule. They are logically equivalent.



There are no universal standards for one approach versus another, but whatever the choice is, it must be followed universally within the enterprise. My recommendation is the following:

  • Use the first option (all of the following conditions are true) if there are 3 or more conditions
  • Use the second option (and) for rules with 2 conditions

     iii.        Standards for Rules with Multiple “OR” Conditions

One can argue that rules with multiple “OR” conditions can and must be converted into separate atomic rules, each of which will have a single condition. That is the recommendation, but there are exceptions to the rules. The following example will illustrate the exception. Here is an example of different implementations of the same rule. They are logically equivalent.




What makes this case different is the fact that all of the conditions in the rule use the same data attribute (the status). For this category of rules the best practice is to use the last option, i.e. “is one of” operator.

2.   Decision Tables

Decision Tables Represent a set of rules with the same set of conditions and actions. Tables provide efficient and intuitive representation of the rules and benefit from gaps/overlap checking. Here are few tips on dealing with Decision Tables:

  • Remember to use pre-conditions
  • Merge rows with same conditions, it will make the table more readable and maintainable
  • Limit decision tables to 10 columns and 50 rows where possible. Otherwise this becomes impractical to manage on the business side. These can easily be broken down.
  • Where common conditions and actions occur in two or more rules decision tables should be considered.
  • Preconditions for decision tables and definitions are good ways of filtering but should not be too complex. If they are too complex, then use intermediate variables and or rules to simplify before the decision table is reached in the flow. If a variable for a condition column repeats throughout the decision table this should be moved to a pre-condition.

3.   Decision Trees

In a decision tree, conditions are depicted as nodes, values are represented by branch lines, and actions are displayed in boxes at the ends of branches. Decision trees provide an alternative and more convenient way of viewing and managing large sets of business rules, especially when these rules are not symmetric. Large sets of nonsymmetrical rules may be easier to understand using decision trees, where the path from the first condition to the end of the actions along any branch corresponds to one rule. Decision Trees are not commonly used and are not recommended to be used, unless there is a strong reason. Decision Trees are hard to read and maintain.

4.   Ruleflows

Ruleflows are a way of controlling rule execution. They are made of linked tasks that contain instructions which rules to execute and in what order. Here are few tips on working with them:

  • The flow should be high level and generic enough not to be changed unless there is a major change that would require IT involvement.
  • Reference the package (not individual rules) wherever possible. The reason for this is that in Decision Center the business can add rules without having to have development change the ruleflow for them. The flow artifact is not editable in this interface.

5.   XOM/BOM

The execution object model (XOM) is the model against which you run rules. It references the application objects and data, and is the base implementation of the business object model (BOM). Here are few tips regarding XOM/BOM implementation

  • Avoid using JRules functions for Java code (in IRL script). Prototype with functions, then move stable logic into XOM/BOM method.
  • XOM attributes for java reference types should be defaulted, i.e. no null values should exist (Type checking or NULL value checking should NOT be done by business rules, unless it is part of business logic). This can be achieved in a few ways depending on the complexity of the model. Complexities arise where defaults may conflict with logic; for example, max date as a default may conflict with a condition that checks for greater than a certain date and therefore unexpected behavior will arise.
  • The XOM/BOM should be built out with the view that future rules can be written on additional attributes that may not be used in the current release. The point of rules is to enable the business to write rules and this entails building out a solid base for their endeavors.

6.   BOM Verbalization

  • Do not use the characters ” (double quote), { (left curly bracket) or } (right curly bracket) in verbalizations, they will cause warnings and ambiguity problems when used in rules.
  • Do not use abbreviations such as “4” for the word “for” or “2” for the word “to”. Verbalizations are business-readable expressions.
  • Remember to agree on a uniform and simple policy for words capitalization.
  • Agree on how to denote the set of most commonly occurring business terms and concepts.


These are high level recommendations around commonly used ODM artifacts. It is critical to follow best practices and guidelines.  Zilker Technologies has best in the market resources to establish ODM rule development standards and best practices for a readable, reusable, robust and efficient rule application for both new and existing ODM projects.

About the Author

Artur Sahakyan

is an IBM Operational Decision Management (ODM) Architect with over 7 years of experience working with the product. Artur’s background is mathematics (probability/statistics) and he has as strong knowledge in finance. He also has a profound knowledge of IBM Business Process Manager (BPM). Artur is IBM certified on latest versions of both products.



Don't miss out! Get updates on new webcasts, events, and blogs.