IBM Says Business Event Processing is Not CEP

Sandy Carter, IBM’s vice president of SOA and WebSphere strategies, said something in IBM Buys AptSoft To Boost BPM-SOA Line I completely agree with, relative to most of the technologies folks are calling “CEP” these days:

“In the marketplace today, everybody talks about complex event processing,” Carter said. “We actually are trying to rename that category, because we believe the real value is in business event processing, with a focus on the business.”

For example, none of the current CEP vendors are doing “complex event processing” as many of us have said, repeatedly.

TIBCO and AptSoft, for example, are examples of companies that are really implementing, business event processing. You can easily confirm this in TIBCO’s press release, TIBCO BusinessEvents 2.2 now shipping…, where Paul Vincent blogs:

The main change with this [TIBCO BusinessEvents 2.2] release is the inclusion of new deployment options:

+ deploy BusinessEvents within a BusinessWorks container: great for using BusinessEvents as a decision engine for SOA integration processes, choreography, transaction flow monitoring, etc, or for using BusinessWorks as a ruleflow tool.

+ deploy BusinessEvents as a BusinessWorks container: great for exploiting SOA orchestration and services under the control of CEP, such as invoking complex adapters.

This is absolutely, “business event processing” just as IBM’s Sandy Carter stated, correctly in my opinion, not CEP.

The same is true for event stream processing (ESP). ESP technology from companies like Apama, Coral8 and StreamBase, is much more closely aligned with the “business event processing” than anything that is truly CEP.

