The Development DBA role, though not as common as the more prominent DBA and Database Developer roles in the database space, has its place too - and I think is likely to become more popular as things evolve. What is the Development DBA role? One could argue that it's at the intersection/overlap between the DBA and Database Developer roles.
Job postings have looked for "Development DBAs" for some time. Below is a graph describing the growth of the roles afore mentioned.
The dynamic chart, at the time of this writing shows job posting activity clear back to July 2005 including the three roles: Development DBA, DBA and Database Developer. In the last couple of years (2009, 2010), both Development DBA and Database Developer roles have seen between 25% and 75% growth.
Mind you, the job posting data shows part of the story. There are additional shops that utilize a Development DBA role - just not an exclusive new hire for that position. That was the case when I took on said role - a role which I came to enjoy.
Now in absolute terms, the DBA and Database Developer roles are far more common - indicating that the Development DBA role is more of a specialty role. That said, I'd like to discuss the basic ecosystem as I understand it where this intriguing role belongs and share some of my experience with it.
Regarding ecosystem, the role in question is useful in places where a fair amount of database development goes on where project safety and organization can be improved by assigning this role, thereby allowing the other roles (DBA and Database Developer) a higher degree of focus.
A DBA that's strong in the programmability space or a Database Developer with adequate DBA training can potentially switch into this role on demand if the project doesn't call for a dedicated resource to the role. However, some of the activity that I think belongs to this role such as preparing deployment scripts and preparing test data can be considered specialty crafts not unlike the performance tuning specialty which takes some time to grow into and perfect - hence the demand for consulting services surrounding some of these specialties. The Development DBA role is especially critical leading up to deployment as this role is likely to be directly or heavily involved in the deployment process.
With that, I'll segue into some of the duties and responsibilities that I covered while in this role and that I think could reasonably be assigned to this role.
- Administer source control of production schemas and development schemas.
- Administer versioning of schemas.
- Provide administration of development, testing and staging servers.
- Monitor and troubleshoot development, testing and staging servers for deadlocks, performance issues and resource issues.
- Responsible for refreshing schemas and datasets for development, testing and staging (using backup for copy and other techniques).
- Prepare test datasets including redacting live data or using data generation tools.
- Prepare deployment scripts and producing deployment plans.
- Prepare rollback scripts and producing rollback plans.
- Run schema and data comparisons.
- Create unit tests for stored procedures including set-up and tear-down operations for continuous testing and integration.
- Performance tune queries and offer expertise on set-based operations.
- Offer consulting on optimal architecture and data models.
- Perform business requirement analysis, project management, support and other duties consistent with this level of responsibility.
- Create and manage schema documentation and other technical artifacts relating to development.
In general terms, the database development and testing space can quickly become disorganized and a threat to ongoing progress. Many horror stories have been told. The Development DBA role can take charge of this space and bring order to the chaos. There is power in remaining organized and staying consistent. If there is any question about who'se responsibility it is to make sure that happens in development, testing and staging environments, then the role in question might be a good fit.
In more specific terms, I've suggested that there are some specialty tasks involved in database development that someone with a lot of experience preparing changes for production offer additional expertise. For instance, there's the craft of preparing deployment plans and deployment scripts.
The production environment is often like a train that must keep on going while adjustments are made. Often the sequence of events matter. So, a plan needs to be made that lines up the sequence of events that will allow all the adjustments to be made given the various and often complex dependencies and relationships between objects and flow of operations. To stay in the safety zone, changes should be arranged so that they can be deployed with the minimum down time and minimum impact. Often the preferred analogy is a precise surgical procedure rather than a medieval hack. That said, there are often tools of the trade such as Visual Studio comparison tools or the Redgate SQL Compare or Data Compare tools that a practitioner of these operations should be able to leverage to maximum advantage which requires requisite experience.
It is often a good idea to have a rolllback plan in order to have contingency coverage should the need arise to undo changes made to production. This Development DBA can meet this need. Once again, the sequence of events is critical to the success of a rollback. If a rollback is successfully applied to production, bringing the environment back pre-change deployment status, this can often curtail the need to take more invasive measures such as restore from backup.
An often time-consuming and periodic need is set-up and tear-down of development and testing environments. This can be handled by the Development DBA role. The role can take charge of removing objects that are no longer needed, keeping the environments organized. The role can put new databases and objects into place and add rows needed to make everything work. Often there's a momentum to this type of thing. The person doing environment set-up and tear-down often needs to acquire and retain substantial knowledge of the changes being made, business logic and the inner workings of the system. For instance, there may be seed rows needed in certain tables for a new environment to work right. Or, the testing and development might need a certain set of test data in order to cover objectives. Assigning a particular person to do this may be the most effective way to handle the need.
It might help to compare, contrast and find the rough boundaries between the three DBA, Database Developer and Development DBA roles - or at least make a sketch.
Someone assigned to the Development DBA role could certainly be involved in the database development efforts, perhaps at a senior level, handling some of the aforementioned operations in order to keep dedicated developers efficiently focused on some of the other programmability tasks they will likely work on in a project such as writing stored procedures and user defined functions. The role might ensure that set-based operations are put into place when possible versus a more procedural approach sometimes taken due to less experience. The role might involve more advanced performance tuning and testing efforts.
With regard to the DBA role, a DBA who is versed in programmability may very well be able to handle all the aforementioned prospective duties of the Development DBA role - but perhaps she'd be able to do her job better of some of these duties were offloaded to the specialty role. That way, the DBA can focus on some of the non-programmability askpects of their job such handling the ongoing administration and maintenance of production environments, monitoring, administering for high availability, planning for disaster recovery, and so forth and so on.
That said, personnel assigned to the Development DBA role may not necessarily need to know how to do clustering, mirroring, design of storage subsystems, and so forth.
Anyhow, that I hope will offer a quick sketch.
Having served in the Development DBA role myself and having seen the role play an efficacious part of ongoing database development efforts, I can say that I'm a big fan of the role and I see a growing need for it in the future.