With the release of SQL Server 2005, Microsoft is creating a value proposition for customers by integrating that product and Visual Studio (VS) 2005 to address the needs of developers, IT pros, and end users and help them work better together. "Better together" is a key message behind the joint launch of these products. I interviewed Microsoft vice presidents Paul Flessner (senior vice president, server applications, including SQL Server) and S. Somasegar (corporate vice president, developer division, including VS) to get their inside perspective on the better together strategy and what it means to customers. (To learn more about which features in the new releases are Flessner and Somasegar's favorites, see the Web-exclusive sidebar "Favorite Features," http://www.sqlmag.com, InstantDoc ID 47877.)
Stitching the Strategy
KF: What drove the better together strategy?
Somasegar: In the past, we thought of the developer world and the data world as two different worlds. Then we came to the conclusion that data and applications go hand in hand. If you don't have an application that does something meaningful with data, I don't know what you do with data.
Integrating the Common Language Runtime (CLR) into SQL Server is a huge step forward in bringing these two worlds together. We can now bring database developers the flexibility and productivity gains that we've always had for application developers in VS. If you're writing a data-driven application, you'll love this integration.
KF: So you're stitching together the developer and database tools instead of assuming customers will do the work?
Somasegar: Customers expect us to do the stitching; they don't want to do the stitching themselves. They say, "You're giving us different products—make sure they work together; tell us how we should use them together. If all you're going to give me is different products and you let me do the stitching, I can go to Microsoft, or I can go to five different vendors." Better together is the value proposition that Microsoft provides.
Behind Schedule
KF: Microsoft has been criticized for taking so long to finish SQL Server 2005. Your message is that integration is the value proposition for this launch, but did the integration contribute to the delay?
Flessner: It really did. It was hard to get the CLR into the server. We had to do a lot of framing around that: the memory management, supportability, and performance. We did huge amounts of work on the integration of Visual Studio IDE and the whole debugger experience. Then we had \[the\] Slammer \[worm\] in the middle of development. We took 6 months to address security.
I'll take heat in this release—that I could have shipped this thing 6 months ago—and I don't even care. I feel so deeply that the product has to be ready for prime time when we ship it. If you think about it, Service Pack 1 (SP1) is baked in. Microsoft has had criticisms before that we finally get it right by Version 3, and people are supposed to wait for SP1 to put a new release in production. Uh-uh. Look—SQL Server 2005 is running this entire company \[Microsoft\] and companies all over the world today. I'm proud of that.
This morning, I was upstairs having an email conversation: The field wants 100 more go-live licenses because there's so much customer demand to put SQL Server 2005 into production. The demand is so strong now that I know the release is ready, and that feels good.
KF: You mentioned that security affected the schedule. Were other changes in technology and the industry factors in the delay?
Flessner: No, we didn't keep adding features. Some things are timeless: supporting developers, supporting the abilities, and supporting information workers. It wasn't that we kept adding. The problems we bit into were hard, and the dependencies were hard.
The VS team had a release called Everett, which slowed us down. We had hoped to ship SQL Server with Everett, but we couldn't. That was a decision around the Windows business, and it was the right decision for the company.
Are VS and SQL Server tied forever, and will the next release be slow again? We'll depend on VS technology, but my plan is to take their shipping bits and include them, so I don't have to wait. I plan to go right back to 24-month shipping cycles.
KF: Are you talking about the same approach the Windows Server Division has announced? They'll have a major release every 2 years and then a minor release 2 years later.
Flessner: No. I'm back on an every-24-months release cycle. That's my plan right now, but that can change.
Somasegar: I think for VS, for SQL Server, all of us—we absolutely want to get to an 18-to-24-months cadence. The challenge is that not everything we develop can start and end in 18 to 24 months. Some releases will take 48 months; others might take 16 months. So we need to figure out how to structure our R&D.
KF: WinFS generated a lot of excitement and then had to be dropped from this release. Did WinFS play a role in the schedule?
Flessner: It had some impact, but it also had positive impact. We put a lot of super strong engineers on WinFS, and they pushed us to include certain features. For example, the WinFS guys pushed support for User Defined Types (UDTs). But overall, I think the biggest factor in the delay was the connection with VS.
KF: One new aspect of the schedule for this release was moving to the Community Technology Preview (CTP) model instead of a beta program. Is CTP the future for Microsoft products?
Somasegar: I wouldn't say I'm moving away from beta to CTP. My dream is to include customers at every step. Every build that comes out of my main build lab is released to my division of developers to test. There's no reason why I shouldn't share every build with my community. I feel super good about being able to do that once every 6 weeks. How can I get builds to customers every 5 weeks, every 4 1/2 weeks, every 3 weeks? That's sort of the goal that we're marching toward. So in that scenario, the line between what is a beta and what isn't gets blurred.
The reason we do betas is to tell customers that this is a build we've added a bunch of functionality to. Give us feedback on whether we're headed in the right direction, whether the right quality level is there. If we can provide builds more often, do we call it a beta or not? Then it becomes a program for getting feedback.
KF: I see the value of continuous feedback. But betas are a way for customers to measure your progress. Do you think customers like betas as milestones that help them judge where you are with the code?
Somasegar: I don't think we've decided we'll never ship betas any more. We need to be descriptive and say, 'This build is fresh from the oven. Go try it,' or 'This build is good enough to deploy in production, and we're going to stand behind that.' That distinction needs to be there. We may call one build a CTP and another one a beta.
Competitive Issues
KF: What's your message to the competition with this release?
Flessner: The "nowhere to run, nowhere to hide" message to Oracle and IBM should be loud and clear. We have the mission-critical abilities. We have a superior developer productivity story. We have a far better BI story. On the low end, we have \[SQL Server 2005\] Workgroup \[Edition\] and \[SQL Server 2005\] Express \[Edition\], which we beefed up and really integrated with the tools. We're going to flex our muscle at both ends of the market.
We're selling more units than the other guys combined. We're also outselling them now in the enterprise in terms of units. It's frustrating for us to see Oracle and IBM using revenue to define market share for this industry. It's really not the right measure. It only shows they can charge more and get away with it. I'm about to prove that strategy is a big mistake for them because I believe we have all the capabilities that they have and more at a fundamentally differentiated price point. I want to get that message out there.
I've been quiet in terms of the competition. I thought: We just need to demonstrate quiet competence in execution. But you know, I've had it. They sell at dramatically higher prices with less functionality, and I'm going to make that clear to the consumer and the industry. We're going to punch pretty hard. We're going to offer an Oracle conversion kit and if IBM gets enough market share, I'll do an IBM conversion kit and we'll just keep slugging.
Better Together Benefits
KF: What would you say are the benefits of the better together strategy?
Somasegar: I think people care about three things: 1) business insight so information workers can get the necessary information; 2) productivity so developers can get more done more efficiently; and 3) a secure, reliable infrastructure for the IT pro to run mission-critical applications. If we can deliver on these three things, I feel that we're delivering on our promise of connected systems, and we're moving the bar in a big, big way.
