Blogger: Richard Watson
Over on the Executive Advisory blog Chris Howard discusses Monday's outage at the London Stock Exchange (LSE). The TradElect platform, built on .NET technology was down for seven trading hours. Knowing all I do about the demands of developing and operating trading systems, I’d be slow to throw stones at an entire platform and quick to murmur
glad it wasn’t me. Chris raises an interesting point about the choice of platform for trading applications:
A surprising amount of .NET infrastructure underlies sophisticated trading applications worldwide, both on exchanges and within Financial Services companies.
One contributing factor to this is that trading platforms are often built
outward in, the GUIs are established first, and design decisions made at the front-end drive the entire architecture. Initial financial product development is always done on spreadsheets. In many cases, portfolio and risk management remains on spreadsheets far longer than is prudent (or legal) to do so. For their interfaces, traders like familiarity – front office applications are typically modeled to appear tabular like spreadsheets. Traditionally Microsoft has the upper hand in the richness of the GUI widgets, and of course great integration with Excel.
This is a landscape that Microsoft is looking to exploit heavily with its Silverlight technology, and an important battleground for Adobe to try to gain a foothold in with AIR.
Front office developers are skilled .NET practitioners, and will tend to trust the technology when it comes to building out infrastructure. That trust and investment in development skills are huge factors in platform selection, despite the pleas of technical architects to turn to Java for high-volume mission critical systems. It’s not that there’s no Java, just less than you’d think. In fact Java is still looked on with some suspicion in the front office for latency-sensitive applications – because of its reputation for being interpreted (
it can’t be faster than my C code) and stopping the world to collect garbage. Of course this is almost entirely unfounded, in this age of real-time JVMs with predictable GC and JVMs that optimize reactively based on runtime profiling data. Again in a pinch, developers will stick to the tried and trusted. C and C++ will decay to their half-life slowly.
There are winners and losers in any event like this. The clear winners in this case are the competing multilateral trading facilities Turquoise and Chi-X, and dark liquidity pools. Trading organizations with smart order routing would have fared better – certainly brokers in a post-RegNMS/MiFID world could have sniffed out liquidity for some securities at alternative venues. Turquoise can’t do too much laughing – it had its own 80 minute outage last week, handling a fraction of the volume of LSE. I guess the other Superplatform players will believe that these outages will strengthen their claims to be more suitable for mission-critical environments. I’m doubtful. There are too many other potential sources of the problem – weaknesses in change management or testing strategies, for example. If anything, what is strengthened is the case for effective IT governance.
If schadenfreude is your thing, there’s plenty offered in this story. Clara Furse, the LSE chief executive headlined the FT's letters page on Monday, the day of the outage.
We have been operating an electronic trading engine since the introduction of SETS in 1997, and we recently introduced TradElect to ensure we remain at the cutting edge, she wrote.
The emergence of new trading platforms should test the attractiveness of our services. Indeed.
As Andrew Hill chuckles in the FT,
The higher the horse, the harder the fall.