|
I was recently talking with a group of Microsoft SQL Server MVPs and they all confirmed a phenomenon I have been seeing time and again. We discovered that we were all dealing with the fallout of this scenario in our own projects and had also seen it many times in the past. I call the scenario "The Involuntary DBA." This is the situation in which an IT project has no DBA to speak of.
It’s not surprising to me that small, mom-and-pop operations might implement an important application without having a DBA (typically more expensive and harder to find than developers) on staff. Instead of hiring a DBA, the team leader drafts one person, usually a canny and clever developer or perhaps a network administrator, to act as the DBA. But what’s troubling to me is that this also occurs even in many important and well-funded IT projects at major corporations.
While this keeps many expensive consultants and performance-tuning specialists happily employed, systems designed without a DBA have huge fundamental problems - performance, poor maintainability, very unhappy users. Yet these problems could easily be averted if the IT team had put a talented and professional DBA on the job at the inception of the project.
Why do companies continue to place important responsibilities on someone without the right skills when the risks are so obvious? And why don’t professional DBAs in the SQL Server world get the respect accorded to DBAs on other platforms such as Oracle and DB2?
I believe that the answer to both questions stems from Microsoft’s tireless devotion to the Visual Studio community. Yes, DBAs are more expensive than developers, but there’s more to it than that.
In many ways, Microsoft’s devotion to the Visual Studio community comes all the way from its top executives. Bill Gates, especially, was a code developer and still loves coding. Steve Ballmer, along with many senior vice-presidents, also seems to carry this bias. When you compare the marketing from each of the top business units within Microsoft, you can quickly see that SQL Server, despite being the third largest revenue-producing unit in the company, is strongly overshadowed by Visual Studio. Visual Studio has more magazines devoted to it, more Web sites about it, more bloggers babbling about it, and so forth. With so much visible and vocal support for Visual Studio and veiled apathy for SQL Server, it’s easy to see why IT project managers feel like their smartest developers are able to handle the task.
Meanwhile, Microsoft’s own features in SQL Server seem to erode the role of the DBA. Inclusion of code-based features like LINQ and the Common Language Runtime (CLR) which allows developers and DBAs to write stored procedures in .NET languages, while not negating the importance of DBAs, certainly reduces the areas of the database platform over which the DBA has undisputed authority. One could debate that these features offer useful ways to expand the integration of Visual Studio and SQL Server, but many DBAs would rather turn these features off instead of being forced into maintaining code they can’t understand or debug. And of course, many other shops decide whether or not to use these features without the advice of a DBA at all.
Today, IT operations that consider the DBA as a “nice to have” rather than a “must have” feel the pain of that decision in poorly performing applications that are difficult to implement, hard to use, and even harder to maintain. But until Microsoft treats the DBA position as an equal player in the application development process, developers and network administrators can expect to be pressed into service as the involuntary DBA.
About the Author:
Kevin Kline is the technical strategy manager for SQL Server Solutions at Quest Software. A Microsoft SQL Server MVP, he is a founding board member of PASS and the author of several books, including SQL in a Nutshell (O’Reilly & Associates). Kline is a top-rated speaker at industry trade shows and has been active in the IT industry since 1986. For more information about Quest Software, go to www.quest.com.
|