Five Useful Technical Patterns for Operational Decision Management
cheryl wilson 270003VHSH email@example.com | | Tags:  operational-decision-mana... brms business-rules decision-management business-rule-management
1 Comments | 6,568 Visits
Technical patterns are useful as best practice guides for both selecting and using technology. The technical patterns for IBM Operational Decision Manager (ODM) technology can be divided into two sets, those that align with its business rules capabilities and those that align with the business events capabilities.
For this post, we’ll start with five technical patterns for business rules, in no particular priority order:
1. Complex or Volatile Routing
ODM helps in both of these cases: complex or volatile routing. First, with ODM you can build complex rulesets and decision tables … in a way that a business user can understand (and approve!). This pattern is commonly used where routing is dependent on a combination of business variables. Second, ODM enables encapsulation of rules separate from other components, making it easy to change the rules without needing to change the rest of the system.
2. Input Data Validation
However, there are many scenarios where the data fields are dependent on one another and/or where the checking of fields change frequently (e.g. limits on numeric values). This is where rules come into play. This is especially true when there are complicated forms where inconsistencies and inter-relationships between fields are crucial or even life saving (e.g., medical information). However, it’s also important where bounds on fields such as interest rates or deposit minimums/maximums change on a frequent basis.
3. Data Enrichment and Calculation
There are scenarios where it’s applicable to use the rules engine as a data enrichment and/or calculation engine. In these situations, you can use the rules engines for complex rule-based calculations such as working out an insurance premium based on the set of (sur)charges, special discounts, etc., or calculating sales tax which can be a complex task dependent on the location and size of the sale. This is not entirely dissimilar to the first pattern above, but it’s different enough to be interesting on its own.
4. Data Augmentation
of Decision Service Requests
This pattern is for scenarios where the full set of data required to invoke a set of business rules is not available to the calling application. In this situation, you would generally insert some additional component, such as an ESB, between the caller and the rules engine to “make up the difference“ because components like ESBs are really good at this and rules engines less so. So, you would want to use the optimum capabilities of each of component. Some might debate whether this is really a business rules pattern or a pattern applicable to the higher layer scenario, but I think that it’s still worth including here.
There are many applications out there today that have business rules embedded within them. Many observers think only of mainframe systems and COBOL applications in this context, but any language and any environment is applicable. For many business scenarios, these applications represent business rules trapped within code – where there’s no easy way to figure out what the rules are and there’s generally no easy way to change them in a timely manner. Extracting the embedded business rules and implementing them in a rules engine addresses both of these concerns.
End note: These are not the only patterns for business rules, but they are a useful starter set. In a future blog post, I’ll discuss the technical patterns for ODM business events. Stay tuned.
This post was contributed by guest blogger, Stuart Jones, IBM BPM Solution Architect. Thanks, Stuart.