Missing Goals and Requirements in Business Rules

Both of the following statements are true, but the first is more informative:

  1. Business Rules Management Systems (BRMS) typically produce forward chaining production rules that are interpreted by[1] a business rules engine (BRE) based on the Rete Algorithm.
  2. BRMS typically generate rules that are interpreted by a BRE.

First, dropping the word “production” before “rules” loses information. BRMS do not typically generate rules that are not production rules. Consider, for example, the BRMS vendors involved in the OMG effort produced the Production Rule Representation (PRR) standard. The obvious question is:

  • What is different about production rules?

Second, dropping the words “based on the Rete Algorithm” loses information. The dominant rules vendors and open-source engines are all based on the Rete Algorithm.

  • Why does the Rete Algorithm matter?

Third, dropping the word “chaining” before “rules” loses information. Chaining refers to the sequential application of rules, as in a chain where each link is the application of one rule and links are tied together by their interaction. But:

  • Why does chaining matter?

Fourth, dropping the word “forward” before “chaining” loses information. Forward chaining reacts to information without requiring goals. This begs the question:

  • Don’t goals matter?

What is different about production rules?

In a system where rules are not productions, new knowledge must be positioned within the existing knowledge. In the worst case, the cost of adding a new rule is proportional to the existing number of rules. That is, the cost of acquiring new knowledge increases as knowledge accumulates. The ability to improve at constant cost is the basis of agility that comes from using production rules to implement business rules.

The term comes from automata theory, in which the rules that define a formal language are called “productions”. The important thing about productions is that the formal language they define does not depend on their order.

For example, changing the order of rules expressed in Backus Normal Form (BNF) will not change the definition of a language (e.g., Pascal). This is distinct from “if-then-else” statements in procedural languages where order is clearly relevant.

Also consider that the order of logical formula does not matter to a theorem prover.[2]

Procedural rules (including if-then-else statements in procedural languages and decision trees) are less agile. The effort required to codify them increases as the amount of pre-existing code increases.

The irrelevance of order is the critical ingredient of agility.

Focus on truth. Minimize context.

Why does the Rete Algorithm matter?

The agility of production rules would be less practical if performance degraded as more rules were added. For a practical business rule system, performance must scale less than linearly with respect to the number of rules. That is, if doubling the number of rules always cut performance in half, the applicability of rules might be limited. Ideally, adding a rule would have zero impact on performance.

I’ve written about these topics many times[3] and there is plenty available on the Web[4].

Essentially, in Rete, the conditions or antecedents of rules correspond to SQL queries. Rather than check rules by running a sequence of queries against data, however, Rete compiles queries into a pattern matching network through which data flows. Performance of the first approach would clearly be linear in the number of rules (queries). The worst case performance of Rete can also degrade linearly as rules are added, but the expected performance is less since Rete effectively ignores conditions that are not satisfied by data.

Decades or experiments and commercial use have demonstrated that Rete typically scales up with performance that degrades far less than linearly. Here is the technically accurate statement:

The expected performance of the Rete Algorithm is asymptotically independent of the number of rules.

In practice, adding a hundredth or ten thousandth rule will have immeasurable impact.

Rete matters only because it implements unordered rules in an efficient and scalable manner. If you can implement rules without ordering them some other way, great – but consider chaining, too.

Why does chaining matter?

Chaining refers to the sequential application of rules, as in a chain where each link is the application of one rule and links are tied together by their interaction.

Without chaining, inference is impractical.

Chaining is a key distinction between implementing rules using an engine versus in procedural code. A rules engine can string inferences together to reach conclusions involving several steps, where each step is expressed in a rule. Procedural languages provide no support for reaching intermediate conclusions and building further upon them.

Without chaining, a system cannot be intelligent.

Chaining is your greatest source of leverage for semantics and intelligence. By writing statements[5] that are true you can leverage deduction. Doing so makes all your statements less verbose and more reliable.

Don’t Goals Matter?

Backward chaining involves working backwards from goals to the current state of the world. Therefore, backward chaining requires a goal. Problem solving involves goals.[6]

Forward chaining involves working forward from the current state of the world. Forward chaining does not require goals. Forward chaining is behavioral and – without goals – strictly reactive.

