Most of us are tired of this overused, vague term. How many of you have clicked on a 'DBA' job posting only to find that it's not what you do? Or asked for a DBA resume from a recruiter and gotten something other than what you expected? Or how about interviewing someone for a DBA position and finding that the candidate is not even close to what you're looking for, but can still rightly call himself a DBA....?

I got an interesting mini-speech on this a couple of years back and I've always referred to it ever since.  I can't take credit for it...the credit goes to my friend Yitzhak Khabinsky, although I have embellished it somewhat.  Here is the "mini-speech":

"Many people refer to every database professional as a 'DBA'.  This is wrong.  The term is much too vague.  What really exists is 5 separate disciplines:

1. Data Modeler - these people work with Business Analysts and developers during the requirements and design stages of the Development Lifeycle.  They usually are (or should be) one of the first people to get the requirements from the business people and translate those requirements into a data model.  They are experts at creating data models and working with data modeling applications.  It goes without saying that they are experts in relational database design from a conceptual standpoint.  They don't necessarily meddle in any one specific database platform, since much of their work is in the Logical Design Phase and is therefore platform-agnostic.

2. SQL Developer - these are the SQL experts who usually code review all the SQL written by anyone in their organization and take on the biggest SQL challenges themselves.  They are usually tied to one or more specific platforms.  They know all the ins and outs of writing clean, performant, scalable SQL and all the pitfalls to avoid.  Many times they are the last line of defense when confronting some particularly hairy SQL that is slow or is causing problems.  They also are usually the ones who take over a project after the data modeler finishes his work and develop the SQL core of new product offerings.

3. DB Administrator - these are the professionals who often work inside the "cold rooms" and deal with the actual SQL Server hardware of their organization.  They manage backups, restores, tape libraries, creation and consolidation of SQL instances, SANs, and the like.  They usually get into programming in order to automate administrative functions, but are usually not involved in application programming.  When they get involved in performance tuning it's usually the type of tuning where they don't touch the code; they try to optimize performance by laying out the database properly on the disk subsystems, making sure enough memory is available, configuring servers properly, and performing proper maintenance on the database servers.

4. ETL Developer - this is similar to the SQL developer above, but it has taken a direction of its own with the proliferation of Data Warehousing and Business Intelligence.  These professionals are usually experts in one or more of the "ETL" applications (Ascential, Informatica, SSIS, etc), which go beyond the realm of SQL development.

5. Database Architect - this is "all of the above" or close to it.  These are very senior professionals with many years of experience and can lead
teams of other Database Professionals.  In spite of many claims to this level of professionalism, there are in fact very few of these professionals around.  These professionals also get into the internals of how the database engines work and are also usually interested in database research as well.  The main litmus test is that they possess most of the 4 other skills if not all.

Also, the above 5 disciplines only apply to the OLTP world (with the exception of the ETL developer who has one foot in OLTP and the other in BI).  There are 5 other similar disciplines that apply to the BI world (Dimensional Modeler, MDX developer, Administrator, ETL Developer, BI Architect)."

So, that's the 'mini-speech'.  You will find that if you use this model you will get a FAR better idea of what you're looking for in a DBA job if you're looking for work, or a DBA candidate if you're looking to hire.  When I interview people I usually start with this mini speech and then try to put the person into one of these categories.  I have found it to be very effective in hiring top-notch candidates.  Obviously, there is some overlap...most people fit into more than one category, but you get a FAR better idea of what the person is capable of by following this model.

 ...and that's my 2 cents....

SB