Speaking from a vendor that provides various levels of event processing (human, complex-automated, service-oriented), the classification scheme of event-decision-process makes lots of sense.

Of course, we are talking technologies not vendor market areas. So consider a BPM system generating events indicating the completion of activities. These can be complex events (abstracted), and you can view them, make decisions about them, and have a process to resolve problems in them. This is, at least in some sense, “process intelligence”. And if you want, you could also run analytics on that process event-data…

Cheers

I remember discussing with one of the industry’s luminaries not so long ago – and he was joking (well not really) that the best way to make a CEP vendor cringe was to ask ‘what do you think is an event’, and then ask ‘what do you mean by an event happens’. Semantic mud, arms thrown up in the air, red faces.

But more to the point of this exchange, I agree with one core argument pushed by Tim Bass (although I could access his article to know whether I agree with the rest) – and this discussion is a clear illustration; CEP suffers from vendors trying to position it to be everything and anything. It does remind me of the early days of BREs when they all were presented as being able to do anything and everything (yes, I am guilty). Well, not any more: clear distinctions are commonly agreed upon between BRs, BPs, etc. A lot us contributed to that clarification becoming crisper, and the industry is better of thanks to that.
Efforts to refine, rules and process semantics are on the way – I think it’s an excellent idea to think about those semantics in concert, but I am fairly certain that what these efforts will lead to is a common understanding of what the different areas of responsibilities are.

Bear with the opinion of a BRMS-turned-EDM guy.

I would love this to be really really simple, So simple that even I will not want to acknowledge that this is that simple after I write it – but that is what you need to do to simplify: turn it into too simplistic and build from there.

- Events are all around detecting what decision needs to be taken in a complex temporal context (essentially event correlation, converting monitored ‘ambient’ events into relevant business events that require reaction)
- Decisions (and I will use that term instead of rules) are all about deciding what needs to be done as a reaction to those business events
- Processes are all about executing the decision taken
Very simple, very simple.
CEP addresses the first, EDM (with BRMS as the first child) the second, BP the third. Yes, it’s reductive with respect to what the CEP vendors would like (sounds a lot like event correlation as in what used to be done 15 years ago) – but, hey, simplifying always starts with cutting too much to add more later. If need be.
Event Management, Decision Management, Process Management.
The fact that platform vendors are integrating the 3 does not mean they are the same. Or that they should be.

What I just outlined is centered operational aspects – as in the operational / improvement aspects distinction presented by Carole-Ann in her talks about the EDM vision at ORF and BRF.

The improvement aspects cover how to leverage the information gathered by the operational system – as well as expertise – in order to improve the decisions. It starts by gathering the information and understanding it. All aspects above are to be covered: Am I capturing the right events? What if I decided to capture something slightly different: does that make my business events more relevant? Why did I capture this event at that point in time? What other events are captured within a given contextual distance from this one? Ditto for the decisions (the rules). Ditto for the execution (the processes).
Why not just call these things "Event Analytics", "Decision Analytics", "Process Analytics"?
Yes, they are connected. But different.

I know, simplistic. Too simplistic.

But deep down in my simple mind, the logorrhea of acronyms that seems to accompany any discussion on CEP / BPM / BRMS (sorry) is indicative of too much confusion.

When we talk to enterprise application architects – they have much simpler descriptions for what they need than what we give them in return. How many presentations have I seen that end up in the customer asking "so you mean this is just "? We should keep the complexities to us, and present very clear and focused concepts and features to them.

My 2 cents (asymptotically reaching 0 these days).

- Carlos, retreating into his shell.

Good point. If I wasn’t clear, here is a distinction between BAM in a BPM context and PI in the same context – as you said, BAM monitors. PI analyzes. I guess the definitional conundrum occurs when PI approaches real time. But it is still essentially analytical, not a monitor. What happened, why did it happen, what it is related to, what are the causal factors, what should be done? This is where it bleeds into the definition of CEP.

-NR

You may be better served by describing the problem that you have and the proposed solution for that.

For example, BAM in the context of BPM can be construed in different ways.

One way to look at BAM for BPM: I would like to monitor the execution of process steps managed by my BPM application. In this example, you are only monitoring activity inside the BPM tool itself. Many BPM vendors offer this form of business process monitoring, and call it BAM.

Another way to look at BAM for BPM: I would like to monitor KPIs for my overall business process. For example, I would like to make sure that all sales activity initiated this morning before 10am completes by 3pm today. Monitoring this activity may include visibility into the BPM application’s execution, the underlying IT infrastructure supporting that process, external indicators such as weather in the region, etc. If it is 12pm now, I would like to know if any events inside or outside of my BPM platform, related to the sales activity at hand, would impact me meeting my 3pm deadline. A pure-play vendor like Systar considers BAM defined more along these lines, as opposed to the view in the first scenario.