Unlike artificial intelligence and logical rule systems, PRR and all but one BRE based on the Rete Algorithm are limited to forward chaining.

Forward chaining systems are inherently limited to “if” and “then”. When the “if” is satisfied they want to conclude or execute what comes after the “then”. Which “ifs” are satisfied, is determined or driven by data, of course.

Unfortunately, the data-driven aspect of forward chaining is often confused with the data-driven nature of the Rete Algorithm. The fact that the Rete Algorithm is data driven has nothing to do with whether it can support backward chaining.[7] The lack of support for goals in the business rules market is the issue, not the Rete Algorithm.

I have previously supported backward chaining using the Rete Algorithm. The details are available on-line[8], from Haley Systems, or by request. More vendors need to step up their support in this area. The open-source community is actually ahead of most!

Support for backward chaining will allow business to use more logical deduction without as much need to indicate when to perform or how to control inference. Subgoaling will focus inference. This will encourage and facilitate increasingly large and sustainable repositories of knowledge.

Even with improved deductive capabilities using backward chaining, BRMS will remain inadequate for requirements, however.

Why can’t BRMS handle requirements?

In order to support emerging standards from OMG[9] and W3C[10], BRMS need to handle logic that is not limited to the “if-then” or “A implies B” form of rules. Such statements include definitions and constraints[11]; or, more generally, requirements.

Requirements do not fit the “if then” paradigm of today’s business rules systems. They do not pose any challenge to logic systems, however. Current rules technology requires an antecedent. A formula in the predicate calculus does not.[12]

This results in all sorts of distortions in the business rules market. Worst among them, in my opinion, is the distinction between requirements management and rules management on which I will post shortly.

[1] i.e., runtime code uses a rule engine to determine and apply applicable rules
[2] e.g., theorem provers and other logic systems, such as HiLog or Flora
[3] e.g., Answers to Common Questions about AI in the early nineties, which I found on-line here.
[4] A summary and key references on the Rete Algorithm are available here.
[5] I say statements instead of rules because truth is often definitional without using the word “if”.
[6] In general, a partial order. See the Problem Space Hypothesis.
[7] There are rudimentary capabilities for subgoaling in JESS and Drools, each of which uses Rete.
[8] see Data Driven Backward Chaining (formerly Opportunistic Backward Chaining in IJCAI 87).
[9] OMG’s Semantics of Business Vocabulary and Rules (SBVR)
[10] W3C’s RIF and OWL and other semantic web activity
[11] e.g., referential integrity
[12] On the other hand, logic systems cannot handle the practical, action-oriented aspects of business rules.

3 Replies to “Missing Goals and Requirements in Business Rules”

  1. Hi Paul,

    Would you please share your thoughts and expereince about natural language processing: its current status, issues, and challenges?


    Gene Weng

  2. Greetings Gene!

    Re NLP, I think it is a requirement for effective policy management provided its technical limitations can be overcome to a useful degree. Authority took a practical approach with respect to business rules that works well, as evidenced by its customer successes.

    Eliminating speech, typing errors, and poor grammar from consideration makes NLP much more tractable. Ambiguity is an exaggerated problem in practice and can be resolved through question (or displaying conflicting interpretations) fairly easily, particularly for sentences that do not run on.

    The principal issue right now is the lack of comprehensive, semantically rigorous ontologies with vocabularly mappings. A cross between a standard dictionary, WordNet and OWL would be very useful. Such linguistically-enhanced, semantically rich models are particular valuable when they cover a standard in a large vertical, such as ACORD for property & casualty insurance. It’s not as important for domains with 3 figure vocabularies, though.

    Interesting challenges include multi-lingual support and relaxing the noise thresholds (e.g., less grammatical rigor, spelling errors or speech).

    There are also issues of caution required of any technology that may take action, but caution may not be critical for query-only applications, for example. This demonstrates that pertinent issues and challenges are, to a significant extent, dependent on your objectives.

  3. Thanks for your insights, Paul!

    This is a great blog and it definately deserves more attention. I have added it to my little knowledge base about rules: http://www.squidoo.com/businessrules

    One of the nices things is the rule community is still relatively small and people get to know each other sooner or later.



Comments are closed.