Chris Miller Blog

RocketScientist's Miscellaneous Ramblings

What's the deal with SQL Server 2008 implementation?

What's the deal with SQL Server 2008 implementation?

I was talking with a Microsoft representative at PASS and he asked me about our SQL Server 2008 implementation plan.

"I don't have one."

"Why not?" astonished look.

"It's up to my ISV's to certify their applications, and they're not doing it.  I have software on SQL Server 2000 still, the ISV's aren't upgrading it and won't support it if I upgrade."

Another astonished look.

"So what can we do to fix that?" he asked.

"I don't know."

I didn't know then, I have a few ideas now.

The problem is that the people who write software that work with SQL Server and then sell that software (I'm not talking about things like SQLBackup or Hypebac.  I'm talking about ERP systems, line-of-business systems, and so on) don't have incentive to certify that their applications work against the new SQL Server versions, that they don't have the QA resources to do the certification, and they don't make any money providing us with an upgrade because it's not a major release for them.

That's a problem.  That's why I still have about a half dozen SQL Server 2000 boxes, and exactly 0 Sql Server 2008 implementations.

What's the solution?

Automated QA.  Which has its own set of problems, the chief among which is that the licensing is EXTREMELY expensive.  Like "Go buy yourself a nice car.  Italian car.  The kind that gets to kick off Top Gear every week."  That expensive.

And that's outside the reach of ISV's.  They drive nice Hondas, not supercars.

So, how do we fix that?  Well, the Automated QA vendors I've worked with in the past have had a business model of selling a few really expensive licenses to very large companies.  This keeps the marketing costs low (smaller number of CIO's to take to golf outings), the support costs low (when you only sell a few licenses it limits the number of simultaneous calls you can get) and keeps the software out of the hands of a lot of people who really need it.

This is a situation Microsoft has been in (and been victorious in) before.  IBM had the same business model with their mainframes.  Oracle had (still has) the same model for selling thier DBMS.  In nearly every market with this business model in the personal computing space, Microsoft has built a product, sold it at a reasonable cost, and forced the existing market leaders to rethink their strategy or perish.  And made italian supercar level money by selling to hundreds of customers instead of a dozen.

So, if Microsoft wants to increase SQL Server 2008 licenses, they need to enter the automated software QA space.  Then start applying pressure to ISV's to adopt automated testing procedures with Microsoft software, because it'll reduce their costs without breaking the bank.  The pressure doesn't need to be negative pressure, more of "hey, here, have a huge discount on this software if you'll implement it," or "This is part of your Partner-level benefits."  Build a great product, support it, and sell it.  The big vendors in this space can already show a good ROI, if the initial cost of entry was drastically reduced then the ROI would be even bigger.

The ISV's build testing scripts for their applications so they can test all their minor changes.  Then along comes a new version of SQL Server, and the certification process is "run the same script we do for a bug fix, just point it at a SQL Server 2008 box".   It certifies, or it has a few little glitches that get cleaned up, and the product ships.  Way cheaper and faster.

Then the ISV's are happy because they've got better software from having better processes, Microsoft is happy because the ISV's are making better stuff, they get to sell more boxes of software, and people will start upgrading their back office components, and finally the folks like me are happy because we get to consolidate some versions together more quickly.

Faster please.

Legacy Comments

Charlie Maitland
re: What's the deal with SQL Server 2008 implementation?
This reminds me of a conversation I have at Convergence a couple of years back.
I was in discussion with one of the SQL people and she asked me "how do we sell more SQL Licenses?" My response was "you don't sell SQL to companies you sell applications to companies". This seemed to be a surprise to her. I explained that very few companies buy SQL as a product in it's own right they buy an application that will solve a business need and if that means they need SQL then so be it.
So your point about ISVs is spot on but this inertia goes right to the top of the ISV chain with larger vendors such as ERP suppliers being some of the worst offenders.

re: What's the deal with SQL Server 2008 implementation?
It might help if Microsoft would quit releasing a new version of SQL Server every five minutes. Here we are in year 2009, moving slowly and painfully to the "brand new" SQL Server 2005, barely looking at SQL Server 2008. And for that matter, quit naming the damned products after the year. The "code name" is almost always a cooler name, and doesn't convey immediate obsolescence.

re: What's the deal with SQL Server 2008 implementation?
Well, I can see your point Slappy, but...

Here's the problem. They have to release the new features. The feature list in 2008 is very long and includes some very important things (MERGE, just to name one). And holding those things up when they're done kinda sucks.

The resolution would be to offer those as addons in feature packs, but that extends Microsoft's testing and support problems, and eventually would wind you up with a less reliable product.

Three years is a reasonable product relase cycle. I think that to keep up feature-wise with the competitors they'll need to keep that kind of pace. Which means the ISV's need to pick up their pace and speed their cycle times. They just don't have the tools to do that.

Log Buffer
re: What's the deal with SQL Server 2008 implementation?
"What’s the deal with SQL Server 2008 implementation?. 'I was talking with a Microsoft representative at PASS and he asked me about our SQL Server 2008 implementation plan. [...]"

Log Buffer #143