Imaginary Voyage - the story of IT department of Hog HedgeFunds
Mahesh Kumaraguru <>
8 Sep 2007 10:12AM ETOphir,
I started Hog HedgeFunds 30 years ago and initially all work was done using paper. First year of operation showed good profit and we decided to invest in Automation using computers. Con Sultans software consultancy services were hired to determine the best automation strategy and they suggested IBM's AS400 with Cobol400. The management started a "Portfolio Management System" (PORT) project. The high level technical view of this system is
Screens - CICS400
Database - DB2 UDB for AS400
Operating System - OS400
Language - Cobol400
Shell Scripting - REXX
The system does "Portfolio Rebalancing to maximize Return and Minimize Risk" (runs a MiniMax algorithim) to give my traders a Buy X1,X2,...,XN and Sell Y1,Y2,Y3,...,YN SOD (Start Of Day) list which is Traded using Phone, Fax, Telex, Manually, etc.
At the peak of Performance, Hog HedgeFunds took over Con Sultans software consultancy services.
Over the years, many homegrown systems used by different departments were built which did accounting,reporting, tax lot calculations etc. and these programs held significant domain knowledge from the portfolio managers, traders and other business staff, some have left the hedgefund. When desktop computers with GUI (Graphic User Interfaces) appeared in the market, screen scrappers / database integration were used to provide access to parts of Cobol400 Core business applications.
With the advent of electronic networks, some automated trading was adopted and the Cobol programmers and data analysts created a data format for orders (comming from PORT) and trades (going into PORT) which was internal to Hog HedgeFunds (HH Format). Then for every execution venue, Java programmers build interfaces (adapter software OO design pattern) to convert from / to HHF and whatever the format the execution venue needed and send Orders and receive trades "over the wire".
When Market Data started being available electronically, a program was developed to feed Market Data received in BUM format (Best Unified Market Format) to do EOD (End Of Day) data feed to the existing Cobol400 Rebalancing module for the nightly rebalancing batch process. BUM was a great Market data source at the time it was first released, but of late it is being noticed that there are latency issues and there is talk of FAST protocol being much faster.
We extensively trade with Broke Stock Brokerage. Recently in a meeting, I was informed that Broke Stock Brokerage is discontinuing the BITCH (Best Integrated Trading CHannel) trading protocol and has decided to move to FIX in a phased manner. Since our HedgeFund currenlty does not connect to any FIX only venues, our business decided to adopt FIX. Since we do not intend to migrate / replace the Cobol400 system in the near future, our IT department posted Java-FIX developers required ads to help develop FIX and FAST interfaces to the Cobol400 Core business applications. This job advertisement has left you wondering "Who the Hell on Earth wants to integrate something as new as FIX with something as old as Cobol". Valid point. We received ideas from software development companies offering to rewrite the entire legacy applications into latest N-Tier technologies, but presently do not have the budget for this kind of grand project. Definetly we have this in our longterm plans, but not now. Presently, we only need a few Java developers with FIX knowledge.
This just a typical example of the need for "Enterprise Application Integration".
Widely discussed in J2EE (Java 2 Enterprise Edition) circles and very good example of Enterpries Application Integration of Cobol to Java is the "Fly By Night" assignment of Sun Certified Enterprise Architect (SCEA)
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=forum&f=26
Regards,
K. Mahesh
+1-203-252-4039
Disclaimer Notice :- All names of companies, corporations, people, etc. are imaginary except Mahesh and Ophir. All real software trademarks are owned by their respective companies.
