• subscribe
December 22, 2008 12:00 AM

Ready? Set? Kilimanjaro!

SQL Server Pro
InstantDoc ID #100840

Executive Summary:

The pre-beta announcement of the business intelligence (BI) focused interim release of SQL Server, code-named Kilimanjaro, has Michael Otey concerned that Microsoft marketing might be jumping the gun and creating confusion for enterprise IT departments.


When Microsoft announced the 2010 Kilimanjaro release at its October 2008 Business Intelligence (BI) Conference, I thought, “Oh no! Not yet!” It isn’t because I have technical reservations about this BI-focused incremental release of SQL Server: I’m concerned about the marketing and the timing. 2010 is just too soon for another release of SQL Server. SQL Server 2008 was released more than halfway through 2008, and its adoption curve is still in the infancy phase.

A super-early announcement of a follow-on product can create confusion and even uncertainly about the current product. Should a company upgrade now to SQL Server 2008 or should it hold off for the Kilimanjaro? Such announcements also cast doubt on the product that was just released. Quick subsequent releases can make it appear that the product needs to be fixed or replaced right away. Even when that isn’t the case, it might create the appearance of a problem to businesses.

The Microsoft Major-Minor Release Cycle

While the marketing spin on the new release will be about customer choice, don’t forget that Microsoft plans for product releases on a major-minor cycle. Each server product gets a major release about every four years and then is followed by a minor R2 release about two years later. In the past, customers waited a long time (around five years) for products such as Windows XP and SQL Server 2005, so I can understand why Microsoft wants to shorten the release cycle. However, two years is too short, especially for an infrastructure product like SQL Server. The less often a company needs to mess with the core components its IT, like SQL Server, the better—to a point. Replacing your company’s database servers every two years is just too often. I think the major-minor release cycle works better for products like Windows Server than it does for products like SQL Server.

Kilimanjaro and Madison

So what exactly is Kilimanjaro? As you might expect for such an early announcement, the details about Kilimanjaro are still sketchy. Microsoft intends for the Kilimanjaro release to improve its capabilities for data warehouses of all sizes. The Kilimanjaro release will also be the foundation for Microsoft’s first data warehousing appliance, code-named Madison.

Kilimanjaro and Gemini: Self-Service BI

In conjunction with the Kilimanjaro release, Microsoft plans to provide a set of easy-to-use data analysis tools code-named Gemini. The Gemini tools are add-ins to Microsoft Office that will allow information workers to create their own BI applications and have better access to SQL Server BI information from Microsoft Office. Gemini will let Microsoft Word and Microsoft Excel users use BI from within the Office applications they already know. Microsoft calls this “self-service BI.” For more on the Kilimanjaro, Madison, and Gemini releases, see the Microsoft press release.

The Evolution of SQL Server

On the one hand, it’s good to have product planning information well in advance to understand how the next generation of SQL Server is evolving. On the other hand, knowing about the future and actually being able to deploy a new SQL Server release across the enterprise every two years are very different things. In the real world, most businesses just can’t keep up with that pace.



ARTICLE TOOLS

Comments
  • Marcos
    3 years ago
    May 05, 2009

    I would say that this is not a Microsoft's choose. The company has to catch up the time it loose. It is well know that Microsoft's BI platform comes late to the market, if the company wants to increase your share, it has to act like that.

  • Henik Staun
    3 years ago
    May 05, 2009

    improvements every 12 months is not too often...

  • Brian
    3 years ago
    Jan 16, 2009

    Just to finish my last thought. Let's not forget that SQL Server 2005, was originally intended to be SQL Server 2003.

  • Brian
    3 years ago
    Jan 16, 2009

    I'm not sure I agree. Are you sure you aren't just applying the flawed logic of Microsoft's release mistakes between 2000 - 2005? The years when MS releases were too far apart?

    Yes, upgrading infrastructure every 2 years is probably too often. However who says the infrastructure must be upgraded that often? Microsoft? It's a customer's choice more than it's Microsoft's. And yes, I'm totally aware that with 3rd party systems there can be major restrictions (or obligations) related to the 3rd party's support requirements.

    These aren't mandatory upgrades... As numerous sources have indicated, lots of products/companies are still using SQL 2000, and may skip directly to SQL 2008 (2010?) when the time comes.

    Also, you are placing too much weight on the "directly supported, single-step" upgrades. What's to stop a customer from doing 2-stage upgrades? That's always been an option on every platform I've ever used. If you fall behind and then catch up, you upgrade through as many steps as it takes to get current. That's part of the price of falling behind.

    Falling far behind current always has an interesting dynamic. You certainly risk losing support from your vendor. On the other hand, the products tend to be well known, are often fully Service Packed/Updated, and the real world need for vendor support often drops dramatically. Never to zero though.

    Vendor releases should be viewed as customer opportunities to upgrade, as choices to select from. More choices, in this model, are usually better.

    The two years between SQL 2008 and 2010 hardly seem like a precipitous act on Microsoft's. Nor do they seem like a vote of non-confidence in SQL 2008. I've worked for years with companies and products whose stated goal (whether met or not) was an annual release cycle. Many of these systems were massive applications on the functional scale of an ERP system.

    Finally, let's not forget that release date slippage is always a possibility.

  • KEVIN
    3 years ago
    Jan 12, 2009

    Very useful info on the 2010 release. I agree that it is too soon.

You must log on before posting a comment.

Are you a new visitor? Register Here