My friend Opher mistakenly thought I was thinking of him when I related the story of the fish, as he replied, CEP and the Story of the Captured Traveller.
I must not have related the fish story very well, because to understood the story of the fish, is to know that we are all like the fish, in certain aspects of life, and there is nothing negative to be gleaned from the story.
However, to Opher’s point on CEP, I disagree. Just because the marketing people (not the market) has misdefined CEP and therefore the vendors are drifting from the technology described in Dr. Luckham’s original CEP work, including his CEP book, we should not change the context of CEP. Therefore, I don’t agree we should redefine CEP, as David envisioned, as Intelligent Event Processing (IEP) because CEP, as today’s software vendors sell it, is really SEP (or whatever!) Please recall that David’s background at Stanford was AI and he did not define CEP as the software vendors have defined it either!
The fact of the matter is that the software marketing folks have decided they are going to use Dr. Luckham’s book to sell software that does not perform as Dr. Luckham described or envisioned! I make no apologies for being on the side of end users who actually need to solve complex problems, not sell software that underperforms.
As I mentioned, this positioning and repositioning does not help solve complex problems. At the end of the day, we have problems to solve and the software community is not very helpful when they place form over substance, consistently.
Furthermore, as most customers are saying, time and time again, “so what?” … “these COTS event processing platforms with simple joins, selects and rules do not solve my complex event processing problems.” “We already have similar approaches, where we have spent millions of dollars, and they do not work well.”
In other words, the market is crying out for true COTS CEP solutions, but the software community is not yet delivering. OBTW, this is nothing new. In my first briefing to the EP community in January of 2006, I mentioned that CEP required stating the business problem, or domain problem, and then selecting the method or methods that best solve the problem or problems.
To date, the CEP community has not done this because they have no COTS tool set other than SEP engines (marketed as either ESP engines or CEP engines – and at least ESP was closer to being technically accurate.)
Experienced end users are very intelligent.
These end users know the complex event processing problems they need to solve; and they know the limitations of the current COTS approaches marketed by the CEP community. Even in Thailand, a country many of you might mistakenly think is not very advanced technologically, there are experts in telecommunications (who run large networks) who are working on very difficult fraud detection applications, and they use neural networks and say the results are very good. However, there is not one CEP vendor, that I know of, who offers true CEP capability in the form of neural nets.
Almost every major bank, telco, etc. has the same opinion, and the same problem. They need much more capability than streaming joins, selects and rules to solve their complex event processing problems that Dr. Luckham outlined in his book. The software vendors are attempting to define the CEP market to match their capability; unfortunately, their capabilities do not meet the requirements of the vast majority of end users who have CEP problems to solve.
If the current CEP platforms were truely solving complex event processing problems, annual sales would be orders of magnitudes higher. Hence, the users have already voted. The problem is that the CEP community is not listening.