Changing Role of the DBA
Continuing with this series I wanted to share some thoughts about how development of databases has changed over time. Prior to my transition to Agile software development I worked with DBA teams as a side group. This team worked with both operations and software development.
Working with operations we were responsible to keep all systems running. Working with development we were responsible for all database schema changes and code that was deployed outside a developer’s sandbox. We were the final approval of all things database. This was pretty much the case if you were using Oracle, DB2 or SQL Server.
We had tools for modeling databases, performing version control, monitoring performance, disaster recovery, and managing deployments. That world still exists today and is effective in environments where waterfall development processes are used. It is also often important when there are shared systems on which the database operates, competing for resources.
Some companies moving towards agile processes have taken that group and split it into two entities. The operations entity keeps the lights on and assures adequate resources on each system where the databases live. They are responsible for disaster recovery, security and all that wonderful stuff. These individuals don’t necessarily require the best skills in the SQL language or database design techniques.
The other half of the DBA team is often greatly reduced to one or two individuals. To supplement the loss of DBA resources developers are mentored to perform many database development tasks. Also, a topic to consider tomorrow, much of the CRUD activity has been removed from database code and extracted into a Data Access Layer. This results in a more lightweight database that simply serves data.
With the reduction in requirements on the database engine a single DBA can support a large team of smart developers all by themselves.
I am not saying either one of these processes is better than the other. Personally, I love Agile techniques. But I wouldn’t say it is superior to a team of DBAs using a Waterfall process. Waterfall can definitely scale to a lot larger team size.
Stephen shares some thoughts about working without access to production systems he supports:
I am a developer, both of .Net and T-Sql and have been working on ‘system’ since I created it back in 2000. When I brought up the ‘system’ up the DBA were only worried about Oracle, not thinking that SQL Server would ever be want it has become today. So they didn’t worry about developers bringing systems up on SQL Server and they didn’t even offer any assistance. So I had to learn to do all the “DBA Roles” necessary to get the ‘system’ working, and they have been good for twelve years and I have not needed any DBA’s.
As far as security, I am a good government worker that is not looking for riches and being a developer just wants to have people use the system that I put up. I am not like many other people that don’t care and wants to get more “MONEY”; I guess for “MONEY” sake. My greatest goal is for the ‘system’ that I have created to be used by my customers for as long as necessary.
I don’t like the operations people who want to cut me off from my database and code in production. The policy is that any individual familiar with production code should not have access to production resources is not creditable to me.
I hope this segment of the changing role of the DBA has been interesting to you. If so, and you would like to share your thoughts, send them in to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured White Paper(s)
Top 10 Tips for Optimizing SQL Server Performance
read more)