12 Responses to IBM Says Business Event Processing is Not CEP

  1. Opher Etzion says:

    Hi Tim. The reason for IBM marketing use the name “Business Event Processing” instead of “Complex Event Processing” since they don’t like the word “complex” – the same reason that Progress invented another term — to avoid the term “complex”. I am not sure that CEP is a good name , but I think that the name has caught in the industry, and I am not sure that this can be changed – internally in IBM, the term CEP is also used all over.



  2. Tim Bass says:

    Hi Opher,

    Marketing is definately part of the problem, from the begining.

    I agree 🙂

    My issues and concerns are more related to the difference between orchestration and detection.

    I don’t think we will ever fully agree, because you are more closely aligned with marketing and analysts opinions than I am.; and I am more closely aligned with solving real-time, complex detection-oriented problems than marketeers and analysts with opinions.


  3. Paul Vincent says:

    For sure, business event processing overlaps with complex event processing. I’m not sure there is much interest in non-business complex event processing though!

  4. Tim Bass says:

    Hi Paul,

    A concensus is unlikely since the field is dominated by companies trying to sell products and out position each other in a relatively small market.

    Yes, there is overlap between BEP and CEP; however, a statement like “I’m not sure there is much interest in non-business complex event processing though! adds to the “two second sound bite” category, to be frank.

    We are talking about the difference between process orchestration and complex situation detection, the first closely aligned with BEP and the second being closely aligned with CEP.

    TIBCO has been focused on BEP because, you can’t do complex situation detection with just a rules-engine (period). That’s really OK. Event-driven process orchestration is very cool and very important.

    Yours sincerely, Tim

  5. Paul Vincent says:

    Hi Tim, I’m pretty sure all vendors agree that simple event orchestration (like TIBCO BusinessWorks) is not CEP. And that as CEP is a superset of simple EP, you can do simple EP in a CEP tool.

    But “you can’t do complex situation detection with just a rules-engine” must depend on ones definition of “complex” and “rules-engine”. I guess we should defer that to the EPTS Use Cases discussion.

    PS: I should have pointed out that the previous CEP functionality remains in BusinessEvents – we’ve just added more options! So the same complex situations you can detect in BE2.1 you can still detect in BE2.2. Sorry for the confusion.

    PPS: TIBCO’s Event-driven process orchestration tool is called iProcess Conductor, and layers BusinessEvents CEP on top of iProcess BPM. Mostly used in the telco market for provisioning.


  6. Tim Bass says:

    Hi Paul,

    As the old saying goes, “when you only have a hammer, everything looks like a nail.”

    Because software companies have only built hammers, of course the use cases look like hammers solving problems with nails.

    In other words, the EPTS use cases will not resolve this issue, they only reinforce the “hammering the nail” metaphor.

    It is a bit like asking the “flat world society” to comment on the future of a round world.

    I am sorry to disagree with you, but the use cases from the EPTS will only illustrate how to hammer nails with hammers, not what is the true value of complex event processing.

    Yours sincerely, Tim

  7. Opher Etzion says:

    Hi Tim. The EPTS use-cases WG that started working (and will issue its findings around mid 2008) is intended to check the “state of the practice”, which does not say what can be done in the future, but what has been done until now. Of course, this may not represent the full potential of event processing , since IMHO we have just scratched the surface, however it will provide a snapshot in 2008 of what the state of the practice is.



  8. Tim Bass says:

    Hi Opher,

    Candidly speaking, I do not agree that EPTS will provide the “state-of-the-practice” in event processing, as you reply.

    The reason I am of this opinion is that there are many companies doing very interesting things in event processing that are not a part of the EPTS or marketing as CEP companies. In fact, some of the companies I could reference are generating considerably more event processing related revenue that many current EPTS members and flagship (steering) companies.

    In my opinion, EPTS needs to be more inclusive and have strong representation from the myriad companies who are doing real event processing every day. However, many do not yet see any tangible value from spending marketing resources calling themselves “CEP” or “event processing engines” — because they already have considerable EP revenue or are simply too busy for committees. The companies benefiting the most from the “buzz” are companies trying to build market share with their software products.

    There are so many interesting applications of event processing in the business world, and many software companies leading EPTS represent only a fraction of the current “soft” event processing market.

    So, I think EPTS should rapidly evolve to be much more inclusive, including embracing the myriad companies already in the event processing space focused on domain specific applications. EPTS is missing out on many interesting CEP/EP use cases that are not from companies marketing themselves an “event processing middleware” but instead, using event processing to solve domain specific problem, with or without “infrastructure EP engines”.

    I have given considerable thought to this, BTW; and I think you have done a good job getting EPTS started. It is time, however, to become more inclusive and make the focus on these “CEP engine companies” less dominate; and bring forward the solutions companies actually solving CEP-types of problems; and these companes are not currently marketing themselves as CEP or EP companies – they are simply solving CEP classes of problems without the hype.

    Alternatively, EPTS can continue as a vehicle for software companies to build market together for their software. – but this will not capture the true use cases and state-of-the-practice in event processing (by a long shot).

    Yours sincerely, Tim

  9. Changhai Ke says:

    Hi Tim,

    I agree that CEP should stay CEP, and BEP is another thing.

    CEP suggests me a sophisticated algorithm designed to process efficiently, in real-time, numerous incoming events. Most of them are low-level and technical (sensors, alarms, etc). CEP is designed to be highly reactive, correlative, memory cautious and voluntarily stateless. If an event is not of interest, it is just good to ignore it to save space.

    Business events are synthesized from the technical events (using CEP). Those events are the target for any event middleware, BAM tools, etc. They have their importance at business level (PKIs, metrics) and business people should know what they are. Here, it does not appear that algorithm is the main issue; it is more a question of middleware and architecture. Business events are often logged.

    CEP should stay CEP. It vehicles some kind of algorithmic challenges, and not any kind of publish-subscribe pattern, with loosely coupled components. It will be disappointing to remove those challenges from the name. BTW, EP itself won’t be very meaningful; it is too general to suggest any underlying technology.

    About the rule engines, I think you meant “production rule engines”, and more specifically the stateful rule engines? In its general meaning, a rule engine is an engine executing some rules (written in some language), and why not also to perform CEP.


    Changhai Ke

  10. Opher Etzion says:

    A comment on EPTS – there will be soon a call for membership for all the community (vendors as well as individual persons) , as we formalize it. The current steering committee is to jump-start it, and in the future steering committees will be elected by the members.



  11. […] the IBM folks who are calling these first generation “CEP orchestration engines” BEP engines, because that view is closer to fact than fiction.  Frankly speaking again, process […]

  12. Yoram Kochol says:

    BEP is different then CEP.

    Business events are a part of an over all application software architecture addressing BPM/SOA/EDA. A product has a lifecycle built out of business events which are generated by services as part of a business process. The business events are emitted on the esb to an event processing engine on the enterprise level which provides for integration, business activity and business intelligence. Business analysts and business users can configure the event processing engine to fit business requirements. All this can happen without a CEP engine.

    CEP is an additional layer on top extending the above functionality.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: