How can we determine what is truly a rule engine and what isn't?

[Agility Alliance Network]

Are there any good criteria, standards, or guidelines for deciding whether a software pkg is truly a business rules engine (BRE)? I get the sense that some sw vendors and marketers use the BRE label to sell their products even though when you lift the hood the rule engine isn't there.

Those of us in the rules industry have an idea for what is and isn't a rule engine. But customer's aren't so sure. Maybe there is a report or list somewhere of what the minimum requirements are to be classified as a BRE.

For example, does an engine really have to use/support Rete, pattern matching algorithms, forward or backward chaining, inference, reasoning, etc.?

[James Owen]

Greetings:

First, use your real name! :-) [Rolando]

Second, almost all of the manuals and text books on the subject treat a rulebase as a program that contains some kind of inferencing engine, whether it be Rete or SOAR or whatever. And it has to manage data combined with a specific set of rules in order to obtain an answer to some question for problem. The subject of managing business rules specifically is a subset of the rulebase and not the primary concern.

It should (must?) be able to handle certain things such as pattern matching of many objects and many rules, universal (for all) relationships, existential (for any) relationships, is (not) equal, greater or less than relationships, etc., etc. Some say that a real "expert system" must have an explanation facility as well as a tutorial system and a GUI interface. However, these are not part of the basic definition. It should be able to handle things like NP-hard problems, complex problems, problems with insufficient data, etc. All of this is discussed in some detail in the seminal treatment by Gary Riley and Dr. Joseph Girratano - I strongly suggest that this should be the "jumping off" point of all questions. A further listing of books and white papers is on-line at http://www.kbsc.com/aibooks.html and the G&R book is #1 on that page.

All other things are further definitions of a rulebase. Forward or Backward Chaining is an attribute of the rulebase. A rule repository is another optional attribute. Templates, a user GUI, temporal processing or CEP are all attributes that a rulebase may or may not have. If a customer wants an instant answer, read the book and then give them whichever page you would like to reference.

And you have brought up another subject. Programmer after programmer after programmer has often asked me, "How do I get to be a Knowledge Engineer?" When I reference the link above and tell them to go read I usually get a blank stare. There is not such thing as "instant knowledge" and you cannot absorb within a few weeks or months what it takes fairly intelligent technical personnel years to accomplish. This is the one field where instant gratification leads to failed projects and losses in the millions of dollars for companies and IT departments who believe the rubbish spread by vendor sales persons.

SDG
jco

[James Owen]

BTW, a BRE (Business Rule Engine) is not necessarily a rulebase. It is simply a way to store and manage the business rules of a company. Business rules are usually simple in nature and massive in number. Excel is good way to manage business rules. And there are tools that will help you manage them without having to use a rulebase. For example, Rule Manager by Acumen (http://www.acumenbusiness.com/Products.htm) has such a tool. I wouldn't recommend it (not yet - I have not evaluated it yet) except for simple management applications.

SDG
jco

[Agility Alliance Network]

a BRE (Business Rule Engine) is not necessarily a rulebase. It is simply a way to store and manage the business rules of a company. Business rules are usually simple in nature and massive in number

Aren't we confusing BRE with BRMS? The BRE is the inference engine that executes the rules; the Business Rule Management System (BRMS) is the rule management tool that stores the rules, but doesn't execute them.

You also mentioned "real expert systems" while you were defining rule engines. I agree that business rules usually consist of many simplistic rules. But I've also noticed that most expert systems, on the other hand, consist of fewer, more complex, rules. Do you think that ES and BRE are really the same thing? I wonder how the ES term evolved into BRE in the first place. I always thought it was a marketer in an ES/BRE vendor!