Goals and backward chaining using the Rete Algorithm

I was prompted to post this by request from Mark Proctor and Peter Lin and in response to recent comments on CEP and backward chaining on Paul Vincent’s blog (with an interesting perspective here).

I hope those interested in artificial intelligence enjoy the following paper .  I wrote it while Chief Scientist of Inference Corporation.  It was published in the International Joint Conference on Artificial Intelligence over twenty years ago. 

The bottom line remains:

  1. intelligence requires logical inference and, more specifically, deduction
  2. deduction is not practical without a means of subgoaling and backward chaining
  3. subgoaling using additional rules to assert goals or other explicit approaches is impractical
  4. backward chaining using a data-driven rules engine requires automatic generation of declarative goals

We implemented this in Inference Corporation’s Automated Reasoning Tool (ART) in 1984.  And we implemented it again at Haley a long time ago in a rules langauge we called “Eclipse” years before Java.

Regretably, to the best of my knowledge, ART is no longer available from Inference spin-off Brightware or its further spin-off, Mindbox.  To the best of my knowledge, no other business rules engine or Rete Algorithm automatically subgoals,  including CLIPS, JESS, TIBCO Business Events (see above), Fair Isaac’s Blaze Advisor, and Ilog Rules/JRules.  After reading the paper, you may understand that the resulting lack of robust logical reasoning capabilities is one of the reasons that business rules has not matured to a robust knowledge management capability, as discussed elsewhere in this blog.  Continue reading “Goals and backward chaining using the Rete Algorithm”

Behind the CEP curtain – it’s about time, not the cache

TIBCO is the CEP vendor most focused on the market for business rules, as reflected in Paul Vincent’s post here.  Although I agree with Paul that rule vendors are not currently offering enough in terms of support for long-running processes, the conclusions that he draws in favor of considering a CEP alternative to a BRMS are not compelling yet.

Paul said that rules don’t address the following that are addressed by CEP:

  1. BAM (business activity monitoring) and the other BPM (business performance management)
  2. Complex-rule processing
  3. Customer-centric (portfolio-based) decisions / policies

I am sure Paul was just being flippant, but you may notice that there is a bit of a war going on between CEP, BPM and rules right now.  Continue reading “Behind the CEP curtain – it’s about time, not the cache”

Externalization of rules and SOA is important – for now

James Taylor’s notes on his lunch with Sandy Carter of IBM and the CEO of Ilog prompted me to write this.  Part of the conversation concerned the appeal of SOA and rules to business users.  Speaking as a former vendor, we all want business people to appreciate our technology.  We earn more if they do.  They say to IT “we want SOA” or “we want rules” and our sale not only becomes easier, it becomes more valuable.  So we try to convince the business that they are service-oriented, so they should use SOA.  Or we tell the business that they have (and make) rules, so they should use (and manage their own) rules.   And rules advocates embrace and enhance the SOA value proposition saying that combined, you get the best of both worlds.  This is almost precisely the decision management appeal.  Externalize your decisions as services and externalize rules from those services for increased agility in decision making.   This is an accurate and appropriate perspective for point decision making.  But it doesn’t cover the bigger picture that strategic business people consider, which includes governance and compliance. 

Nonetheless,

Effective SOA and business rules have one requirement (or benefit) in common: externalization.  

The externalization of services from applications Continue reading “Externalization of rules and SOA is important – for now”

Oracle should teach Siebel CRM about location and money

Not long ago I posted on the need to understand common concepts well. My example then concerned the need to understand time well enough to answer a question like, “How much did IBM’s earnings increase last quarter?”. Recently, in contemplating some training issues related to the integration of Haley Authority within Siebel, I came across examples phrasings from the documentation on Siebel’s web site, including:

  • if an account’s location contains “CA” then add 50000 in “USD” for the account
  • if an account’s location contains “CA” then add 70000 in “USD” on today for the account

Two things are immediately obvious.

  1. Oracle does not understand location.
  2. Oracle has an interesting, but nonetheless poor understanding of money.

Of course, I am intimately familiar with Authority’s understanding of money. However, Siebel needs more than Authority understands. Continue reading “Oracle should teach Siebel CRM about location and money”

CEP crossing the chasm into BPM by way of BRMS

Complex event processing (CEP) software handles many low-level events to recognize a high-level event that triggers a business process.  Since many business processes do not consider low-level data events, BPM may not seem to need event processing.  On the other hand, event processing would not be relevant at all if it did not occasionally trigger a business process or decision.  In other words, it appears that:

  • CEP requires BPM but
  • BPM does not require CEP

The first point is market limiting for CEP vendors.  Fortunately for CEP vendors, however, most BPM does require event-processing, however complex.  In fact, event processing is perhaps the greatest weakness of current BPM systems (BPMS) and business rules management systems (BRMS), as discussed further below. Continue reading “CEP crossing the chasm into BPM by way of BRMS”

Agile Business Rules Management Requires Methodology

Don’t miss the great post about his and Ilog’s take on rule and decision management methodologies by James Taylor today (available here). 

