I was recently talking to a very technical algo trader from another company about CEP. I asked him why he did not use a product like Apama or Truviso for his algo trading needs. His reply was that it did not give him a competitive advantage if he used the same technology as other competitors used. He has the budget and the resources to build out a custom platform, one which he thought would give him a distinct advantage.
©2009 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Subscribe to:
Post Comments (Atom)
10 comments:
Here's the most common objection I've heard: "Let's write the code ourselves and put that money toward our bonuses." Hard to argue with that.
Buy or build - you still have to have your 'secret sauce'
But, does the language of the CEP engine let you express your secret sauce? And, does the performance of the CEP engine allow you to execute your secret sauce in front of the competition? (OK, the CEP engine is only one part of the entire infrastructure, but trading firms spend a substantial amount of time optimizing each little segment.)
People who think this way are missing the point about platform technology. It's the food chain effect. Starting at the bottom it’s the reason Java is better than C. Java provides a wealth of class libraries, C has a barebones ANSI C lib, which means you have to write practically everything yourself. With a platform you move up the food chain. How many people would consider writing their own AppServer? That platform (J2EE) takes Java to the next level. With a platform you get (and should expect) a set of ‘ilities: scalability, reliability, high availability, manageability, security, etc. See http://www.softwarearchitecturenotes.com/architectureRequirements.html for a very nice list. They are the ante into the game in any platform architecture (CEP or otherwise) and necessary functions in any production deployment. By adopting a platform architecture it allows you to focus on higher level business functions (be it trading or other). The lower you start on the food chain, the more your assume the ownership and the headaches of these mandate but vital functions, and they will ultimately detracting you from your stated goal (i.e. making money in the trading world).
Assuming that Louie was responding to my comment, it depends on how you do your P&L accounting.
If you do the normal project by project and annual accounting, then every project needs to justify the cost. The 300K hit from a software package had better work out really well, or it will just drag down the P&L for that year.
If you do your accounting over multiple years and many projects, then you start to see the platform effect. But that is not a very common way of doing P&L.
I think Louie said it well.
I couldn't help but wonder: Why would a trader think that implementing his algo on a commercial platform wipe out his competitive advantage? Surely his secret sauce is in his trading algorithm and not his ability as a programmer to write better (faster?) code? If he's got a superior algorithm, is there benefit to getting it into production sooner?
And if the attitude is really driven by the idea that it's cheaper to write it themselves, that says programmers with a lot of spare time, looking for things to do. I don't see many of those these days.
I don't think you guys appreciate the extreme low latency algorithmic trading requires. By the time your CEP engine has popped an order message from the queue for processing our trading engine has already acted on this information. Even running complete strategies in FPGAs is not far out... Microseconds count.
So there are many kinds of algorithmic trading and not all of them require low latency. But low latency strategies are often the most accurate over time, so that is why latency is such a big deal. For the low latency strategies, it's an arms race to be the fastest. In other words, a better algorithm will provide inferior results if it is not able to enter its orders in time to beat others to a particular price.
I have seen CEP engines support very low latency activity and I would not claim to have much faster software unless I have tested a particular engine. Some of them do go to great lengths to be low latency.
In terms of buy vs build, there is no right answer. All things being equal, the choice should be to buy rather than build. But all things are never equal, so in practice the answer is to evaluate on a case by case basis.
Louie, Java is not better than C. Maybe you're thinking of C++.
Let's not forget about the complexity of writing a CEP engine in the first place. A rules engine is a quite complicated piece of code, and even many of the vendors (such as TIBCO) haven't yet got it right. As of version 3 they're still missing 'not' and 'exists' operators. That makes it rather difficult for the trader to implement a strategy unless you work around these deficiencies with bits of Java code. Ironically, an open source CEP engine, Drools (reviewed at InfoWorld, has a full implementation, but it took them three versions before they got building the network right.
The moral of the story: building a CEP engine is a lot more complicated (and expensive) than it first appears.
Post a Comment