COM and .net, FIX and ITCH/OUCH

Most posts on here are clearly sat in either technology or business.  This is a rare one that uses technology as a way to look at business.
Firstly, I recommend reading this post “How Microsoft Lost the API War” by Joel Spolsky here .  He published the article in June 2004 so there are some points that have not aged well, but for a ten plus year old article he makes some great points.  Joel worked at Microsoft back when Bill Gates conducted code reviews and while I’ve never met the man I have read a lot from him and he has some interesting and thought provoking viewpoints.
His conclusion is “None of this bodes well for Microsoft and the profits it enjoyed thanks to its API power. The new API is HTML, and the new winners in the application development marketplace will be the people who can make HTML sing.”
 
Now, let’s look at the FIX side of this and here I recommend reading this post from George Kledaras here.   George is a man with whom I have done business and while I am not doing so at the moment, I would happily do so again.  An honourable gentleman.
So, let’s review this and get to the meat of this post.
Joel posits that the API is the key and that when moving from COM to .NET Microsoft lost the war.  From my viewpoint of technology I see merit in that, I have not seen a new build of a large enterprise application that run exclusively on Windows for some time.  Indeed, the default design pattern for large applications now seems include a great deal of diversity in terms of the core application stack – so open source tools commingled with proprietary code rather than a straight up and down Microsoft stack.  As a comparison, in the late 1990s I worked on a trading application with a technology stack that looked like this:
  • Client application VB6 and C++ running on Windows, connecting by Microsoft Message Queue to the middle tier
  • Middle tier – VB6 running within Microsoft Transaction Server on Windows Server.
  • Relational database – Microsoft SQL Server running on Windows Server
  • FIX engine – Java Application running on Windows Server, connected via sockets to middle tier
  • Extract/Transform/Load – Microsoft Data Transformation Services using Visual Basic Script running on Windows Server
Compare to a recent project:
  • Client application – HTML5
  • Web server – Apache on Linux
  • Middle tier – Tomcat on Linux
  • FIX engine – Java application on Linux
  • Relational database – Oracle on Solaris
  • Visualisation module - C# on Windows
Obviously this is only one experience but I think we can all agree that the adoption of Windows Server in Financial Services for trading application has decreased sharply over the last ten years or so.
If we look at the world of Electronic Trading we have seen a growth path of FIX adoption. My experience starts in the late 1990s and since then I have seen FIX become the standard for communications between the buy-side and sell-side in the trading space.  There has also been adoption by networks and vendors such as Tradeweb, FXAll, MTS, FXConnect, LMAX and many others.
Within the exchange connectivity space we have seen an increase in usage of ITCH and OUCH – there’s a good article here
Hence my view is that in order for FIX not to become rather like the COM of Electronic Trading, the FIX Trading Community should work with NASDAQ OMX to bring ITCH and OUCH under the umbrella of FIX Trading Community.

Comments