Xenomorph’s thoughts on Clustering
Chris Budgen, Chief Technical Architect, Xenomorph
- What experience has Xenomorph in applying clustering to financial markets?
-
The first usage coming through from clients was in scaling out the pricing and re-pricing of derivative and fixed income portfolios. At that time, we used Microsoft Application Centre 2000 to load-balance pricing calculations across multiple CPUs and servers. This took the client’s preferred pricing model vendor (in this case FinCAD) and distributed this calculation load as COM+ objects across a dedicated cluster.
- What was the business need from the client?
-
The client was a major asset management institution moving into the use of derivatives within their investment process. They wanted an architecture that would allow their end of day P&L and risk management processes to scale with the growth of their business.
- Were there any major technical issues from the implementation?
-
When Xenomorph first started looking at the clustering technology back in 2001, it was very young. As a result, we had to do battle with a number of irritating bugs and shortfalls in Microsoft’s technology offering at that time, particularly around memory-management and lack of fault tolerance in task redistribution. In fact, to develop true fault tolerance, we had to develop most of the solution ourselves!
Once the fault tolerance and task redistribution issues were overcome, we then had to focus on applying object serialisation and batch techniques to eliminate bottlenecks introduced by database and network overhead.
- What performance benefits did you observe?
-
This depended on the number and nature of the instruments being priced and the models being used. For simple instruments (straight bond pricing for example) you needed to batch them up in bulk to see the benefit, whereas for compute-intensive models that took seconds to price (e.g. Monte-Carlo), the speed benefit was much more obvious. Essentially if the cost of the model far outweighed the cost of getting the pricing object ready to price on the target node, then redistribution was worthwhile. In this case, a near N-fold improvement was observed, where N = number of nodes in the cluster, assuming of course that all nodes in the cluster were of equivalent specification.
- What are Xenomorph currently doing with clustering technology?
-
We are looking at extending our existing calculation server framework to work with the latest in clustering technology. I guess the main driver has come from clients looking at ever larger portfolios containing multiple instrument types, plus on the technology side things have matured so that current clustering and grid solutions offer users (and developers) much more control over the jobs to be executed and their priority. We are looking at Microsoft CCS and technology from supporting vendors such as Digipede (www.digipede.com), and are checking these technologies out thoroughly before investing heavily in them there is no substitute for checking that they do what they say they do!
- What types of instruments are now supported by this calculation server solution?
-
Our solution is built around TimeScape Data Services and TimeScape Pricing Services, whose architecture is designed to cope with changing business needs. This means our clients can extend support any kind of instrument they wish to add, as and when their business needs dictate. The framework is plug-in based, which means new components can just be dropped in to extend the pricing functionality as needed. That said, we support over 150 asset class template out-of-the-box, from the simplest equity to the more complex derivatives (e.g. convertibles) and structured products, so many clients seldom need to do this.
- What types of models do you support?
-
Which ones do you want? No seriously, coming back to my last point on our solution’s flexibility, our founding principle is to design on the assumption that clients’ business needs are guaranteed to change and that includes their models. We also recognise that organisations will want to use best-of-breed models to meet their business demands.
We ourselves are not model vendors, which is why we have deliberately designed our solution to allow clients to incorporate their own or third-party models as they see fit. Clients may choose to utilise models provided by one of our partners (NumeriX, FinCad, Monis, or MBRM) or their own in-house models we leave that decision entirely up to them. The important thing is that they can choose to use a mixture of model vendors if that suits their need they do not have to be tied to a single model vendor, which we find gives them greater choice and comfort. It also makes for some interesting benchmarking comparisons!
That said, we do provide a set of simple models out-of-the-box to get clients started, but we find most clients either have their own they wish to use or prefer to adopt a vendor with recognised expertise in that particular instrument pricing field.
- Microsoft has recently released Excel Server for managing centralised spreadsheets can your solution integrate with these?
-
Yes, indeed it can and more! In fact, Xenomorph were actively involved in the beta program for this and worked closely with the Excel development team in Redmond to explore the possibilities of using this technology within our solution.
As a result, we can now integrate with Excel Server workbooks in an identical fashion to how we use any other pricing model. This means that through our solution, clients can price across a vast range of different instrument types, including structured/bespoke products that they have modelled in Excel workbooks. We even provide integrated access to desktop Excel add-ins (XLLs) that Excel Server does not yet itself support. We see this as important, as many clients have invested a lot of effort in that technology. Thus clients who use our solution can migrate seamlessly away from desktop-based spreadsheets to server-managed ones without having to invest huge technology effort in rewriting their models.
All this happens through a single, consistent pricing API that normalises access to the underlying instrument, irrespective of how the client is choosing to model that instrument. It could be a model they have coded themselves, a third party model they have integrated or one that they have structured in an Excel spreadsheet. At the end of the day it makes no difference to us. We just remain focussed on providing the quickest means of delivering cost-effective business value to the client. Our support for Excel Services is just another natural extension of that philosophy.
- Where are Xenomorph looking to apply clustering technology next?
-
We are now actively extending our clustering solution to offer distributed, real-time queries that we’re branding “Active Queries”. These will be linked to live market data, pricing, risk and scenario analysis components to provide real-time notifications on any analytic you may wish to perform. This could be anything from a recalculated fair value on an option, to a live implied volatility surface or to an entire portfolio re-pricing using real-time market data.
- Interesting times what else are Xenomorph up to away from clustering?
-
Good question. Probably the most significant development lies in our work with Microsoft SQL Server 2005. We have invested significant effort in this area over the past year. In particular, we have been working closely with the Microsoft SQL Server team to move our TimeScape XDB object database technology into SQL Server 2005. We see tremendous opportunity in this space to combine the best of characteristics of our object database with theirs and set a new benchmark for database technology for the coming years.
Away from the database, then we also continue to work with our clients to extend our query engine capabilities to take it to the next level, particularly with regard to scripting in the areas of scenario and back-testing analysis. Again, you can expect some new products announcements in this area over the course of the next year.
Chris Budgen, Chief Technical Architect, Xenomorph


