Microsoft's Rationale for Code Name HellMicrosoft's Rationale for Code Name Hell

Kilimanjaro, Gemini, Madison... what's with all the code names and why does Microsoft need so many to describe developments that are all expected to bow in the first half of 2010? Herain Oberoi, group product manager of the SQL Server Business Group, cleared up a few questions for me here at the Micosoft's BI Conference 2008, but it took an outsider (from Teradata) to reveal another possible rationale for the confusing naming conventions.

The clear headliner in Kilimanjaro is "Project Gemini," which will bring in-memory, on-the-fly sorting, filtering and slice-and-dice analysis of massive (millions of rows) data sets to Excel with the aid of a client plug-in, controlled storage and sharing through integration with Sharepoint, and behind-the-scenes modeling by Analysis Services. So why two separate names? Well, Oberoi stressed that Kilimanjaro also includes self-service reporting extensions to Report Builder that will enable users to create, store and share report components that can be mixed and matched for what's described as rapid, grab-and-go reporting.Okay, so there's more to Kilimanjaro than Gemini, but why not include "Project Madison," the DATAllegro data warehousing technology, under the Kilimanjaro umbrella as well? Oberoi confessed that there's still debate about exactly how support for scale out appliances will be bundled. It could be a separate version of SQL Server, and given the questions still outstanding, he said Microsoft didn't want to hold up one set of new capabilities because the other project was on a different schedule.

Reading between the lines, then, Madison may be a later release, which may force me to eat my words. Back in July, I guessed that the DATAllegro integration would take 18 months. It still might if Madison bows in January 2010; if it's delayed until June of that year, it will have been 24 months, and Mark Madsen will be proven to be the better forecaster.

That brings me to the observation by one Teradata executive (who wasn't speaking officially for the company) that Microsoft is coming under intense pressure - fueled by last year's mega mergers - to split Analysis Services, Reporting Services and Integration Services off from the Microsoft SQL Server Database. Microsoft has coached us all to think of these things as inseparable from the database, but this executive points out these services are basically Windows applications that could easily stand on their own. When Teradata acts as a back end to Microsoft BI, as often happens through their partnership, customers can actually turn off Microsoft SQL Server if it's not in use. Microsoft's BI tools and services can also run on top of DB2 and Oracle (or MySQL, for that matter), so why tether Analysis Services, Reporting Services and Integration Services to the SQL Server database license?

In a corollary, BI software from vendors like Microstrategy and Business Objects (both exhibitors here) certainly runs on Microsoft SQL Server, but these vendors aren't exactly thrilled that all those BI services are part of the bargain. In short, Microsoft could wear a white hat by separating the services from SQL Server, but such a move might still fly in the face of the company's BI ambitions.

It's even clearer to me now why Kilimanjaro and Gemini are separate from Madison. Microsoft was clear in saying that these projects are neither a point release nor a service pack on Microsoft SQL Server 2008. They're too big a deal to be described as such, but these projects also don't add up to (and aren't the same as) the next full release of SQL Server. In fact, Kilimanjaro and Gemini actually have very little to do with the database and could be a pure BI release, if only those services weren't bundled in with Microsoft SQL Server.

Maybe all those code names are really about keeping all options open.Kilimanjaro, Gemini, Madison... what's with all the code names and why does Microsoft need so many to describe developments that are all expected to bow in the first half of 2010? A Microsoft exec cleared up a few questions for me here at the BI Conference in Seattle, but it took an outsider (from Teradata) to reveal another possible rationale for the confusing naming conventions.