Saturday, April 28, 2012

Event Distribution and Event Processing

I have recently been involved in several discussions (sales opportunities perhaps), where the answer seems to be, "We need a CEP engine". Of course if one chooses solutions based on products there's something wrong. And then working with the sales force, I hear, "Customer X wants to buy our CEP engine, you know something about the industry, what use cases should we propose?" When I delicately suggest that nothing they have said so far qualifies a CEP need, and that the problem is bigger (based on industry knowledge), and that it will require more than the CEP engine, I get the message, "That will drive the price up too much, and anyway we have told them that the CEP engine is the way to go, so we can't change..." So why ask me?

But that isn't the whole point of this post.

There are things that CEP engines are *really* good at. However, distributing events isn't necessarily one of them. Now when it comes to interpreting the events in relationship to each other in a tight time window - now we are talking. When it comes to creating events out of that interpretation, we again have good cases. But that isn't distribution either - that's just notification.

But the nagging question is there. "How does the CEP engine (or indeed any other kind of event processor) get to hear about the events it is monitoring?"

A way of looking at that is in terms of the Event Distribution Network. Now that is serious architecture and infrastructure. Not to speak of some mental gymnastics on behalf of both the business and technology communities.

Conceptually, events are easy things. "Something happened". Of greater trouble is making sure that the knowledge that "something happened" gets to the right place.

The right place might be a CEP engine - we want to see the implications of what happened with a whole bunch of other things that happened. Oh, and do it in Near Real Time (NRT) (Whatever that means!).

But another place might be at the next stage of a business process. "The customer paid their bill, let's ship the goods". In other words thge event as the trigger with a process call-to-action. These aren't exclusive alternatives.

Of course there can be many things that need to know about the same event.
So just because you see a customer need that says "event" and you have a product that has the word "event" in its description, don't make the mistake of assuming that one matches the other.

It's as absurd as the trouble compilers have with English in examples like this. "Fruit flies like a banana". "Time flies like an arrow"