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.

Lately there’s been a bit of a buzz about CRM.  Not sure what caused it, but here are three thoughtful articles on the subject:

1. Derek Miers’ post on Case Management revival
2. Bruce Silver’s commentary regarding a new OMG spec RFP for Case Management.
3. Paul Vincent’s blog for Tibco, where he mentions PRR and DMN… and Case Management yet again…

I’m still waiting to see a really good case being made that Case Management requires or lends itself to different technical solutions than, say, BPM.  Having said that, I’m also sensitive to the fact that as BPM was picking up steam, many in the SOA stack community wondered why BPM wasn’t just a “feature” of SOA.  The fact that I don’t yet have the information to prove to myself that Case Management has technical requirements not addressed by BPM, does not mean that such information won’t be forthcoming.

Update: Bruce Silver has another update – apparently there was a bit of controversy about the case management proposal at OMG recently, and a little bit of blogosphere dust-up resulted.