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.
- Apparently, the broader OMG feels the same need for “event semantics” we discussed in Florida.
- In addition, BPMN users indicate that too many event types complicate process modeling.
- 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:
- Whether BPMN has too many features
- 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.
- XPDL may not be enough for BPM.
- 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)
- RIF will be much better than PRR but it will still not facilitate effective interchange between BRMS vendors
- 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 4th 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 4th of July is a process and last year’s 4th 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:
- Occurrences of processes “are” (can be viewed as) events.
- 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.
- Durative events are occurrences of processes.
- 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?
Thanks Paul, interesting question.
A similar topic was discussed in the Business Architecture working group at OMG last week. One of the speakers presented:
Business Entity = data entity + data model + lifecycle state model
Business Process Model = set of communicating business entities
Business Service = state transition in business entity in its lifecycle
Normally, of course,
Event = observation of state or state change
So Event and Process are certainly related…
IMHO, the best definition of Events and States had been done in the beautiful book by Sally Shlaer and Stephen Mellor “Object Life Cycles: Modeling the World In States”. (I still don’t understand why CEP vendors do not use their methodology – at least I could not find direct references to it). I do not agree with your statement that processes can be viewed as events – not in the same “system of coordinates” at least. Events are atomic (and constant) by nature and processes are stateful. You can not have both in the same model. So, 4th of July picnic is not an Event(I feel that English semantic of “school event” got mixed up;), but invitation to the picnic could be. I would rather categorize Picnic as an Activity (i.e something that has start and finish, can be interrupted, postponed or even canceled, may have observers etc.). So, in “my ontology”, events do not occur – they are notifications about something that occurred – more or less like in Paul Vincent’s post. And, on a side note, “a point in time” only makes sense if we use the same timer for all events, otherwise relying on this attribute may cause problems. Shlaer-Mellor methodology requires only that events from the same source were delivered in the order they were created, but makes no assumptions about events from different sources.
Interesting “system of coordinates” comment, but it seems stronger with respect to your point in time comments. That we can understand each other implies that we share some ontology which defines an event and a point in time. We may have different word senses or refinements, but it is the commonalities that are critical.
Perhaps your “atomic” is my “instantaneous” and your “activity” is an event with a duration (i.e., another way of refering to a process). Last 4th of July’s picnic cannot be interrupted, but few events actually have zero duration and there are processes that cannot (reasonably) be interrupted. Isn’t thinking about events as notifications an implementation rather than a semantic perspective?
On the points in time, you are more consistent and complete with respect to relativity, but natural man would not care. BTW, I did not say that the GMT for a point it time was necessarily specified, only that it existed. Adding something beyond timezones, such as frames of reference, has merit in physics or the distant future, perhaps.
I hope others feel motivated to comment on this. It is clearly a critical need in multiple areas spanning the semantic web, CEP, BPM, … But we have to be careful to tolerate ambiguity and, therefore, focus on generality, without introducing jargon. If we make “event” an overly precise concept, we will never reach concensus and non-scientists will remain alienated and unengaged with our work. Rather than narrow the definition of an event, why not use adjectives (or other words) to be more precise when needed?
Paul,
Thanks for your reply,
To clarify, my “atomic(and constant)” rather meant “immutable”. “Instantaneous” is probably a logical consequence of immutability.
That’s the problem with semantics – if even so called “experts” can not agree on the meaning of the word – then there is a trouble. For example, I do not see the need of having “event with a duration” instead of “activity”, is it just a matter of taste?
I understand, that we need to tolerate ambiguity on business vocabulary level, but on underlying semantic level there should be a clear separation. And coming from Shlaer-Mellor perspective (at least from my understanding of it) events ARE notifications,
I would also add that Events are the major source of process state change.
I don’t know is it implementation specific or not, but the best way to settle this is to analyze several use cases and see if there is other semantic to Event, if Activity is made disjoint from Event.
Too broad definition can be confusing, we can say that “key pressed” is an Event and Business Rules Forum 2007 was an Yearly Event – but do they really have a lot in common?
I understand your assertion that few events “actually have zero duration”, but this is only true if we accept the broader definition of Event, otherwise we do not have to associate duration with Event at all.
Point in time is a slippery concept, for example you receive two notifications about two events 8-)) that were generated on two different computers and the first one has a timestamp that is 2 sec earlier than the second one.
Can you reliably state that the first event occured earlier? I’d say – no, and this is an intrinsic property of any Event pair form different sources in a real-world application.
Will the fact that you received the former after the latter affect the conclusion? I say – no, there could be network(delivery) delay, etc. To keep the interaction consistent,
we have to rely only on the “right” order of events from the single source (which is also takes an effort to guarantee).
For example, if we had this discussion over email, and the system would not deliver emails from me in the order they were written, it would have much less sense, then it (hopefully) does now
You are more than welcome. My appeal is to avoid deep philosophy and focus on common sense and consensus. If the common person does not agree with our definition of event, we are stuck. We need a definition of event that is simple, not exact. A generality. But true. If we cannot say “yes” to “do events happen?”, we are lost.