Topic: Consistency

Your Business Rule System is a Fool

Dietrich Kappe, Thursday, July 20, 2006 @ 8:00 am

He who knows not, and knows not that he knows not, is a fool - shun him.
He who knows not, and knows that he knows not, is a child - teach him.
He who knows, and knows not that he knows, is asleep - wake him.
He who knows, and knows that he knows, is a wise man - follow him.

The above is either an Arabic, Persian or Chinese proverb. I known not, so take your pick. But you could learn something from it for your business rules project.

Even after you've gone through the trouble of pulling your business rules out of existing applications and processes and centralizing them in a rule repository, you could still face problems of a logical or informational variety. You're business rule system may not have the necessary data, or it may have wrong data, or it may have the wrong kind of facts. The system may further not have all the right rules, or some bad rules or it may even come up with some unpleasant conclusions you didn't expect at all. In short, it may be a fool, a child, asleep or even a wise man, all at once, and even a few other choice epithets not included in the above proverb.

To make sure your business rule system behaves well, there are a few specific factors you should consider. I'll blog about them in the next few weeks, digging a little deeper and proposing some remedies along the way:

• Data (or Fact) Consistency - If you've got Joe being both 16 and 45 years old, you've got a problem. If that situation seems absurd to you, I tip my hat. You're clearly one of the chosen few whose data is consistent across all of your firms databases. The kinds of data inconsistencies can go much farther, such as a 5-year-old having a husband, or a dead man requiring a liver transplant. The solutions to these data consistency problems are for the most part very unglamorous techniques from the world of data modeling.

• The Wrong Kinds of Facts - If you've ever design OO software or designed a database, you know what I'm talking about. If your entities are the wrong kind, the wrong size, or incomplete, you will kill yourself writing awkward code. These entities and associated behaviors are like your nouns, verbs and adjectives. Pick the wrong words and your sentences are hard to write. If you capture only the final bill in a system and not the details of the transaction that incurred the bill, you may still be able to extrapolate the transaction information, but you have to work harder to do it. Too much hard work and the system limits rather than enables your ability to describe your business rules.

• Rule Consistency - What if given a clean, consistent set of facts, your rule set allows you to arrive at A and Not A -- "Joe is a minor" and "Joe is an adult?" With a few hundred or a thousand rules in your set, this problem may be hard to discover. (I'd add rule execution order independence to this category.) In fact, tracking down rule inconsistencies can be a bit tricky, with a couple of not quite satisfactory solutions available.

We'll leave off from things like decidability, as they probably don't have much bearing on BRE's, and cross product matching, as that's really more of a performance issue. I would advise you to be prepared, however, for your cauldron of rules and facts to sometimes deliver you some unexpected results. If you've done more than just 1 + 1 = 2, they can surprise you and perhaps grow past your own abilities. You've built a child and taught it to be a wise man -- or maybe it's just a fool that's mouthing off.

• Digg
• Reddit
• del.icio.us

Comments (1)

business rules engines