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.

Joe McKendrickJoe

More Sybase/Aleri reactions

Responding to a few blog posts about Sybase buying the assets of Aleri:

Bundling/portfolio vs. stand-alone product

John Bates thinks, among other things, that a stand-alone EP engine is not feasible. Paul Vincent thinks that Sybase will bundle an Aleri EP engine with a database purchases.

Other than the “larger company means more resources” argument, vendors with a large product portfolio can bundle many products under one purchase and support contract. Intuition says that this is particularly important for Event Processing because it reduces the cost of an initial implementation.

Now which is a better fit for an Event Processing engine: a database centric portfolio or an event driven architecture centric portfolio? Maybe it depends on the features of the EP engine.

Mark Palmer, CEO of StreamBase, naturally thinks that the Aleri buyout means great things for his company. He has argued that some vendors will get Event Processing wrong because (to paraphrase) they are not as good at innovating. He also dismisses the failures of various EP vendors as natural market evolution.

TIBCO has innovated a pretty popular product in BusinessEvents. But if history is any guide, Mark is right that most big vendors will get Event Processing wrong, at least in the early stages (where we are now). But so will most small vendors…

Colin Clark thinks that were StreamBase to merge with its step-sister company Vertica, it would imply that either StreamBase or both companies were in trouble. His comment is from a venture capital perspective, but I wonder about the product bundling aspects as well.

And finally, Opher Etzion takes his usual “not black and white” stance, providing arguments both for and against stand-alone Event Processing. Worth reading, even without a decisive opinion.

Maybe EP will develop differently, in different vertical markets

Philip Howard categorizes Event Processing products by vertical market, and is not relating the results of one vertical market to the results of the others.

It’s true that some of the most successful vendors stress particular vertical markets. But the lack of consolidation in non-finance vertical markets of Event Processing is more likely a result of when the firms got venture capital .

Reaction to the Sybase/Aleri buyout

My first thought was “why didn’t StreamBase buy them?” Were they not approached? Did Aleri take the deal that preserved the most jobs? Were they outbid?

My gut gives a different reason…

(just being honest here)