Indeed, one of the challenges with ODM is that it is too flexible :) It will do a great job of running even poorly written rules. But like Peter our experience is that analysis and being declarative not procedural is key.
Original Message:
Sent: Mon May 06, 2024 01:48 AM
From: Peter Warde
Subject: Rule Introspection in ODM (reasoning the business rule match result)
Hi Jatin,
Yes, analysis and approach is the key to all this, so you are on the right track!
There is a tendency to think procedurally when designing decisions and rules. This is "developer-think". Business rules are not code. Code is a procedural sequence of instructions and algorithms.
Business rules are declarative statements about the business that tell you how it must run. For example
A customer from Atlanta must be given a $10 coupon
is declarative because it implies no order. It is a standalone statement expressed in the everyday language of the business. It is only when rules are expressed in business language as declarative statements that can they can easily be analysed, managed, validated and approved by business people. That's what great about ODM. It can do this. But you also have to have the right mindset!
------------------------------
Peter Warde
peterwarde@rulearchitect.com
Original Message:
Sent: Sun May 05, 2024 09:25 PM
From: Jatin Khanna
Subject: Rule Introspection in ODM (reasoning the business rule match result)
Thanks, for the clarification. I couldn't agree with you more, the need for better organising the rules as you said into a hierarchical model cannot be more emphasised. This is key to managing the level of complexity, access control and the efficiency of the decision service, a no brainer. In that regards we can certainly do much better on the business analysis side to establish a more structured hierarchical approach to decision making. This would be ideal, but our usage is far from ideal, our actors often typical front line business users (not IT) , rule management/deployment is targeted and often covert, requiring quick turnaround of business rules into decision services and front-line outcomes with 3M outcomes daily. Decision Service supporting policy driven uses cases (e.g. loan approval), often have the luxury of better analysis & time discretion. Not suggesting this principle can't be extended to all use cases including tactical uses cases. I guess the key here is initial decision analysis and distilled and normalised decision service design that provides a seed structure for the business users and evolve organically. Moving from a very traditional orthodox approach wherein business users have an all-in-one strategy to create individual, isolate business rules that provide an absolute outcome to now designing hierarchical decision model is a major shift for our business users coming from legacy platforms where each rule was managed/deployed individually vs a family of business rule working together in a ruleflow organised through rule packages.
Certainly, from your response I did not literally infer creation of 2999 more packages to support the remaining business rules, but rather the need to organise these rules better that provide more logical grouping (micro-decisions) to then facilitate the application of techniques such as rule chaining, algorithms, exists etc.
I guess we will continue to enforce the need for better decision analysis and approach supported by education to overcome this business decision making challenges. I appreciate your response and time Peter.
regards
Jatin
------------------------------
Jatin Khanna
Original Message:
Sent: Fri May 03, 2024 07:15 AM
From: Peter Warde
Subject: Rule Introspection in ODM (reasoning the business rule match result)
You wouldn't have the remaining business rules in the same package, Jatin. They would go in other packages applied to other ruleflow tasks. Only the $10 coupon policy rules go in the $10 coupon policy package as they are the rules that apply the business policy of rewarding a customer with a one time $10 coupon.
This activity of creating the hierarchy of projects and the packages is Decision Center repository design. It is important for the organisation a large number of rules, and useful when you when you want to create rulesets based on a subset of rules in the repository using dependencies in the hierarchy and | or ODM extractors. You can also use packages and projects to provide access controls and permissions for rule authors in Decision Center. It is usually based on the organisation of rules into business policies by analysts.
I will reply to your other much longer message to me when I have some time as there is quite a lot in it.
It's good that your post has generated so much comment!
------------------------------
Peter Warde
peterwarde@rulearchitect.com
Original Message:
Sent: Fri May 03, 2024 02:22 AM
From: Jatin Khanna
Subject: Rule Introspection in ODM (reasoning the business rule match result)
Thanks Peter. I believe you are referring to following exit criteria setting in the rule flow
- Rule: All the rule instances of the first applicable rule run for a tuple before moving to the next tuple.
- Rule Instance: Only the first rule instance of the first applicable rule runs for a tuple before moving to the next tuple.
In either of the cases only first applicable rule / instance of the rule would be fired from the rule package, which would works fine of the simple example. The key here is the selection of the rules based on incoming tuple objects. Let's extrapolate from your suggestion to 3000+ "business" rules.
We started with a business rule (say Rule R1) then decomposed this to say (Rule1.1 and Rule 1.2 from your example) working on the same tuple objects. With rule package algorithm =sequential, exit criteria=Rule and ordering=default, the rule package completes once either Rule1.1 or Rule1.2 match.
How do you then propose the remaining "business" rules, Rule R2...Rule R3000 (yet to be decomposed) that sit in the same rule package "$10 coupon policy" be organised? I would assume there is a better way to organise the rule flow given that Rule R2...Rule R3000 (mostly homogenous, applying towards the same incoming tuples objects, still need to be executed?
Regards,
Jatin
------------------------------
Jatin Khanna
Original Message:
Sent: Thu May 02, 2024 11:59 AM
From: Peter Warde
Subject: Rule Introspection in ODM (reasoning the business rule match result)
I am not sure why rule authors have to order the rules or set the exit criteria Guilhem.
In the example you give ....
if someCommonCondition and the city of the customer is 'Atlanta' then give the customer a $10 coupon
if someCommonCondition and the income of the customer is greater than 100k then give the customer a $10 coupon
... there are no dependencies between the 2. The order does not matter.
With regard to setting the exit criteria, this is a property of a ruleflow task. Ruleflow is normally designed by the rule architect and set up by the rule developer in Rule Designer and published to Decision Center.
If these rules are added at package level to the ruleflow task (both called $10 coupon policy) , all the rule author needs to know is to create these rules and any other rules that give a $10 coupon, in the right package in Decision Center i.e. $10 coupon policy package, and everything is taken care of. All other detail is hidden from the rule author. It's a clean solution.
------------------------------
Peter Warde
peterwarde@rulearchitect.com
Original Message:
Sent: Thu May 02, 2024 08:54 AM
From: Guilhem Molines
Subject: Rule Introspection in ODM (reasoning the business rule match result)
Yes, this can help. In my example above, this would prevent both rules to fire, but would still put the onus on the rule writer to order them properly and set exit criteria - assuming most rules have the ability to turn a flag to trigger the exit criteria. Or, use a hit policy in the case of a Decision Model (in ADS).
But still, it's not a sufficient solution by itself, and forces to include non-business related elements within rules, so it's not so clean I think.
------------------------------
Guilhem Molines
Original Message:
Sent: Thu May 02, 2024 04:40 AM
From: Peter Warde
Subject: Rule Introspection in ODM (reasoning the business rule match result)
How about using the Exit Criteria property on a rule task?
"The Exit Criteria property specifies whether all the rules run or just the first instance of the first rule runs."
https://www.ibm.com/docs/en/odm/8.12.0?topic=execution-properties-rule-tasks
------------------------------
Peter Warde
peterwarde@rulearchitect.com
Original Message:
Sent: Thu May 02, 2024 03:44 AM
From: Guilhem Molines
Subject: Rule Introspection in ODM (reasoning the business rule match result)
Thank you for providing us with insight on your business problem.
In general, the points made above by James and Eduardo are correct, that is adopt decision tables and avoid uses of "or" by breaking down a rule into several.
That said, they are cases where this doesn't apply. Your example with ice cream flavor is hiding the true complexity, as the flavor can be vanilla or strawberry but not both. Let's look at an example where the or can't be treated as a xor.
For example:
if someCommonCondition and (the city of the customer is 'Atlanta' or the income of the customer is greater than 100k ) then give the customer a $10 coupon
In such a case, breaking the rule in two:
if someCommonCondition and the city of the customer is 'Atlanta' then give the customer a $10 coupon
if someCommonCondition and the income of the customer is greater than 100k then give the customer a $10 coupon
doesn't work, as the customer could get 2 coupons.
Likewise, moving those in two rows a of Decision Table doesn't work, as the rules are not using the same conditions, and thus this would generate a DT with 3 condition columns and some gaps. With a real size ruleset, these grow horizontally to a point where it's not manageable anymore.
Consequently, we need a technical solution. I'm working with another customer who raised the exact same requirement as you. As of today, we do not have anything easy in the product, but we're looking into it.
Thanks
------------------------------
Guilhem Molines
Original Message:
Sent: Thu May 02, 2024 02:27 AM
From: Jatin Khanna
Subject: Rule Introspection in ODM (reasoning the business rule match result)
Hi Peter,
I appreciate your feedback. I agree the complexity of the rules and the need for the rules to be atomic. Perhaps I should have comprehended the overall decision service complexity of our decision service better (something, I should have done in the original post). Most certainly not the mini-loan or the loan validation samples that are shipped with the product:
- Total Number of rules: 3000+
- Average rule conditions: 30-40 attributes across BOM hierarchy.
- Rule Complexity: Various combinations of if all, if any etc.
- BOM Attributes: 250+
- BOM Size: 1-3MB
- BOM Hierarchical levels: 4 levels
- Number of decision service invocations: BOM per day 3 million
- Business domain: National Security.
I understand and appreciate the best practices around "atomic rule" with a singular outcome. I practice its easier said that done with the complexity we have on hand. Whilst this is great conceptually, the business definition of a rule is the point at which they need to act ( the final outcome) , which is the complete business rule.
Apply the Decision Table and Atomic rules from the suggestion on the post to the current complexity, I can envisage the result as shown below:
=> 3000 DT decomposed to 3000 X 30 conditions = 9000 DT's => Typically growing horizontally because conditions use attributes disparately and their isn't always a consistent pattern.
=> Need 30 global variables at worst per DT to hold the intermittent line level results
=> rule chaining and aggregation to consolidate the results from intermittent
=> at this point since the rule is distributed/fragmented across a number of rule the comprehension/visualisation of the business rule becomes cumbersome or essentially lost.
Your comments in regard to "the request" is just for illustration in the mock profile that I literally typed (not from designer or DC) . We certainly do use this vocabulary for our business users.
I regards to using the term "Rule Introspection" in my post. I appreciate your point and redact. Really what we are looking for the reason for the match.
The point I am trying to make from this post is the current business users on MF on a legacy platform that provides them the full path of rule match in the response matching criteria matched against i/p BOM is not intuitive to ODM.
What I would have liked to see is a mechanism to query the match criteria for a given rule either in the working memory or a product api.
Regards
Jatin
------------------------------
Jatin Khanna
Original Message:
Sent: Wed May 01, 2024 07:04 AM
From: Peter Warde
Subject: Rule Introspection in ODM (reasoning the business rule match result)
Using OR in a rule condition is not a good idea, Eduardo. A rule should be atomic i.e. as granular as possible, cannot be further reduced or decomposed to another rule. Rules that are not atomic are difficult to understand and validate. They may contain too much complexity.
It is also good not to use the term "the request". It is an IT technical term and not a business term. You should stick to business terms.
------------------------------
Peter Warde
peterwarde@rulearchitect.com
Original Message:
Sent: Wed May 01, 2024 05:16 AM
From: Eduardo Izquierdo Lázaro
Subject: Rule Introspection in ODM (reasoning the business rule match result)
In fact, using OR in the rule conditions is like grouping several rules in one. If you split you rule, either in rows of a Decision Table or in individual rules, you could create a clear explanation for each:
if the flavor of the ice cream of the request is "Vanilla"
then Finalize reason "the flavor of ice cream is "+the flavor of the ice cream of request;
if the age of the client of the request is less than 8
then Finalize reason "the age of client is "+the age of the client of the request;
In some situations, depending on the requirements, using OR in rule conditions is kind-off small anti-pattern.
------------------------------
Eduardo Izquierdo Lázaro
Automation Architect
DECIDE
Madrid
609893677
Original Message:
Sent: Mon April 29, 2024 02:44 AM
From: Jatin Khanna
Subject: Rule Introspection in ODM (reasoning the business rule match result)
We have been using ODM since Jrule 7.0 days currently 8.10.5 which is going out of support tomorrow. We have plans to upgrade.
Since the beginning of ODM journey which was more than a decade and a half ago our business authors have been asking this question "When will rule introspection be available in ODM". In other words they are asking "please explain why my business rule has matched". Let's look at this business rule for example.
if any of the conditions is true :
- the flavour of the ice cream of the request is 'Vanilla'
- if any of the conditions is true:
- the age of the client of the request is less than 8
- the flavour of the ice cream of the request is 'Strawberry',
- the day of the week of the request is 'Sunday' and the the flavour of ice cream is 'Chocolate',,
then
Finalise reason for match using + the age of the client of the request + the flavour of the ice cream of the request + the day of the week of the request
Rule engine correctly identifies when this rule has matched but cannot provide any reasoning for a given BOM for why the rule has matched. In the case above when in action part of the rule, the rule engine has no knowledge of why it is processing the action of this business rule. Writing a reason for match accurately then becomes a challenge.
This is necessitated because we have two functional groups within the business the rule authors (policy makers) and the rule actors (shop front). The actors rely on the accuracy of the reason for match without necessarily having to relate the i/p BOM against the rule, to reason why the rule would have matched.
In reality our business rules look way more complex wih many conditions and BOM with greater than 300 attributes that the shown example which is just a simple exemplar for demonstrating the short coming of rules engine. We looked at the decision warehouse which only seems provides a view of which rules fired matched/not matched, i/p and o/p BOM etc, but does not go down to the condition that cause the business rule that resulted in the match.
We have tried to work around this issue by setting context parameters when the conditions are wrapped in BOM virtual methods e.g
- myVirtualmethod (the flavour of the ice cream of the request, 'Vanialla') in place of
- the flavour of the ice cream of the request is 'Vanilla' which retruns "true" when a match is found whilst setting the context parameter at the same time to be able to retrieve it in the action part and establish the reason for match. The context parameter is consumed in the action part and reset for the next rule. But we are now stuck with being able to execute the rule one-by-one for a clean cache, which I am unsure if it even possible with any algorithms supplied (Reteplus, Fastpath or sequential). The closest I came across of "sequential" but even that combined multiple rules in the execution scope depending on the homogenous nature of rules (same tuples).
It would be great to understand, if your business users have had similar issues
- In relation to rule introspection to provide the most accurate reasoning what conditions caused the match.
- In relation to the being able to better control the execution of the rules (not just dynamic BAL), like in our case one-by-one execution with the understanding that none of the algorithms enables this behaviour.
Any insights would be much appreciated.
Regards,
Jatin Khanna
------------------------------
Jatin Khanna
------------------------------