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.