Here’s the bottom line:

  1. Focus on what the system does or decides.
    • Focus on the actions taken during a business process and the decisions that govern them and the deductions that they rely on.
    • In priority order, focus on actions, then decisions, then deductions.
  2. Don’t expect to automate every nuance of an evolving business process on day one – iterate.
    • Iteratively elaborate and refine the conditions and exceptions under which
      • actions show be taken,
      • decisions are appropriate, and
      • deductions hold true

Another way of summing this up is:

Try not to use the word “then” in your rules!

Do check out the Ilog methodology as well as the one I developed for Haley that is available here.  The key thing Continue reading “Agile Business Rules Management Requires Methodology”

Rules are not enough. Knowledge is core to reuse.

James Taylor’s blog today on rules being core to BPM and SOA in which he discussed reuse had a particularly strong impact on me following a trip yesterday.  During a meeting with the insurance and retail banking practice leaders at a large consulting firm, we looked for synnergies between applications related to investment and applications related to risk.  Of course, during that conversation, we discussed whether operational rules could be usefully shared across these currently siloed areas, but we landed up discussing what they had in common in terms of business concepts, definitions, and fundamental truths or enterprise wide governance.  It was clear to us that this was the most fruitful area to develop core, reusable knowledge assets.

In his post, James agrees with the Butler Group’s statement:

Possibly the most important aspect of a rules repository, certainly in respect of the stated promise of BPM, Service Oriented Architecture (SOA), and BRMS, is the ability for the developer to re-use rules within multiple process deployments.

I have several problems with this statement: Continue reading “Rules are not enough. Knowledge is core to reuse.”

Haley / ART syntax lives on in open-source Java rules

The ART syntax lives on in yet another product! 

JBOSS Rules (formerly Drools) just described its imminent support for rules expressed in the CLIPS syntax here.

NASA derived CLIPS from the syntax of Inference Corporation’s Automated Reasoning Tool (ART) in the mid-80s.  I designed and implemented the ART syntax with Chuck Williams on a team with Brad Allen and Mark Wright. 

CLIPS didn’t have many of the features of ART (including an ATMS or backward chaining, for example), but it Continue reading “Haley / ART syntax lives on in open-source Java rules”

Understanding events and processes takes time

We have been teaching a computer to answer questions like, “How much did IBM’s earnings change last quarter?”  It takes a fair bit of knowledge, including how to understand English, to answer this question.  But teaching it what a “quarter” is brought back memories of debates with some former CMU colleagues about what units are and how to model time.  Since quite a few people ask me for help with knowledge engineering and ontological matters, I thought some might be interested in parts of those debates.As you will see, a strong upper ontology of common knowledge is required to understand common business knowledge.  Leveraging such an ontology is the only way to deliver business rules for under $50.

Sentences like “do something if more than a number of possibly related things have happened within a timeframe of something else happening” or “do something if nothing happens within a timeframe following something happening” are extremely common in business process management (BPM), complex event processing (CEP), and workflow.  With a sense of time, a business rules management system (BRMS) can support BPM, CEP, and workflow applications almost trivially.  Without a sense of time, most BRMS force users to perform computations.

For example, without a sense of time and an infrastructure that supports it, the sentence “call a customer if no response is received within 30 days of notifying the customer of a delinquency” has to be transformed into something like “if a notice is mailed on a date and the notice is a delinquency and the date of notification has a day number then compute the date for checking by adding 30 to the day number and check for a response to the delinquency notice on the date for checking”.  The checking on a date for a response to a notice must also be implemented as a database (or persistent queue) of events to be polled or triggered by application code.  Then a second rule is required to implement the check, as in “if checking whether a response has been received to a notice and the notice was given on a date of notice and the notice was given to a customer and there exists no record of communication with the customer since the date of notice then call the customer”.  (Note that this is actually how most BRMS products would implement this.  The natural language approach I prefer handles the original sentence.)

The discussion here reflects the general structure and content that a usable ontology for business process management requires.  Most users of business rules management tools will find the need to understand and engineer this discussion in their tool of choice.  As my Haley Systems customers know, much of this is reflected in Authority’s built-in ontology and English vocabulary, but quite a few of the points discussed here reflect improvements, especially concerning the confusion between units and amounts.

As you will see the discussion takes careful thinking.  Some readers may find it onerous.  If at any time you have had enough (or if you simply cannot take anymore!), please skip to the end and decide whether to fill in the conclusions by revisiting the body.

Continue reading “Understanding events and processes takes time”

The $50 Business Rule

Work on acquiring knowledge about science has estimated the cost of encoding knowledge in question answering or problem solving systems at $10,000 per page of relevant textbooks. Regrettably, such estimates are also consistent with the commercial experience of many business rules adopters. The cost of capturing and automating hundreds or thousands of business rules is typically several hundred dollars per rule. The labor costs alone for a implementing several hundred rules too often exceed $100,000.

The fact that most rule adopters face costs exceeding $200 per rule is even more discouraging when this cost does not include the cost of eliciting or harvesting functional requirements or policies but is just the cost of translating such content into the more technical expressions understood by business rules management systems (BRMS) or business rule engines (BRE).

I recommend against adopting any business rule approach that cannot limit the cost of automating elicited or harvested content to less than $100 per rule given a few hundred rules. In fact, Automata provides fixed price services consistent with the following graph using an approach similar to the one I developed at Haley Systems.

Cost per Harvested or Elicited Rule

Continue reading “The $50 Business Rule”