I find the term DBA to cover too much and describe too little. More and more we find that the responsibilities of a DBA, as we conceived the term 15 to 20 years ago, are divided among 2 or more persons. Commonly, these persons specialize in a particular aspect of the DBA tasks: Data design, ETL, SQL development, support, etc.
I would like to propose that the concept of a DBA be divided at least in 2 major areas:
- Development and design
- Support
These two roles are becoming very different. The person in charge of support does not need to know how the database and associated applications work and how they interact with the business (although it doesn’t hurt). His primary concern should be to keep the database up and running and to secure the availability of backups, for disaster recovery or regulatory purposes. He should be very involved in the design and construction of a DRP and a BCP.
On the other hand, the person in charge of design/development should be very much involved with the business. He or she should participate in strategy meetings, in order to better design the data structures to accommodate for future developments in the company. He or she should know, for example, if the company is changing from dealing primarily with other businesses to dealing with the general public. This person should always be learning about the new developments in the development language (T-SQL, PL-SQL, etc.).
There are some areas that will require the participation of both these areas, for example:
- Performance tuning. This activity requires skills both from the support and the development teams.
- Developing a Best Practices document. Ideally, every company should have a Best Practices for SQL Development document, describing the naming conventions, coding practices, security considerations, etc. This document should be co-written by both areas.
There are some companies where these two concepts are part of the culture, but I think we, as a community, should try to make them more universally accepted.
