• Un-Rule Engines for Business Rules

March 1 2009: added Postgres Rules, and a few edits.
Revised Oct 20 2008: This is a new "hybrid rule engine" category for the development site, more nut-and-bolts-oriented than most rule engine discussions.

A Rule Engine By Any Other Name?

What should one call rule engines without true inferencing capabilities. How can they be called rule engines if the don't do rule inferencing ? Maybe the best term is "un-rule engines", as if we were talking about the "un-Cola" of soft drink marketing fame.

Un-rule engines are appropriate for rule applications where a given set of rules and data behaves according to some relatively fixed criteria, where there is a well-defined subject of interest for a rule base, such as a type of business transaction, purchasing or selling a product for instance, or when the subject is  restricted to a certain area of inquiry, constructing a family tree, who is the uncle of whom, etc.

The key distinction is that an un-rule engine applies rules in a pre-determined order and working only within a restricted set of situations.

These are often called ECA engines ( Event-Condition-Action ) and they qualify as rule engines in the sense that they apply different rules to different datasets to trigger and execute a workflow, such as running "validate_customer_order". Most basic workflow and validation engines fall into this category. Typically, there is some sort of semi-fixed binding strategy or scheduling algorithm at the core of the engine to resolve execution conflicts. Frequently this is accomplished by defining order of priority or using weighting factors in trigger rules.

Some of these systems have been around for 20 years or more, are large and complex, and are often cranky in the extreme. Many rank among the legacy COBOL applications of yesteryear. Why would IT managers and developers implement these things and keep them going years after year ?

Reasons for Implementing Un-Rule Engines

First, they can be very fast: the per-transaction performance is typically 4-8 times that of a "real" inference engine. And remember that these horrible old COBOL behemoths were originally designed to ran on hardware that was the equivalent of a modern pocket calculator.

Secondly, the kinds of knowledge domain that these applications address often do not really require the power of an "real" inferencing engine. The knowledge domain, while large, is effectively closed rather than open - ideally, the problem space is completely understood and there is little or no new knowledge to be discovered. Consequently, the logic and sequence of rule firing can be more or less pre-determined by a small set of meta-rules - the few special situations can be handled by custom code without creating a maintenance nightmare.

Lastly. the companies that run these systems have often launched giant re-engineering projects to bring them into the 21st century and gotten very mediocre results ... that is, mediocre result when they managed to complete at all, which they often did not. A knowledge domain may be closed but it may still be very big, too big for a technological quick-fix. Insurance applications often fall into this category.

Sometimes the combination of standard knowledge engineering techniques and well-established software technology can achieve better results than either alone. The project can avoid the pitfalls of assuming that the solution is an inference engine or else falling for the fallacy that "we can code our way out of this". When confronted with an inherently complex domain, success may depend on powerful rule-based tools for both the analysis and implementation of the solution.

Many of the necessary components are open source and open license. A very promising technology for un-rule engine solutions is plain old relational database engines, using the very old trick ( probably with a brand new software patent slapped on it ) of treating rule structures as relational entities in the database. In particular, recent versions of mySQL support triggers and procedures. Postgres is quite sophisticated, probably as sophisticated as any commercial database, and seems to be gaining users and greater acceptance on the last few years.

All in all, great stuff for building rule-based applications without the necessity of an inference engine.

Using Relational Database Navigation as a "Rule Engine"

One approach to developing at least a partial solution for a business rules engine without getting into the arcane mechanics of inferencing is using a relational database to drive the engine.

The fundamental problem with this approach is 'reachability', where parts of the deductive "tree" can not be reached by a relational database. In practice, however, many of the benefits of a business rules engine such as flexibility and easy reconfiguration can be realized without an actual rule engine, as outlined in the articles below.

The primary link is to an O'Reily article titled Put Your Business Rules In Your Database. Note the comment by the author "Paul: I understand your concern, but many business rules should be relatively invariant ...". This is a critical point. If a business rule never changes, then it might as well be in the database. Even better, hard-code it !

For a software configuration approach to un-rule engines, see Automatic Generation of Rule-based Software Configurations ( PPT ). The 'rule engine' in the architecture is not necessarily an inferencing rule engine - it could also be a complex database with a navigation engine or even a code generator for a workflow 'scheduling engine' application.