How to build a scalable derivatives risk & pricing platform using open source software March 30, 2007
Posted by James Webster in : software, finance , 6 commentsJust some brief thoughts on how a selection of open-source software might be used to build a architecture stack supporting a derivatives risk & pricing platform, a common system found on derivatives trading floors.
- QuantLib: A popular quantitative finance library implemented in C++ with multiple language bindings. It would provide a good base upon which to build more exotic (and proprietary) models. There are a number of commercial toolkits available as well.
- Hadoop: A Java implementation of Google’s MapReduce algorithm. Hadoop would support horizontal distribution across a server grid of the pricing calculations implemented by QuantLib within a Monte Carlo method framework. A commercial alternative (although much broader in scope) would be DataSynapse. Also have a look at the recently released IBM alphaWorks MapReduce Tools for Eclipse.
- OpenTick: You have to pay the exchange fees for the data but otherwise OpenTick provides an open API for accessing real-time and historical ticks for a broad range of US exchanges and ECNs.
- Ehcache: Although Hadoop includes a Distributed File System it is geared towards large files. A better solution for ensuring the prices received and the figures calculated are updated across the server grid would be a distributed cache. Ehcache has had basic distributed caching for a while now. A commercial alternative would be Tangosol Coherence.
- Esper: Event stream processing (aka complex event processing) is becoming a big part of trading systems. Plugging an ESP toolkit into our stack might provide a way to support algorithmic trading or identification of arbitrage opportunities. There are many commercial players vying for success in this market.
- Amazon EC2: And finally, as a deployment option why build your own grid of servers when you can rent one? There is already a HOWTO for running Hadoop on EC2. One drawback to using EC2 is the current lack of support for IP multicast, but I suspect this will change one they are able to effectively firewall off multicast packets from separate EC2 domains. Another drawback that may be harder to overcome is the latency arising from the Internet links between OpenTick, Amazon EC2 and the trading workstations that ultimately receive the output of this platform.
Whether some of the open-source alternatives I have suggested are appropriate substitutes for their commercial brethern is highly debatable. Nevertheless the commoditization of software continues.
Where’s my GUI designer for lo-fi prototyping? June 29, 2006
Posted by James Webster in : software, development , 2 commentsAt my current client we have been spending time doing a little release planning. This has included creating some mock-ups of screens for a system that until now has been batch-oriented. So far we’ve been creating these mock-ups in the most lo-fi way possible; scribbled on the back of an index card. I had the good opportunity to recently receive some insights into the process from my colleague Luke Barrett who is a whizz at producing GUI prototypes within Powerpoint, which may sound strange but he really makes it work. Other’s prefer to use a wireframe template for Visio or OmniGraffle. Then there is the intriguing Napkin Look & Feel for Java’s Swing toolkit.
What I’m wondering is; can we do effective GUI prototyping using more traditional GUI building tools? What would a GUI builder targetted solely at producing prototypes look like?
A few quick thoughts I’ve had about this…
- Napkin LAF would be mandatory: forcing all prototypes to be rendered in a ’sketched’ fashion will reinforce in the mind of all that view them that they are just prototypes and are fair game for critique.
- Must be simple enough for non-technical people to use: most GUI designers I have used tend to be quite challenging to work with. Through arguable necessity they are festooned with palettes, property panels, toolbars and other assorted widgetry to build functional GUIs. This tool however could be much simpler; no event handlers need to be wired up, no futzing around with colours or fonts should be possible. Simple palettes of controls and contextual editing should suffice.
- Must be light on resource usage: Whilst many developers have the luxury of a high-performance workstation to satiate the resource demands of a modern IDE, most business users and domain experts generally do not. So in addition to being easy to use, this GUI designer should run well on lesser-spec’d machines.
- Can export completed screens/pages/dialogs to common image formats.
- Would include a palette of controls with common labels: I’m thinking of stuff like buttons with ‘OK’, ‘Save’ or ‘Cancel’ labels. Or perhaps drop downs populated with states/countries, etc.
- Should support grids/tables to be set up easily: Most database-backed systems will have several screens that involve the display of tabular data so the prototyping tool should lend a hand in this area.
- Would support the generation of lorem ipsum text.
So what do you think? Am I onto a good idea here or is it all just YAGNI? And if it IS a good idea, would someone care to build it for me?!
Dynamic vs Static languages… FIGHT! March 16, 2006
Posted by James Webster in : software, development , 1 comment so farVia Obie, Reginald Braithwaite argues that compile-time type checking doesn’t buy you much in today’s world. I agree, especially if you are doing test-driven development.
There is alot of activity getting dynamic languages to work on top of existing VM’s such as the JVM and the CLR. Over at Microsoft, IronPython’s pace of putting out betas is impressive, whilst over at Sun, James Gosling is warning of the dynamic language barbarians at the gates.
Interpreting the language (Ruby, Python, whatever) to native JVM/CLR bytecode is only half the battle however. When the standard libraries for those languages are implemented through the underlying capabilities of java.* or System.* things will really get cooking. In my opinion, whichever of the JVM or CLR can get Ruby (and Rails) to run seamlessly on their platforms first will win a lot of kudos in the enterprise space as they will gain the productivity of Ruby/Rails, plus the integration with alot of ‘native’ Java/.NET code. The JRuby project is already making progress in this direction (albeit without Sun’s help). Scoble asked late last year what MS could do to make ASP.NET development more appealing. Get Ruby & Rails to run on the CLR, that’s how!