Tim Bass
11-15-2008 03:23 PM
Sometimes I think Marc Adler is reading my mind, and I wonder how he does it.* I have been thinking for weeks about writing a detailed post about why Algorithmic Trading is not Complex Event Processing; but then Marc pens the thoughtful,
Do You Really Need a Commercial CEP Engine?
In his post, Marc provides some interesting analysis and concludes that
“if a commercial CEP vendor has a vertical application that solved our needs” the commercial CEP engine would be useful.* In other words, in Marc’s domain, what Marc seems to be politely saying is that if CEP vendors built robust algorithmic trading platforms they would be useful as algo trading platforms.
Frankly speaking, I experienced the exact same thing in Japan almost two years ago.* When we presented one vendors “engine” to the Japanese finanacial services client, their response was
“We like [your company] and we respect you because of your messaging, but our clients want immediate, proven, robust algo trading out-of-the box.” Basically, all clients we talked to in Tokyo did not see very much merit in buying an engine that needed specialized programming, training and people from a company that is famous for infrastructure engines.* They wanted domain expertise not a “flexible platform” which is a fallacy promoted by software companies.
As Marc said, there are already myriad platforms for building algo trading applications and you can hire very clever C, C++, C# and other “down on the metal” system and applications programmers to do it.** The question I believe Marc could have also asked is next.* In addition to asking,
Do You Really Need a Commercial CEP Engine?, which is a perfectly valid question, Marc might have also asked,
Will Commercial CEP Engines Replace Algorithmic Trading Platforms?
Stream processing engines, marketed as “CEP” are actually not doing anything that many of us would remotely call “CEP” as was discussed when CEP was envisioned.* In fact, the class of detection-oriented, complex problems discussed in the original CEP literature is, for the most part, almost unsolvable by the stream engines marketed as CEP.*** What is being sold is actually “event stream processing platforms”, which is very similar to what the
The Securities Technology Analysis Center (STAC) calls this technology, as I recall.
STAC has the right idea.* STAC knows that these stream processing engines should not be called CEP products, because they are not really processing complex events.** They are right, 100%.* Just because your marketing department calls something “CEP” does not make it so.** Which leads me to my original premise, why do we find it necessary to rename algo trading platforms, “CEP platforms?”* We do not need to redefine the algo trading space as the new CEP space.* It simply is neither accurate nor useful, in my opinion.
I don’t think any of us have any problem with folks creating vertical algo trading platforms and intelligent order management systems.* This is a good thing.** However, it simply confuses the market to continally redefine CEP as something the software can actually do versus what CEP must do.* Processing streaming events and doing relatively simple pattern matches is not processing complex events.* As Marc shared with us,
“our system does not do any sophisticated pattern matching yet. Right now, we are doing a lot of aggregations, groupings, rollups, and simple comparison testing in order to generate alerts and real-time dashboard information.”
This is precisely what clients have told me for two years.** “Aggregations, groupings, rollups, and simple comparison testing in order to generate alerts and real-time dashboard information” are generally only precursors to a true CEP application.** We have been doing similar things for decades with other tools.** These current generation platforms cannot, for the most part, detect nor process complex situations, and therefore, should not be called CEP platforms.
Source...
