Paul Vincent on BPMN 2 events (all 63 types of them) :

OK, “63 types of event” needs a bit of explanation (and justification). These consist of:

• 13 main event types: untyped, message, timer, escalation, conditional, link, error, cancel, compensation, signal, multiple, parallel multiple, and terminate
• … across 8 situations classified by location in a process:
• Start: top-level, event sub-process interrupting, and event sub-process non-interrupting
• Intermediate: catching, boundary interrupting, boundary non-interrupting, and throwing
• End

… but with some situations not requiring certain types of event (e.g. there is no “start cancel process” event) leaving58 63 event types defined [*1].Presumably BPMN tools will let the user specifiy the main event type and associate the correct symbol from the context in most cases, leaving us to consider just the 13 main event types.

Paul is right: 63 is too many. But I think he also hints at the right answer: the tooling should be able to pick the right symbol based on the context of the detail of the event (or conversely, show the author the right context if they pick a specific event).  But there’s no reason for anyone to know 63 event types off the top of their head.  In fact, they really don’t need to distinguish between all of the 13 “main” event types in most cases.

It is up to the BPMS providers to make the authoring experience powerful and yet simple enough to be manageable and useful.  If the notation has gotten away from us a bit, then software can help reduce it back down to something manageable.  One interesting aspect is that many of these event types are not currently supported by BPMS vendors-  so depending on which tool you’re using you can cross off a lot of the potential event types!  That isn’t exactly what I mean by “simplifying” but it is one way to get there, I suppose.

I think Paul Vincent’s blog on CEP is where it’s at – my favorite place to keep tabs on this interesting space.  It isn’t BPM, but it is related to BPM, and vice versa.  Not only are the markets complementary, sometimes the concepts in one space directly make sense in the other.  A side note: often when having trouble designing a process, I think about the important business (or even system) events that might occur – I may not know the actions that happen inbetween, but the events become useful markers around which to design a process.

A recent post from Paul caught my attention: “Do Events Have Duration“.

This might seem an odd question, but there are 2 schools of thought here:

• An event is a point in time.
• An event is an activity that can take a period of time.

Taking the latter view, we can say things like:

Earthquake MMM took place from date-time D1 to date-time D2
Fraudulant act on account NNN took place from date-time D3 to date-time D4
Flight QQ123 was delayed in the period date-time D3 to date-time D4, when it completed disembarkation time T1 late
World War 2, an historical event, took place from 1 September 1939 to 2 September 1945.

Lest this make your head hurt, Paul makes a compelling argument that events should be considered moments in time, and an “event” like World War II is really more of a “state” of being in World War II with a start and an end and many other events in between.

I think the principle of Occam’s razor applies here: the simplest explanation is usually best.

Another side note: my favorite comment on his blog post is one that almost sounds like a snippet from a Star Trek script: “…’temporal semantics of event processing’. In short — events always have durations, but in many cases, the time granularity that we are interested in a certain application is large enough so that we can approximate the duration to a time point (note that a ‘second’ is also an interval and not a point, since time is not discrete).”  I was waiting for something about reconfiguring the deflector shield…

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.