Every time I go to a business rule related event, I see loads of attendees walk out of the various presentations shaking their heads. "Where do I plug it in?" It’s possible that this state of affairs comes about because the vendors and presenters do such a poor job of explaining the technology, or because they are trying to oversell it. If I had a bunch of speakers telling me that I needed to harvest all of the business rules across my enterprise and realize them in a BRE, I might be a little panicked as well.

So I thought I’d offer some patterns of usage for business rules engines to make their possible use more concrete. The first one is what I call Fact Harvest, a pattern for forward-chaining engines. The basic idea is that you create an object model that corresponds to your "facts," write rules to produce new objects or "facts," then harvest the newly created facts from the engine or wherever you’ve stored them.

Here’s a reification of this pattern from an insurance claims handling context. Suppose you want to provide your claims investigators with suggestions on how to proceed in a particular case. Your "facts" in this case might be rows in a database, from tables such as

• Claim
• Policy
• Incident
• Reserve
• Valuation
• Assessment
• Authorization
• Insurance Object

Each of these rows of course have multiple columns/attributes. Some rule engines have the ability to map rows directly to facts in a BRE’s working memory, with others you might use something like an ORM framework to read in the rows and insert them into the working memory.

A simple implementation would involve a Java application that reads in the data for each incident, populates the working memory, runs the rules — which produce the new Fraud Warning facts, either inside or outside the working memory, depending on whether they are used for further inferences — then harvests those facts and populates a Fraud Warning table in the claims database. These can then be used in reports, work-flow, you name it.

Seems almost too simple? There is the matter of writing the rules, of making sure your data model is complete enough to support meaningful reasoning. Also, there is the matter that most forward-chaining rule engines don’t support easy justification, i.e. explanation of how a conclusion came about. But at base, this pattern can be very simple.

I’d love to hear if this explanation was useful to anyone and whether it was at the right level of detail, too glossy or too in the weeds.

Share/Bookmark