Getting back to my initial point, you may want to consider better defining what and how you want to monitor the business activity, and seek a solution that meets those criteria. Unfortunately for now, the overlap and confusion in industry definitions of BI, BAM, PI, etc. may just perpetuate your disagreements.

I didn’t know there was a Process Intelligence community, perhaps I should join it.

I don’t know why you and John have to make such pointed comments at each other. I think this is pretty simple. CEP doesn’t have the word “intelligence” in it, so I suggest that PI is something like BI, only it is designed to understand process activity somewhat after the fact. If that understanding is moved up to real time, then maybe it is very similar to CEP. They may be converging in effect, but they derive from different disciplines. PI is analytical, CEP is actionable. PI may be actionable, CEP may be analytical.

So why do we have to argue about this?

-NR
twitter nraden

Good qu. Perhaps I was wrong in post 5, based on the sample of 2 responses (yourself and Neil). So if its common in the CEP community, for example, it looks like it isn’t in the Process Intelligence community (and assuming your identity is the same John Patton who commented in one of the Smart Enough Systems blogs, and therefore from the latter community).

[I'll leave the discussion on insults for someone else to comment on, as obviously I'm biased]

“I think your post didn’t receive a response because you are saying “Isn’t Process Intelligence a form of CEP?” which is another way of asking, “What is CEP?””

No, and no. CEP is about abstract events, so if process intelligence abstracts events, should it not be connected with the idea of CEP? And if anyone wants to check out definitions, see http://www.ep-ts.com and its glossary.

“Process Intelligence can be distinguished from BI by some key technology differences (e.g., an object model vs. a data model; an event store vs. relational or OLAP store.) So the comparison is really BI vs. PI. Which was the point of my initial posts all along.”

Interesting: object model, event store… very much is a part of the CEP technology space. Too.

“So I think you overreach by trying to draw PI into the CEP world. But here’s my quick take on CEP. CEP and BRM form EDM. CEP is a distinct technology defined by the simultaneous presence of (1) a pattern language and (2) stream (non-persisted) data.”

OK, so this tells me the “PI community”, if you are representative of that group, has not yet understood CEP. Because you are describing to me event stream processing. But thats OK, because it cancels your implied inference that PI is nothing to do with CEP.

“OK, so against my better judgment I’ve commented on CEP.”

No, its an interesting comment, and no more invalid than my statement on Process Intelligence.

“So while PI, BI, CEP, BRM and are all part of the BPM ecosystem, they are distinct technologies.”

Funny, I see the opposite: processes being implemented as rules, rule management for CEP, etc etc.

“To this note, I don’t really see BAM being a distinct technology. It is simply the dashboarding of data, accomplished in any BI tool. I believe this is why there are very few pure play BAM vendors left. Those that are left, like Systar, are really KPI management applications. BAM was never a distinct technology, only dashboarding for BPM.”

Interesting again, as I see the difference as real-time / event driven dashboards (push model) versus historic views that are not updated (except by a pull model aka refresh).

Finally, thank you for your comments. I don’t agree, but at least we know where you stand on this!

Cheers

First, let me point out that in Post #5 you “apologized” for assuming that your points were common knowledge. Then in Post #13 you proclaim your interest in a response. Why, if it is common knowledge, would you expect a response? (BTW, I believe Tim O’Reilly is the originator of the “common knowledge” form of blog insult.)

Second, putting aside the implied insult, I think your post didn’t receive a response because you are saying “Isn’t Process Intelligence a form of CEP?” which is another way of asking, “What is CEP?” Process Intelligence can be distinguished from BI by some key technology differences (e.g., an object model vs. a data model; an event store vs. relational or OLAP store.) So the comparison is really BI vs. PI. Which was the point of my initial posts all along.

So I think you overreach by trying to draw PI into the CEP world. But here’s my quick take on CEP. CEP and BRM form EDM. CEP is a distinct technology defined by the simultaneous presence of (1) a pattern language and (2) stream (non-persisted) data.

OK, so against my better judgment I’ve commented on CEP.

So while PI, BI, CEP, BRM and are all part of the BPM ecosystem, they are distinct technologies.

To this note, I don’t really see BAM being a distinct technology. It is simply the dashboarding of data, accomplished in any BI tool. I believe this is why there are very few pure play BAM vendors left. Those that are left, like Systar, are really KPI management applications. BAM was never a distinct technology, only dashboarding for BPM.