Peter Lankford, Founder & Director of STAC, on CEP, ESP and EPP
The following is a reprint of Peter Lankford, Founder & Director of STAC comment on CEP, ESP and EPP. This is one of the best comments on CEP, ESP and EPP I have read.
Peter Lankford
Founder & Director, STAC
I’ve read the blog for some time and have been meaning to contribute some thoughts on vocabulary. By way of introduction, I look after the Securities Technology Analysis Center (STAC), an independent test lab that analyzes technology used in the capital markets. STAC facilitates the STAC Benchmark Council, a group of trading firms and technology vendors who have come together to define standard ways of measuring the performance of technologies used in securities trading (see http://www.STACresearch.com/council).
So-called “CEP” is a category of technology that seems to be picking up real momentum on Wall Street (not as a panacea for credit crises, by the way) and there is a working group within the Council focused specifically on event processing. The Council includes many of the vendors who often identify themselves as supplying “CEP” solutions, including (in alphabetical order) Aleri, BEA/Oracle, Coral8, Encirq, KX Systems, Progress Apama, and Streambase. The event-processing working group is currently working on specifications for benchmarking these products in an apples-to-apples way that replaces hype with insight.
Throughout this process, STAC has resisted using the CEP moniker for these products because we don’t believe it captures the essence of their value proposition. Neither the events nor the processing are complex in many (most?) of the real-world deployments. Nor do we like “Event Stream Processing” (ESP). Systems that process event streams (both packaged application software and custom-built solutions) have been around as long as the streams themselves, so “ESP” doesn’t capture what’s new. STAC believes that what distinguishes these new products from their predecessors is that they are open containers in which customers can plug their own business logic to process event-driven data. That is, they are platforms. We therefore prefer the term “Event Processing Platform” (EPP). This term applies irrespective of the complexity or simplicity of the use to which a given product is put.
This doesn’t directly address your desire to have an un-hijacked term for a particular class of use cases. However, I do think it handles half the problem, which is naming this new product category. For what it’s worth, the vendors on the working group seem to have readily taken to the term. Perhaps if they start using “EPP” instead of “CEP”, it will free up the latter term for your intended use? Or perhaps “CEP” is so damaged that we do indeed need a new term for the processing of complex events. Either way, “EPP” seems to be clarifying things, at least in our experience.
Thanks,
Peter Lankford
Founder & Director, STAC
See also: Event Processing Platforms (EPP)
Filed under: CEP News and Events, CEP Terminology, CEP Tutorials, Complex Event Processing, Cyber-Trading Technologies, Financial Services
I am glad that others have reached the term “event processing platform” that I am already using, however it should be used for the right purpose - read my posting entitled : event processing platfrom — yes, but..
http://epthinking.blogspot.com/2009/02/event-processing-platform-epp-yes-but.html
Hi Opher,
Thanks for stopping by. Good post on EPP. However, please don’t try to be “the inventor” of the term. As I learned from top USAF leaders many years ago…
“there is no limit to what you can accomplish when you give the credit to others”
Trying to claim “you are the first to use EPP” is “not helpful” to the cause of event processing. It is the “I invented it” attitude that causes most of the problems, so please drop that perspective. Thanks.
I agree that it will be difficult to get the software vendors in the market today to use the term EPP v. CEP, but we need to do it.
Calling EPPs CEP is (1) bad for the industry (2) bad for the state of the art of complex event processing and (3) a joke among experts in the field with many years experience solving complex event processing classes of problems.
Routing, filtering, scheduling, etc. are all wonderful EPP applications, and the sooner software companies in the so-called “CEP market” today follow STACs lead and start using the term EPP to describe their software, the better for everyone.
Yours faithfully, Tim
Hi Tim. I never claimed to invent any TLA, actually my favorite term is “active systems”, but it did not accumulate traction. While I am not a big fan of the CEP term, I still fail to see why it is so important that the name CEP will be used for the classes of applications that you like instead of how it is used today — If you care about advancing your favorite applications — which as I understand are event processing applications using stochastic methods to discover unknown event patterns in off-line or on-line (hope I got it rigt),
If I were you, I would chose another name — since the name CEP will always be overloaded. As I am not a very good copyrighter I’ll leave the name to you or others
I think it will be more useful to all if instead of insisting to use a label that will always be overloaded, just chose another name, and focus your energy on positive postings that will continue the good work of educating us through your Blog about these types of applications,
stay well,
Opher
Hello Opher!
Great to hear from you. Sorry, but I find it necessary to correct you on a number of points.
First of all, in your blog post, you said:
“… EPP ….so I should have copyrighted this name…”
This implies strongly that you feel you invented this term, because you said, directly, you believe your had some claim to copyright in the past. So, I was correct in my post that you were claiming you invented the term. You will notice that neither in my posts, nor in STACs post, are we claiming any rights past or present.
Editoral Note: Streambase has repeatedly tried to claim copyright to the term “event processing platform” and you can see many instances where they have placed the (TM) symbol after this phrase. This is another reason to view Streambase with caution.
Second, I completely reject your continued attempt to paint what I consider “facts” and “truth” as “negative thinking”. Frankly, I find your attempt to paint my thinking as “negative” out-of-line and am asking you now to stop. Thanks!
My view is that you and others (who) are using the term “CEP” incorrectly and this this view on my part is not “negative”. In my mind, it is simply a technical fact. If you want to debate the technical merits of complexity in detecting threats or opportunties in real-time, then please do so, but do not paint an opposing view as “negative” just because you don’t like the argument.
Counter arguments along these lines, metaphorically speaking, are like calling folks who argued against the “flat world theory” as being “negative”. It does not matter which side of the argument you place yourself, “flat world” or “round world” or “simple event processing” or “complex event processing” ; you should cease-and-desist attempting to paint an opposite or different opinion as “negative.”
Third, I also reject (as I have in the past) your suggestion to create another name for “complex event processing” as “something else processing” because the term “CEP” has already been hijacked by software marketing departments. I am not going to follow your lead … e.g. that terminology is “important” when it benefits me to be important; and terminology is “not important” when it benefits me for terminology to be “unimportant”. I am going to continue to work on being “technically correct” (honest), not “convieniently correct” (dishonest). As I have said in the past, the EPTS definition for “complex event” is laughable and sets the state-of-the-art of event processing back 10 to 20 years.
What the current vendors are doing with their so-called CEP software does not match any of the original ideas behind the DARPA funded CEP research in either scope, functionality or complexity. It is not “negative” to say so, it is simply a fact; and the sooner we set things right, the better for the users.
There is very little chance I am going to stop pointing this out, because I am technically correct. Most of the folks who are using the term “CEP” in their posts and in their marketing material have zero to little knowledge about how to detect anything beyond a trival pattern match for a routing decision. This is not CEP, it is simple and plain-old event processing.
The current lack-of-knowledge and “not invented here” attitude by vendors selling EPP as CEP is not my problem; but it does cause problems with users who have true complex problems to solve. I am on the side of the users, not the vendors.
I hope I have made myself clear
And furthermore, my position has been consistent since (pre-EPTS keynote) March 2006, three years ago, when I put a chart up on the wall in NY and explained how CEP requires methods far beyond simple database joins and queries across sliding time windows. Nothing has changed, except that software marketing has dropped the ESP term and jumped on the CEP term, all without any regard for the science of actually detecting complex events!
Yours sincerely, Tim