Apress - Accelerated SQL Server 2008

Before I describe the contents of this book and why I think you should just take it over to the counter and buy it, I would like to give you an insider’s look at the SQL Server 2008 product development cycle. I believe this insight will provide you with a deeper understanding of how SQL Server is continuing to evolve. The rest of this book will show you why SQL Server is enterprise-ready. For the past 5 years, I was a program manager at Microsoft in the SQL Server product unit. During this time, I owned various features within the product, including SQL Server Agent, SQL Server Express, and most recently, database security.

When I joined SQL Server in 2002, the product team was in year 3 of planning and implementing the Yukon (SQL Server 2005) release. One of my first responsibilities was to own the Create Database/ Database Properties dialog in SQL Server Management Studio. After working with the user interface (UI) design team and various UI developers, we crafted the interesting grid-based dialog that you see today in Management Studio. However, arriving at the implemented Create Database dialog was not as straightforward as we wanted.

In our organization, we had separate teams writing the UI, writing the Server Management Objects (SMO) code to support the UI, and writing the code in the database engine itself. One of the more common issues we faced was the orchestration of the three separate teams working on a particular feature. Each of the three teams didn’t necessarily put the same priority on the work, and this resulted in situations like having a UI that did nothing because either the SMO or database team didn’t write the code to support it at the time. In the end, when it came time to ship the product, there were some features that had no UI support in SQL Server Management Studio. For example, try to manage Service Broker in Management Studio in SQL Server 2005. I will save you the time— there isn’t much there.

So why am I airing our dirty laundry? Well, it’s not because I want everyone to enjoy the smell. It’s because I want to tell you about the dramatic improvements in efficiency that have been made, resulting in a better product for you, the SQL Server customer.

With respect to our software development issues, the upper management in the SQL Server product unit actually cared about the problems people in the product team experienced. When SQL Server 2005 was released, the management set aside a bunch of folks, locked them away (not literally), and had them come up with solutions to the problems. What came as a result was called the SQL Engineering System (SES), which has fundamentally changed the way Microsoft develops SQL Server.

As with other versions of the product, we started with the core themes of the release. In SQL Server 2008’s case, these were as follows: mission-critical platform, dynamic development, beyond relational data, and pervasive business insight. These were not just marketing buzzwords, but actually meant something in the SES process. Then another, smaller group came up with scenarios that matched each of these themes. One of the scenarios I was involved with was “secure platform for data.” This scenario dealt with issues around data protection. As program managers, we helped define the various improvements that would support this scenario. My specific assignments were the securityrelated improvements, such as transparent database encryption, Extensible Key Management, and auditing improvements. So, everything we did in the product boiled down to an improvement based on a scenario that was part of a major theme. This kept everyone focused on the common goals for the release.