Powers Unfiltered

But what about the applications? I’ve mentioned this before, and the idea is not originally mine, but the majority of financial calculations are still done using spreadsheets with large overhead, interpreted languages. I think this is a pretty good place to start.

OK, Greg, you’re on the money yet again, and it’s time for a bit more depth on spreadsheets. There have been a number of efforts to grid-enable spreadsheets in the past; for the most part, they’ve been “demonstration projects” that bolt a spreadsheet onto the front of an existing grid system, and the uptake has been pretty disappointing. 

But this political correctness of the grid community in never naming names is starting to get in the way of real communication. Let’s be real — the right word isn’t “spreadsheets,” it’s “Excel.” And it’s not “large overhead, interpreted langauages.” It’s “VBA or .NET.”  When we talk about applications for the grid, one of the key insights we need to have is that “applications” are made by application companies, and they’re made to run on a certain platform.  In the space Greg identifies, financial modeling in spreadsheets, there is only one player — Microsoft Excel. So using financial calculations in spreadsheets as “a good place to start” requires solving the big, complex problem of grid-enabling Microsoft Excel spreadsheets on Windows — not the huge and probably intractible problem of abstracting out another layer to grid enable “spreadsheets” on diverse operating systems.

So — what’s the right way to grid-enable financial models in Excel? That turns out to be a function of how the Excel spreadsheet is structured, but by focussing on .NET on Windows (not “applications” on “operating systems”) it’s pretty straightforward, and Digipede customers are now using Excel on a grid quite routinely.  Whitepapers and videos are available on this topic, so I won’t go into more detail here.

The great thing about Excel is that it’s so universally used, especially within the financial services community, that innovation (from within Microsoft and beyond) continues at a blistering pace. Any Next Big Thing for Excel has the potential to be very lucrative, because of the huge base of wealthy and demanding users. (Make a demanding Firefox user happy, and you have bragging rights; make a demanding Excel user happy, and you have money.)

So one Next Big Thing for Excel is Excel Services. Microsoft has its own way of describing this new Sharepoint-based product, but I just tell people it’s the way work done by your smartest analyst can be published securely for your whole organization to use. This product aligns Excel (wittingly or not) with the SOA movement — Excel Services can be accessed through a browser, or programmatically through a Web Services interface, and hence can be incorporated far more easily into larger applications. Grid-enable THAT and you’ve really got something.

Oh wait — we did. Dan Ciruli’s excellent series of posts describes what he did to put the Digipede Network behind Excel Services, so all the work by “your smartest analyst” can scale when you expose it to “your whole organization.” The series goes:

Gettin it on with Excel Services
What Is Excel Services 2007, and What Is a User Defined Function and Why Should I Care? 
Adapting a Spreadsheet to Excel Services
Why Beta Software Is Hard To Use, and How A Huge Company Still Listens to the Little Guy  (OK, that one’s a bit of a detour, but a worthwhile part of the story); and
All’s Well that Ends Well, and Why Put a Grid behind Your Spreadsheet in the First Place

I’ll wrap up by saying that we think Greg’s focus on applications is dead on, and his example is dead on as well.  Just as spreadsheets (VisiCalc and Lotus 1-2-3) were the killer application for the personal computer, spreadsheets (Excel and Excel Services) may become the killer app for the grid as well.