Response to SQL Mag: Ready? Set? Kilimanjaro! Editorial

This will be a first, and I just had to do it. For some reason Michael Otey's January 2009 editorial just didn't sit well with me – it may have to do with the fact that we were at the same conference, the same speech, but it appears we both heard and interpreted two entirely different scenarios out of this information!! I bet that's never happened before!

Now that I'm done being silly, I want to share my letter to him with everyone to open myself up to criticisms as well -- I like open dialogue and many people out there will have experiences that either corroborate what Mike has put forward, what I have responded with, or, and quite possibly, something entirely different.

Feel free to post a comment or e-mail and let me know what you think of Mr. Otey's editorial and my subsequent response.

My letter:

In response to your editorial: Ready? Set? Kilimanjaro!

I want to open by stating that I am an avid fan of SQL Server Magazine; you and the rest of the staff put together a very useful, direct and informative monthly that I recommend highly to colleagues and clients.

However, I have to wholeheartedly disagree with your editorial post in the January 2009 issue, for the basic reason that I feel you missed the point of this release and what Microsoft is aiming at with future releases of its SQL Server product line.

One of the other key elements mentioned during that same speech was project Madison, which will incorporate the technology gained in the purchase of DATAAllegro into the SQL Server suite. This technology is aimed at supporting scalability and processing capability in the data warehousing space.

Why does this matter? In the past, and even with the current release of SQL 2008, the product differentiation is driven mostly by how large will your database setup (procs, nodes, etc) be and how much uptime are you looking for (clustering, etc). For most customers, they really do not know the differences they get in using Enterprise versus Standard – the stack just does not look that different to even seasoned developers.

Those who really need the Enterprise features will use them, but also in vastly different ways. High Availability clustering versus the enhancements Analysis Services gets in Enterprise mode don't always fall into the same needs bucket. More directly, what Kilimanjaro, Madison and Gemini mean for Microsoft, I believe (since I do not work for them), is that they are looking for more than just features as the differentiation for the SQL Server product. I believe that they are focused on the end use of the product, at what its purpose will be and drive off of that.

Madison will be focused on those customers with large data warehouses and Kilimanjaro at those wanting to take advantage of the enhanced BI feature set – related, but truly developing these days into two distinct skill sets and needs – as an example, how many deeply technical SSIS developers do you know that can also expertly do dimensional modeling, write MDX and design cubes? They are few and far between. The customer needs in addition to employee skill sets are segmenting.

You can imagine how this will work very nicely for their marketing department in trying to explain cost differences between the versions – it is much easier to speak to those with the purchasing power about a product's business role than it's I/T capability.

I also believe that you have simplified how companies approach a product, "Replacing database servers every two years is just too often". I completely agree, and Microsoft knows this as well. SQL 2000, 2005 and 2008 are all rock solid, and customers have stayed on them for years and will stay on them for years to come, another point Microsoft knows all too well. Madison and Kilimanjaro change by bringing in purpose specific releases of SQL Server, allowing an easier "story" on why a new product version is required versus pointing to how it now has DVD navigation and more horsepower at less MPG than the previous model.

I believe that the basic notion in your object rests on the assumption that any installation of a new product version must therefore encompass upgrading all other versions of the same product family. I have not had a single customer that works this way, or believes this – many have SQL 2000 and 2005 warehouse, ETL, etc systems with new development or edge cases being put on the newer platforms. This will be the same for Kilimanjaro, which will be heavily BI focused. Our customers will keep their 2000 and 2005 warehouses and plug the new SQL release into the mix as just one more piece in the architectural map.

There are several issues that the major-minor release cycle does bring up though, that would be worth exploring by your magazine:

1. Complexity in managing a very heterogeneous database environment, even with the products all coming from the same vendor
2. Feature set and Security – each product version (hopefully) increases security and features, but that will also be crippled by having older versions as part of the farm. I think it will be interesting to see how MS handles security and features for the new products while making it pluggable into a customer's existing grid

Of course I will follow this diatribe up with a reminder to myself and others that this is my opinion based on my experiences. I fully respect that everyone has the opportunity to see things from different angles, which is one reason why I am sharing mine. Again, thanks for the wonderful work on the magazine and I look forward to being a subscriber for some time to come!

January 13, 2009 20:12 by Sid
E-mail | Permalink | Comments (1) | Comment RSS

Analysis Services Tools

Happy New Year! I know it is a bit late, but this is the first post I have been able to produce thus far, so please forgive…

After many moons, I am backing to working on Analysis Services. As such, I am dusting off old tools and references, as well as building some new ones. I will be posting more on SSAS this month (as it is easiest to keep posting on what I get to work on), but for now, the tools and references:

1. Analysis Services Specific
   1. Script performance analyzer, basic, but it helps explode the details of the query for you
   2. Various bits and bobs posted by the user community, most notable to my needs being the Load Simulator
2. Performance related reading material on Analysis Services
   1. SQL Server Best Practices Article: Identifying and Resolving MDX Query Performance Bottlenecks in SQL Server 2005 Analysis Services
   2. SQL Customer Advisory Team blog post on SSAS performance tips (if you don't have their site bookmarked already, do it now)
   3. TechNet post here on OLAP Design Best Practices – design is key to performance
3. BI Tools in General:
   1. BIDS Helper: http://www.codeplex.com/bidshelper. I had heard this mentioned in passing, but after a customer showed it to me recently, I had to dig into it myself to really see how cool it is. Available for Visual Studio 2005 and 2008

There are tons more on CodePlex.com and in TechNet, but these are a few of my favorites.

Also, having burned through most of the MS Press books on Analysis Services 2005 (and not wanting to spend money yet on the 2008 glosses), I found the SAMS Publishing book, Microsoft SQL Server 2005 Analysis Services by Melomed, Gorbach, Berger and Bateman to be a fantastic reference, in addition to covering in depth subjects areas I have not yet mastered -- highly recommended for anyone who is pretty adept at SSAS, but wants some more detail. Great for beginners as well, though for extreme newbies, I would recommend the MS Press Analysis Services Step by Step as a primer to this book.

Amazon product link below:

January 12, 2009 22:17 by Sid
E-mail | Permalink | Comments (2) | Comment RSS