BPM and EP
I just read a post from Joe McKendrick at ZDNet, titled Why business process management and complex event processing are converging, which reports on a webinar about Business Process Management (BPM) and its relationship with Complex Event Processing (CEP). The lead quote is: The BPM and CEP combination means ‘process monitoring on steroids’
This is exactly the kind of thing that lead me to describe two types of Event Processing: Detection Oriented vs. Operations Oriented. I see this pattern over and over in pretty much every use of Event Processing (EP) that I have worked with.
Operation Oriented EP handles events that follow a pre-defined business contract. The goal is to trigger business-level action, based on the known business contracts of the incoming events.
Event driven BPM is a major type of Operations Oriented EP. BPM handles events with defined business meaning and triggers business level action based on them. That’s not an attempt to subsume BMP into EP. Rather, I point out that BPM can use EP in the same way that it can use a database, while remaining an independent class of software.
Detection Oriented EP handles events that follow patterns outside of the main business use; the business meaning must be distilled from the events, it is not captured by the business definition of the events themselves. The goal of this type of application is to create new types of business-level events based on those detected patterns.
But remember that an event can have a business meaning to a BPM system, but also be a part of patterns that lie outside of those clear business contracts. So Detection Oriented EP often works over the same events as Operations Oriented EP, but it uses them in a different way. The upcoming book Event Processing in Action describes this powerful property of events: they can be used simultaneously by different applications in very different ways.
The blog post mentioned above describes a system that monitors the BPM looking for various patterns that fall outside of the normal business contracts. I would call that Detection Oriented Event Processing. This kind of application watches the same events that drive BPM. But it’s looking for patterns that lie outside of the business meaning used by the BPM aspect. These patterns then produce new events with defined business meaning, which can feed back into the BPM.
What is the point of breaking Event Processing into the categories of Detection vs. Operations Oriented? It highlights the fact that event driven BPM shares many aspects with other Event Processing applications – because they all process events. But also, BPM belongs to a class 0f EP that differs significantly from the Detection Oriented class.
I prefer the Detection vs. Operations Oriented classification to terms like Complex Event Processing. Why? Take a look at the Wikipedia article on CEP. I read this article and I can’t tell the difference between CEP and event-driven BPM. CEP seems to encompass every business application that processes events (basically everything outside of a message bus).
Yet there are clearly differences between BPM and the type of CEP that Mr. McKendrick reports in his post. So I prefer a hierarchical definition, where Event Processing applies to all of these applications. But then we drill down into specific categories of EP.
Hi Hans – interesting thought. But…
Surely the detection of some business state through events (eg an exception) is used to drive some process or action? The latter may or may not be automated, of course – but that is true for edBPM etc too.
Cheers
Hi Paul –
I was trying to distinguish two use cases for event processing:
One use case works with events having (hopefully) well defined business contracts. Although the contracts may be complex and the logic may be a challenge to manage, it results from well defined business contracts. An example of this use case is event driven BPM.
The other use case develops from patterns that are external to the usual business contracts. In this case, there are things happening that are not exactly specified by the BPM contracts – this is the event monitoring.
My own experience is that these two use cases are quite different from a practical implementation and usage standpoint – even though they may seem to be the same because “they both process events.”
I have also noticed these two types of use case in many event-driven projects that I’ve seen or participated in.
It’s not an unreasonable distinction. What you call an operational event is the instantiation of a state transition pattern, such as the arrival of a data unit in a protocol, or a new lexical unit read in parsing. What you call a detection event is a new data point that might alter a prior expectation. Operational events are routed, detection events are scored. Nothing precludes independent (passive IDS) or dependent (search) routing and scoring. A better algorithm likely blends routing and scoring (and probably limits the set of people who can evaluate it to Phd quants).