This is a subject I’ve been thinking about for quite a while; perhaps others are drawing similar conclusions. I may even be late to the game, but if so I haven’t seen it discussed on the blogs or podcasts, and I keep up with these pretty regularly. After a lot of consideration, I’ve decided there is a new type of IT professional, the SQL Server Developer, of which I consider myself one.
Let’s start out with a basic definition. What is a SQL Server Developer? In my mind they fall into two categories. The first is the developer who works with the SQL Server Business Intelligence (SSBI) tools, namely SQL Server Integration Services (SSIS), SQL Server Reporting Services (SSRS), or SQL Server Analysis Services (SSAS). The second is the type of developer who works in the server end, developing stored procedures in both T-SQL and CLR, scripts, designing tables and views, and other tasks not centered on the day to day activities around the actual running of the Server itself. In many organizations these two areas are covered by the same person.
So what has caused this new breed of IT professional to emerge? Two reasons as I see it. First is the introduction of SQL Server 2005 itself. It brought along a new flood of tools, many outside the experiences of the typical DBA. The ability to write CLR inside the database is very new to DBAs, most of whom have no experience with .Net coding. Note this is in no way any sort of knock against DBAs, I would not expect one to have any experience with it. Likewise with many of the other tools.
The bigger reason though is Sarbanes Oxley. For a complete background see the Wikipedia article on Sarbanes Oxley, but in brief “SOX” is a US law that makes the leaders of publically held companies accountable for the financial dealings in their company. Auditors are responsible for ensuring compliance. As a result, most corporations have put in place rules in IT that place a wall between production systems and the developers who created those systems. In my own company’s environment, and those of many others I speak with, this means the DBAs are no longer allowed to develop code. No table designs, to stored procedures, etc. They are able to develop scripts if they are used in maintaining the health of the server; those are OK because financial decisions are not being made based on those scripts.
Somebody then, had to step in and fill the gap. In many companies since these were considered development tasks the coding fell to the development group. In other organizations DBAs were divided into production DBAs and development DBAs. In either case these folks are responsible for developing solutions to business issues, and are not responsible (at least not directly) for the day to day running of the server.
Now that you understand what a SQL Server Developer is and why they came into existence, you may be asking what the point of this article is? Well, I suppose it’s a plea of sorts. I see a lot of activities / training for both the DBA and the .Net pro, but little for the SS Dev. Even Tech-Ed this year demonstrated the schizophrenia when it split the event in two. There were just as many events in the Dev week as there were in the IT Pro week that applied to the SS Dev. Don’t get me wrong, I have seen training videos, mostly from Microsoft, that cover the technologies involved. But little that talk about the overall experiences that a SS Dev. In addition, almost every book I read assumes the reader comes from a DBA background. Doing so only covers half of the target audience; keep in mind there’s a lot of us who came from a .Net background.
So what would I like to see? Well to begin with, books that don’t assume everyone has the same background. Next I’d like to see more events targeted at the SQL Server Developer. Here in Birmingham we’re planning on a SQL Saturday next spring, I’d like to see many sessions devoted to the SS Dev. Finally, there seems to be very little software, outside the tools that ship from Microsoft, to assist the SS Dev. RedGate has some nice tools, and I’ve just started investigating the ApexSQL tools, most tools seem to target the DBA primarily though. It’d be nice to see collections and offerings more targeted at development.
What can you do? Well if you recognize yourself as a SQL Server Developer, start referring to yourself as such. Talk to Microsoft and vendors, start bringing the gap to them, ask them to start providing tools and events to cover our needs. Finally, evangelize! Do presentations, blog, whatever it takes to let the world know there’s a new breed of IT Professional out there.