What makes an exceptional DBA? It depends on who you ask. In his book, How to become an Exceptional DBA, Brad McGehee gives his perspective on what it means to be a DBA, and the skills and traits that distinguish the exceptional DBA. It is the first time that anyone within the profession has spelled out in detail what the job really entails. The task isn't over, though. To be even clearer on the qualities that are required, we need to add in the consensus viewpoints of associated specialists, including developers, testers, architects, managers, and end-users.

A DBA's primary responsibility is the security, availability and performance of the company's databases, and the integrity of the data they contain. However, a DBA could get a tick in every one of these boxes, therefore making him exceptional in the eyes of other DBAs, but still fail to get peer approval from the developers he, or she, works with. The knowledge and skills of the DBA whose job it is to support a development team must extend beyond the database, and into the realm of the application architecture. It is the only way to appreciate the problems that developers face, and to be able to provide a solution that allows everyone to meet their obligations.

A DBA cannot afford to be too inflexible regarding opinion of the "right way" to architect an application. If the team is using nHibernate, for example, the DBA needs to understand how to reconcile the performance and security issues, rather than simply retreat into a state of entrenched opposition. This doesn't require mutant brainpower, but it does require patience and a willingness to listen, empathize, and to build trust within the team. Brad certainly covers this with his usual thoroughness but it would help to get the developer's view on this, because real-life development, inevitably, is never straightforward. According to one developer at Red Gate:

"There are a few times in my developer career where I can honestly say I received help from a DBA. Some DBAs are approachable, and more than willing to advise on problem queries, and show you clearly where you went wrong. However, I can count many more times when a DBA has been unapproachable and unhelpful - occasionally condescending and obstructive. How many times have I heard a DBA say "no" to a developer based on some vague "company policy issue" or on what he personally does and doesn't like to allow in his databases. Is it any wonder that developers stop listening to you or try to bypass you?"

So what, from a developer perspective, makes a DBA exceptional? Say, for example, a DBA realizes that a development policy will not scale up as required, or will not meet the security requirements in the business. How would an exceptional DBA handle this situation, and avoid it escalating into the usual state of guerilla warfare? How far should a DBA assist in the development of the application domain model? Should he, or she, get involved even in the User Interface, to ensure that the way that data is represented to the user is in line with the business's data model? Do developers see DBAs as merely providing a service in supporting a database whose schema is provided by the developers? It would be great to get your views. If you work with a DBA that offers your development team an exceptional level of support, then why not nominate him, or her, for the  Exceptional DBA Awards, to be awarded at this year's PASS summit?

Cheers,
Laila