Tuesday, February 28, 2006

Case Study: Distributed Computing in Financial Services

We've got a new case study up over at the Digipede site, and it's one of the most exciting customer stories we have.

The customer is a large financial services company (who, being very secretive about the methods of their success, prefers not to be named). Nameless, but big: they manage scores of billions of dollars.

They do a lot of analysis, naturally--minimizing value at risk, satisfying portfolio constraints, and managing transaction costs.

They have a great .NET development team, and they had been developing their own distribution system to farm all of this work out across 20 servers. They made what is a common discovery: they were spending more time writing the code to do the distribution than they were working on their own algorithms. They looked around, and they found the Digipede Network.

Within a week they had a proof-of-concept implementation, and within two weeks of that they were ready for production. That was my favorite part--their lawyers took longer to approve the sale than their programmers did to port their software!

I'm not bringing this up just to brag about a great product. It really speaks to the core of how important a good development framework is. By allowing their .NET and COM developers to take advantage of many machines without rearchitecting their solution, the Digipede Framework simply removed distribution as an obstacle. They are now using the Digipede Network for a variety of applications--everything from C++ to VB to C#, using both COM and .NET.

By bringing in a third party tool, they now have a distribution system that's more scalable, more powerful, and, most importantly, lets them concentrate on their core competency.

This is a scenario I hear about all the time. Developers need to scale an application (maybe it's a web application, maybe a 3-tier application) so they start down a path of multi-threading or .NET remoting (or DCOM or COM+). But soon they realize that the distribution part is hard (especially if they want robustness, good monitoring and reporting, guaranteed quality-of-service, etc.).