Monday, December 04, 2006

The article that started it all?

Business Process Trends had an article posted by Steve Minsky who gave the example:

  • If a customer has good credit then assign a credit rate of 6
  • If a customer has good credit then assign a credit rate of 8

These rules, however syntactically correct, contradict each other; they would cause the arbitrary assignment of a credit rating of “6” to some customers and “8” to others. This intermittent kind of business logic error is extremely difficult to diagnose with even state of the art testing tools. After the system goeslive, it may be months with unknown losses of customers or unprofitable accounts until the error is detected and corrected.

Extremely difficult yes, but Acumen Business has put this functionality inside their Rule Manager. Discover your anomalies in Biztalk policies with the brand new Rule Manager here.

Note: that rules that use facts from assemblies in the GAC are causing problems on the rule anomaly algorithms. This hopefully will be addressed soon.


James said...

This may be new to BizTalk but this kind of basic rule consistency and completeness checking is actually really common in commercial rules products - Fair Isaac, ILOG, Corticon and others all have it.

Marco Ensing said...


Thanks for your comments.

I am familiar with Corticon and a bit with Fair Isaac and ILog. Corticons contradiction and completeness checks are limited to just a rulesheet. They also don't find self-anomalies in actions.

The Rule Manager of Acumen Business is much more advanced by taking all rules within a policy into account to analyze on any rule anomalies.

From my past experience (when I was working on CA's Aion), we know that Decision Tables and Decision Trees are powerful knowledge representations, but reality is that terms used in these rule formats are never exclusively used within these composite rule representations (being this a decision tree, decision table or rule sheet). Obviously whenever one term is shared among other rule representations, the rule verification algorithms must always consider all active rules in a policy (a.k.a. ruleset / rulebase)

Probably the concept is common, but the actual implementation has been rather a challenge for some of the commercial rule products.

I do not have a version of Fair Isaac, so I do not know their limitations.

Acumen’s Rule Manager is probably ahead of the curve here.

make files explained if you did not grew up with them

Here is a nice post on how to define makefiles for a go project and actually teaching you some makefile constructs: