Paul Vincent writes a note explaining the virtues of a new customizable conflict resolution for inference rules:

Whenever I meet production-rule fan (and now co-chair of OMG Production Rule Representation) James Owen, he always asks me “so what exactly is the conflict resolution strategy in the TIBCO rule engine?“. Recently, TIBCO BusinessEvents 4.0 introduced a feature to make him (and other rule programming specialists) very happy – the customisable conflict resolution mechanism!

So, Paul isn’t talking BPM, he’s talking CEP and Rules- and he has an excellent blog for following news in that space.  But often people in the BPM space will tout a rules-based approach for BPM as being easier for the business… Whenever someone tells says that rules are easy, they should just explain a few phrases and see how comfortable they are doing so:

• production rule
• inference rule
• conflict resolution

So what is the customizing the conflict resolution stated above?  It is adding a rank to the rules to determine ordering, which is, um, different than rule priorities, which have priority over rank… got that?

Having worked in the high-end configuration space a decade ago, I don’t find this confusing or hard.  I’m just well aware that rule sets can quickly get difficult to understand by the lay person, while being very powerful in the hands of experts.

For a simple example, while configuring cars on websites (check out Ford‘s), the conflict resolution strategy was to assess rules against user selections first, and then applying the “completion engine” which would progressively apply default selections to complete a configuration.  The magic was that when the user made their next selection, our conflict resolution would prioritize user selection-inspired rules over “completion” (default) rules, and default rules had a “rank” for order of processing.  Thus, preventing innocent default selections from interfering with what the user wanted to explicitly select. But consumer car configurations are simple compared to the stuff we used to configure (jets, PBXs, super computers, mainframes, central office switches, high end networking gear), which required rules for resource allocation, spatial configuration, containment, composites, connections, and backward chaining heuristic search.  And these different types of constraints could compete or conflict with each other. Fun stuff.

It was very cool stuff (to the technical geeks), but it wasn’t for the faint of heart.  There is a time and place for rules – but the KISS approach applies.  Keep it simple, if you can.

Sandy has posted a pretty good presentation on mixing rules and process, which pretty well captures how I feel about the subject.  I’ve never understood why the rules-vendors out there try to model the process using rules.  On the flip side, pure BPMS vendors sometimes fall into the trap of feeling they have to claim to have rules engines because the rules folks will try to claim that they have BPM.  I think customers who are interested in both BPM and BR functionality could do themselves a favor by telling vendors up front that they are using separate packages for this functionality – they’re likely to get more candid answers from the sales folks from both companies, as it allows the vendors to play to their respective strengths.

I’ve deployed several projects that integrated a BPM platform with a rules product, and its just easy to do via webservices or an API call in all but the most extreme cases.  Anyway, enough from me, here’s a link to Sandy’s post.

Disclaimer:  I used to work for a company that did a lot of work in the configuration space, which has a pretty big overlap with rules.  We did heuristic search, constraint satisfaction, resource allocation and pooling, spatial constraints, containment, and we even did massive rule systems that were super fast.  Intellectually it was a very interesting field because you take really hard problems (in some cases, problems that you could demonstrate were NP Hard problems) and finding “reasonably optimal” solutions in a very finite amount of time.  As I said, intellectually very stimulating.  In other cases, it was coming up with very creative ways to use simple rule-based systems to compute very user-friendly user-interfaces in millisecond time against very large rule bases.  But one thing I learned for sure: thinking about the world as a set of configuration logic or rules is a different way of thinking, and it just isn’t intended for the average Bear.  This is why I don’t see representing “everything as rules” as being a terribly useful way of approaching the world when it comes to involving your organization in the process of business process management or improvement.  I consider myself a reformed rules guy, and now, tongue-in-cheek, I see everything as a process!

Update: On a (somewhat) related note, a somewhat humorous post from Jim Sinur on how rules might have initiated the real-estate meltdown.