In the names of CEP and BPM

Have you heard the one about how to drive BPM people crazy? 

Ask them the question that drives CEP people crazy!

Last fall, at the RuleML conference in Orlando, was the first time I heard a consensus that a standard ontology of events and processes was sorely needed.  I’ve had a number of discussions with others on this over the interim until today’s posts by Paul Vincent, summing up an OMG meeting in Washington, DC, and Sandy Kelmsley’s comments on a survey of 590 business process modeling notation users.  

1. Apparently, the broader OMG feels the same need for “event semantics” we discussed in Florida.
2. In addition, BPMN users indicate that too many event types complicate process modeling.
3. Finally, Bruce Silver dives a little deeper in two recent posts, one which responds to the authors of the BPMN survey and the other discussing whether BPMN will actually become portable, among other things, including events.

For me, the Great BPMN Debate boils down to two things:

1. Whether BPMN has too many features
2. That BPMN is missing semantics

I like BPMN.  I wound not want to sacrifice much.  But as a customer, I would think interchange is critical.  Regrettably, Mr. Silver points out some problems serializing to XPDL and other issues with vendor coverage.  We are a ways from effective standards for rules or BPM, it appears.  By effective, I mean standards supported by vendors that actually facilitate interchange between vendors.

1. XPDL may not be enough for BPM.
2. Rule vendors at the Business Rules Forum openly agreed that PRR is too low level for effective interchange given all their value-added (which I do not question)
3. RIF will be much better than PRR but it will still not facilitate effective interchange between BRMS vendors
4. SBVR has little traction and no effective implementation (yet)

One problem with all these standards, and even the web ontology language (OWL), is that they lack a common ontology.  That is, they are syntax lacking shared semantics.  Until they share some semantics, integrating or interchanging between them will remain imprecise , unproductive, and overly technical.  Everything but technical rules and models (e.g., vocabulary) will remain locked in.

BPMN is overwhelmed by events

Just reading Mr. Silvers post, you find start and end events, throwing and catching events, intermediate events, exclusive events, timer, message, error and terminate events.  And there are more.  Too many, BPMN users agree, according to the survey cited above.

How many different kinds of events are there (or should there be)?  For now, I’m going with 2.

What is an event?

Ask any complex event processing (CEP) vendor!  It will drive them crazy or you will get a long-winded answer. Or, like me, they might say that it is something that happens or occurs.

At first, most people think of events as occurring at a point in time.  After some discussion, however, most people agree that events are things that we view as occurring instantaneously, even if they take a day, such as last year’s 4^th of July picnic, which we might also call an occasion.  Events, like the lights going on or a starting gun firing, might indeed be effectively instantaneous, in which case we would not call them occasions.

There is more to the difference between occasions and instantaneous events, however.

What occurs or happens?

Is an event an occurrence or something that occurs?  The difference is  similar to the difference between days, such as Friday versus March 14, 2008.  One is what BPMN would call an event type and the other is an event.  Well, not exactly, I doubt BPM folks would be happy thinking of a day as an event.  Perhaps they would prefer that the start or end of each Friday was a type of an event and that the start of this Friday (i.e., today) was a specific instance of the “start of a Friday” event type.

For those who read about understanding time, the difference between event types and events is similar to the difference between specific and recurring times.  The semantics of introducing different types for starting and ending events is troublesome, however.  Especially if how they are different is not specified semantically.

Generally, for all X, I do not like X “types”. When we talk with friends other than colleagues, using the word “type” confuses them.  When talking to non-technical folks, instead of saying “event types”, why not just say “events”?  Come to think about it, why don’t we talk about process types?  (I’m sure someone thinks BPMN needs them!)

When is a process not an event?

Most people would agree that things happen.  Most people would also agree that events happen.  The word “occur” is interchangeable with “happen” here.  Do you agree that processes, like events, also occur or happen?

If specific instances of events are occurrences of “event types”, what is a specific instance of a process?

If celebrating the 4^th of July is a process and last year’s 4^th of July picnic was an event, could an instance of a process be an event?  Or, is every instance of an event type an occurrence of a process?

Yes and No.  Yes, but, for all X, I do not like X “instances”, for the same reason that I do not like X “types”.  In other words, yes, occurrences of processes can be viewed as events.

But no, some events are not processes.  For example, the start of a process can be viewed as an event, as BPMN views it, but the start of a process is not necessarily a process in and of itself.  We could recurse into philosophy on this one, I guess, but at some level, the beginning of an explosion stops being interesting from a process perspective.

Avoiding philosophy as much as possible while remaining semantic:

1. Occurrences of processes “are” (can be viewed as) events.
2. Events occur instantaneously or over an interval of time.
   • That is, events occur at a point in time or they have a duration.
   • In other words, an event is either instantaneous or durative.
3. Durative events are occurrences of processes.
4. Instantaneous events occur at the beginning or end of processes.

Ontologically, a process is disjoint from an instantaneous event but both are events.

Getting this right is important, not only for helping CEP cross the chasm, but also for integrating BPMS with BRMS.  Whether or not they agree with me, OMG and others need to answer the question:

Are processes and event different and, if so, how?