A Bit of History on CEP and ESP Marketing


 
Thread Tools Search this Thread
Special Forums News, Links, Events and Announcements Complex Event Processing RSS News A Bit of History on CEP and ESP Marketing
# 1  
Old 11-25-2008
A Bit of History on CEP and ESP Marketing

Tim Bass
11-16-2008 12:01 AM
In his Followup to “Do you need a Commercial CEP System?” Marc calls out Progress Apama and their great work in financial services.* I have always liked Apama’s product and what they are doing; however, we should be clear on the difference between marketing and technology.

Progress Apama was the company who, when the buzzword “CEP” burst on the scene, believed that the term “CEP” was not appropriate for these new classes of real-time event stream processing platforms.* Progress’ leadership, including Apama, worked very hard to reposition “Complex Event Processing” as “Event Stream Processing”.* I have always believed that Progress Apama, a company which prides itself in being run by engineers not marketeers, was correct, from a technical perspective, to call their platform “ESP”.* In fact, Apama still positions as ESP today, which makes me proud of them.

Then, the marketeers saw that, contrary to their marketing predictions, “CEP” was gaining traction, and they worked hard to reposition, yet again, and “ESP”* became “CEP” (again).** Some of the trouble with all this marketing spin and repositioning, is that it actually hurts good companies (like Apama, a company that prides itself on technical engineering excellence) because they become buzzword-driven, not technology driven.* It also is not good for the end users.

Marc goes further to say;
When I hear people at my firm talk about Apama, they talk about it as if it were its own class of applications, much in the way people refer to Ketchup now instead of Catsup. They don’t even know that Apama is related to CEP.

Precisely. Bravo!

That is because Apama (and other companies) make great products, but these forward-chaining, event stream processing engines are not processing complex events per se, they are processing events which are, by the most part, not complex, technically speaking.* Progress and the Apama leadership had it right when they fought tooth-and-nail to reposition this software as ESP engines.

The reason they “flip flopped” and repositioned, yet again, to the “CEP buzzword,” was based purely on marketing.* It has very little, if anything, to do with solving complex detection-oriented problems.

Now, regarding Marc’s question to me in his Followup to “Do you need a Commercial CEP System? …
However, there are many CEP applications in other industries, like gaming, transportation, and defense. All of them share the same characteristics. Monitor a bunch of real-time actions and warn when a certain condition is true. So, a generic surveillance block would be great. The surveillance block might come with a choice of adapters for the most popular sensors . (Tim Bass can tell me if I have been smoking crack here.)

Marc, you are right, in the general sense, but we cannot do all of these wonderful things you are talking about if all the “modules” are simply built upon forward chaining stream processors across a sliding time window!* Before we talk about the “intelligence” needed in these “expert modules” we need to move beyond the constrained thinking of the narrow world view of continuous query engines that can only do forward chaining.

We need CEP, not just ESP, and the products on the market are mostly just ESP engines.

TIBCO’s BE, for example, which is more complex than a simpler stream processor, is a forward chaining RETE implementation.** You cannot possibly tackle all the critical classes of complex problems that need to be addressed in defense, compliance, surveillance, detection and more if your modules can only forward chain and cannot backwards chain.

The analogy is quite simple.* If you have a set of alphabet building blocks and all the blocks are every other letter, you cannot spell very well.* The same is true with forward chaining rules engines.** Forward chaining rules engines are great, but CEP needs more than this, much more (neural nets, Bayes nets, backwards chaining rules, for example).

In other words, as I have often blogged, we are taking a set of technologies, with all their issues and constraints, and wrongly calling them CEP.* Why buy into the pure marketing hype based on the limitations of the software not the technical requirements of the customer’s real (and complex) problems?



Source...
Login or Register to Ask a Question

Previous Thread | Next Thread
Login or Register to Ask a Question