Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

What's a 'DBA'?

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

Comments

Posted by Steve Jones on 13 May 2009

Report Writer as well, I've seen people hired just to write reports in SSRS or another tool.

Posted by Wesley Brown on 13 May 2009

I've always preferred fall guy....

Posted by Sam Bendayan on 13 May 2009

I've always seen Report Writers as similar to Application Developers, since they deal with front end user-interfacing work, and that's why I didn't include them in the list.  I guess I see a DBAs role as being in the back-end, not the front-end...that's why ETL Developers are in the list, but not Report Writers.  Many DBAs can write reports, but I don't see that as part of their core functionality...but that's just my opinion...I wonder what the majority of DBAs out there think about this...?

As far as 'fall guy' is concerned, I see that as part of the core functionality of all 5 types in the list :-)

Posted by bobbyfrederick on 14 May 2009

Well written...

Posted by Omoba on 14 May 2009

great job with the mini speech Sam. it does put things into perspective, would you mind if i print it out and and show it to some employers who advertise for a 'DBA', but require someone to cover 4 or all the disciplines in the OLTP world and a couple of the disciplines in the BI world?

the general/'corporate' public need to be educated on this distinctions.

Posted by Jerry Sommerville on 14 May 2009

Here!  Here!  In the past, I have been mistaken as a "DBA" many times even though I might be primarily involved in any one of the 5 different disciplines.  This problem goes back as far as I can remember when I started in this business nearly 30 years ago.  I agree with Sam also in that there are VERY few true Architech's walking around because it requires a deep interest in all things OLTP and active involvement in most if not all of the areas he mentions.

Posted by shawn.calderon on 14 May 2009

DBAs need to compile data to make decisions on a daily basis.  This compilation of data can be called a report.  You frequently need a "front end" report to make good "back end" decisions...my 2 cents.

Posted by Tim MacKay on 14 May 2009

I also think Report Writers should be included. To include them with the SQL Developer group is not a proper alignment of the skill sets required for each task. To "require" a SQL Developer or DBA to write reports is the wrong approach and does not put the proper emphasis on the Reporting skill sets. Additionally, most SQL Developers or DBAs look at being assigned the reporting task as some type of junior role or punishment.

Maybe Reporting is better defined in the BI side? What are the breakdowns of those roles?

Posted by David Jackson on 14 May 2009

1. Data Modeler – Got that T-shirt.

2. SQL Developer – Yep, wore that hat too.

3. DB Administrator – a must for anyone who calls themselves a DBA in my book.  You might delegate these tasks to someone in the team, but you must know how.  And when the proverbial hits the fan you must be an expert on using DBCC to recover, because you know they will be asking.

4. ETL Developer – My current position.  As well as a part time role in my last two jobs.

5. Database Architect – Ditto.

Posted by Howard Perry on 14 May 2009

I agree with the "mini speech", but people need to remember that once-upon-a-time many of these roles were performed by a single person.

In my past developers did physical table design and wrote the code in 3 or 4 GLs including SQL or other query language.   Then the programmers handed tables over to DB admins for laying out physical design on disk and doing backups etc.  Here is when questions were asked about data volumes, load balancing.   If program performance was slow, fixing it would be the DB Administrator's problem, so he/she would need to understand programming as well as query languages.    DBA might also be a sysadmin with system privileges but a sysadmin who was also a DBA, was extremely rare.  A sysadmin once told me she thought of DBA as a "black art".

Perhaps I would qualify as a "Database Architect" under the definitions above, but that really sounds like a data modeller.

DB administrator and Database Architect are incidentally also easily abbreviated to DBA.

Posted by jeff_m_sparrow on 14 May 2009

great job descriptions in recognizing the different disciplines employers should look at in data management

...and Wesley Brown has the other term for "generic dba" correct

Posted by Ed Roberts on 14 May 2009

SB,

I think your opinion of developers needs a little expansion. In my world developers' work includes #1 and #2 above.

Posted by rgriffin on 14 May 2009

Great breakdown and I agree with the descriptions.  Here's the business problem.  As a manager or business owner I can't afford to hire those 5 people.  I only have budget to hire one database generalist.  If I am a smart manager, well versed in the IS world, I will hire a database generalist and allow him some budget for consulting help in these specialties.  A very few large companies maybe able to hire for these specific skillsets, but they are the exception rather than the rule.  For the vast majority of us (consultants excluded) we will continue to have five hats hanging on our wall and be willing to put on a different hat as needs arise.  I like this article and will use it in the future to help me justify asking for consulting help.  One person can't be an expert in everything database related.  You've got to have a support network.  And you have to have great sites like sqlservercentral.com to fill in the gaps.  

Posted by David Fulton on 14 May 2009

Steve,

Thank you very much for publishing this!  

I am still trying to figure where I fit in with all of this DB stuff, so this helps me a bit.  Right now, I am actually a PM.  My company hired me for my experience as a user of our type of DB products and basic knowledge of DB and SQL code, which I learned so that I could query the DB and perform data analysis.  The company gets my experience as a user and I am learning to manage DB projects.

The part that I enjoy the most is working with our data conversions.  This involves reviewing and trouble-shooting our data maps, writing queries against the data and performing data analysis.  I actually enjoy writing code and get a feeling of satisfaction when it performs properly and I get the data that I need.  I'm still not quite sure where that puts me in the grand scheme of things though.

Any recommendations for finding my place would be appreciated and thank you again for publishing this

Best regards,

Dave Fulton

Posted by Ed Roberts on 14 May 2009

SB,

I think your opinion of developers needs a little expansion. In my world developers' work includes #1 and #2 above.

Posted by Mark Cooper on 14 May 2009

SB,

As the years have gone by, the definition of DBA has changed considerably. It did use to mean "the person that does whatever needs to be done to/with the database". Today, just because a programmer develops a procedure or function they call themselves DBA's. It's almost to the point where DBA means Do 'Bout Anything.

According to your definitions, I am a Database Architect. I have done it all and still do it all. AND I LIKE IT!

I was recently forced to find new employment. I am fortunate to have had the experience in all phases of database work. I was out of work for 16 days. Damn lucky in these troubled times. I believe I was hired because of my vast skill set. But even more important was my attitude.

In order to be a good DBAnything you must have the attitude (it's never listed in job requirements). Not just an attitude, but one that includes respect and responsibility, determination and drive, and a massive desire to succeed. You must know going in that your nights and weekends are no longer yours. They now belong to the database.

The other day I was approached by a user asking "Since your a DBA, can you fix my Access database?". MPO: you cannot fix an Access database.

I must get back to my DBAllOfIt work.

Driven,

Mark Cooper

Posted by doohickeyjones on 14 May 2009

I'm with rgriffin in that I'm usually the one and only database guy, and often also the network guy, application guy, etc. It's part of the Perils of being in the realm of Small to Medium Business I.T.

I'd love to be somewhere where I only had to fulfill one of those roles on a regular basis. Even two would be nice.

Posted by doohickeyjones on 14 May 2009

Meh, somehow hit post before I finished.

I especially agree with rgriffin in that it is key for us to have a good support network. This site has saved my bacon more than a few times, and seems prescient in its ability to come up with articles that address the very issue currently causing me grief.

Posted by purplebirky on 14 May 2009

I also preform many of these roles as I have the most knowledge at my company (and i am still learning all the time). I had thaought that everything i was doing was all part of the same role. Thanks for the insight on the diffrent roles.

Posted by rwachalovsky on 14 May 2009

rgriffin made the point. Small to mid-sized businesses have a need for all - including the report writing! - but not the money nor actually the need to have them all staffed with a full-time employee. (Webmaster is another of these catch-all IT professions.) Look at DB Admin - if I only have a couple of SQL Servers with 6  or 7 databases, nobody needs a full-time Administrator for that! I sense a certain snobbish attitude here looking down at the "generalist" - but there are (in my opinion) much more places who need this generalist than the highly specialized expert.

Posted by Grandmere on 14 May 2009

In a large company, the tasks/disciplines are often divided among the DBAs, in a small company, one (or two) DBA usually handles all five disciplines.

Great article.

Posted by Adam Pittman on 14 May 2009

Thanks for the enlightening article.  Being relatively new to this field (read: "I have my BA in Theater Arts"), it is helpful to come across such a well-defined map of the terrain.

For those of you who complain about wearing several hats, about offering your nights and weekends as sacrifices to the database god: what is keeping you from saying no to this diffusion of your responsibilities and thieving of your personal time?  This is not a rhetorical question, I am actually curious.  I find myself stretched out over several domains (I do #s 1 and 2 above, front-end development, and am taking the lead on a complete overhaul of our website), but I attribute my situation to the fact that I work for a non-profit organization.  Is the situation equally grim in the corporate world?  And have any of you thought about starting-up a company to cover one or more of the several functions mentioned in the article, allowing companies to outsource their database development needs to you?  Again, these are just sincere questions.

Posted by MICHAEL on 14 May 2009

Yeah SB, I definitely see a need for a distinct Report Writer. Each sub-unit of database management (Reports, Analytics, Business Intelligence, Physical database-specific, etc.) should get its own distinction.

Beyond that, I might also add the Database Apprentice position where you have to do it all (and should) in order to be generally useful to small and medium-sized businesses.

In general though, a great article. Now if only we could guarantee every headhunter would read it!

Posted by Sadequl Hussain on 14 May 2009

I guess work of DBAs can vary greatly from organisation to organisation. What Sam said is correct, but sometimes DBAs are asked to write, troubleshoot developer written code - particularly if the organiation is running on tight budget. I believe the following are core tasks of DBAs:

a) Installing, configuring database servers - the DBA works closely with infrastructure personnel and project managers and business stakeholders in specifying database server design. When the hardware is ready, the DBA installs and configures the software.

b) Backup - both implementing new and troubleshotting existing scheduled backups. Also restore on ad-hoc basis (e.g. refreshing UAT enironment), etc.

c) Security - maintaining, monitoring and implementing.

d) Data migration and upgrade - the DBA is uually part of a bigger team. Again, this can range from server specs to final migration of databases.

e) Troubleshooting performance issues - where you go through all DMV/DMFs, looking at execution plans, running profilers, running perfmon etc.

f) General day-to-day operations like checking backups, looking for failed jobs, watching for errors in event logs and error logs etc.

Posted by Duke Ganote on 14 May 2009

Interesting that Phil Factor himself, at an obviously big company, was a DBA-ReportWriter!

www.simple-talk.com/.../73310.aspx

Posted by romina on 14 May 2009

Sam, where can I get more information on the 5 disciplines that apply to the BI world? I would very much appreciate it if you could point me to the right direction.

Cheers

Romina

Posted by Ronzo on 14 May 2009

So where do skills like replication, patitioning, multi-tier database architecture and mirroring fit in?  Are these just skills any "DBA" (#3) should know?  Do you lump these in with ETL?

Posted by Sam Bendayan on 15 May 2009

OK...lots of good feedback....I will try to respond to everyone.

Several people raised similar points, so let me address those first:

First, I'd like to clear up that what I mentioned were 5 different ROLES, not different

people necessarily.  As many of you correctly pointed out, many small to medium-size

companies don't have the budget to hire all these PEOPLE, but the ROLES exist

nonetheless.  The benefit here is in identifying the different ROLES and SKILL SETS that

are out there, to better communicate the skills that are needed by employers and

match them with the skills that candidates have.  This is where the general term 'DBA'

is failing miserably.  So you will see many PEOPLE occupying more than one of these

roles (I myself have done that for years), but it does not take away from the

usefulness of defining these different skill sets.

About Report writer skill set, I would NOT include it in any DBA group....to me they

are more like application developers than DBAs...although some DBAs do get into Report

Writing.  However, I think the skill sets required for Report Writing are more akin to

front-end application development than back-end DBA work.  The fact that they write SQL

does not change my view of this; many application developers also write SQL. In my own

experience I have worked several jobs where an application developer will get into

Report Writing and then come to me for help with hard-core SQL work.  But I have not

seen many shops where the DBA gets into Report Writing...they usually are too busy for

that, in my experience.  So I guess that is what has formed my opinion.

Several people asked about the 5 BI disciplines.  I mentioned them in the article, but

can elaborate here.  They mostly map one-to-one with the OLTP disciplines, with some

differences:

1. Dimensional Modeler - this is like the Data Modeler, but with a BI slant in the very

different world of Dimensional Modeling as opposed to OLTP Data Modeling.

2. MDX developer - I called this the "MDX" developer, but the reality is that there are

several different languages to deal with in the BI world.  So maybe "BI back-end

developer" is a better term.  That way it can encompass the several BI languages

such as SQL, MDX, DMX, etc.

3. Administrator - These administrators have to deal with Multi-Dimensional databases

such as Analysis Services, which is a much different skill set than the OLTP

DB Admin.

4. ETL Developer - pretty similar to the OLTP, but the target of the ETL is a BI/Data

Warehousing environment.

5. BI Architect - Similar to the OLTP Architect.  This person has experience building

entire BI systems start to finish, understands the internals of how they work,

and can lead BI teams to the successful conclusion of a project.

Now, to respond to some individual points:

Omoba:  I don't mind if you print it out and distribute.

rgriffin:  I agree with the fact that there are real budget constraints to deal with.  

The cool thing about this breakdown is that, even if you can only hire one person, you

can better gauge who that one person is by using these different categories and see how

they measure up in each.  This will help you get the most bang for your buck.  So, if

you have to hire a generalist, test them on all 5 areas and see how much they know in

each...and let the best man win.

David Fulton:  Sounds like you are in the 'ETL developer' position.  The ETL developer

deals with the job of moving data around in the back-end, without any user-facing work

(other than the quality of the data the user sees on the screen).

earlofroberts:  I agree that many of us cross over into several of these areas,

including #'s 1 and 2 (please see my first point above).  Additionally, I think the problem

is that Data Modeling has largely gone out of style and most people don't realize that

it's a full-fledged profession...it's not just a question of making drawings....I've

heard of places where secretaries were promoted to Data Modelers because people think

that's all there is to Data Modeling.  Big mistake.  Then they wonder why there are

data problems all over the place, and people without the Data Modeling skill set just

complain about the technology and say that there is nothing they can do...maddening.

adam.pittman - yes, the corporate world is just as grim, if not grimmer.  The sad reality

is that many bad decisions are made because people are not well educated in this field,

and the fact that there is lots of money riding on these decisions doesn't help in this

regard.  Add to that your every day "rat race" political agendas and you have a recipe

for disaster.

Ronzo:  Replication, Partitioning and Mirroring would fall under the DB Administrator,

not ETL development.  I think that anything that has to do with configuring

out-of-the-box features of a DB product would fall under DB Administrator.

SB

Posted by Wingenious on 17 May 2009

I think the five separate disciplines listed in the article are a very common reality. I think they are often handled by five separate people (or groups of people) in large organizations. However, there's a critical component of database development conspicuously absent from the role descriptions. It's not clear which role is responsible for implementing primary key constraints, foreign key constraints, indexing, and other structural elements. Sadly, I think this gap in clarity is a very common reality as well. I have seen way too many databases in large organizations where *nobody* paid attention to such things.

Posted by Jagadhees on 17 May 2009

Good speech to categorize SQL professionals.

Posted by Sam Bendayan on 17 May 2009

Wingenious:  the structural elements you speak of are in the realm of the Data Modeler.  And you are right about the lack of clarity in Data Modeling....it's one of the most misunderstood professions in the DB world.  Everyone who has put together an ERD probably thinks they are a Data Modeler.  But those are the same people who don't know what a strong or weak entity is, what an identifying vs. non-identifying relationship is, or what a subtype-supertype is.  If you don't know what these are then you are not a data modeler (note:  you may know the concepts although you don't know the terminology, and that's OK, but you at least need to know the concepts and how/when to apply them).  

One of the biggest gaffes in this area that I've seen is when I attended the official launch event of Visual Studio 2005 for Database Professionals.  They touted Visual Studio's paradigm of adhering to the DB Development LifeCycle, but somehow didn't realize that there are NO Data Modeling features in VS 2005 for DB Pros.  So, apparently Data Modeling is not part of the DB Development LifeCycle :-).  And this is Microsoft we're talking about....

Most of the companies that are convinced that they don't need Data Modeling are the ones that should be screaming for it.  This has been one of the most frustrating aspects of my profession for the last 7 years, and I'm planning to soon write a good, basic posting on this blog about Data Modeling, what it is, and why you need it....stay tuned if you're interested...

SB

Posted by Wingenious on 17 May 2009

Sam: Then I'm confused about your definition of a data modeler. You wrote "they are experts in relational database design from a conceptual standpoint" and "They don't necessarily meddle in any one specific database platform" and "much of their work is in the Logical Design Phase and is therefore platform-agnostic" in your description. However, the structural elements I speak of are more than conceptual and they often have platform-specific factors. Sure, data modelers identify candidate keys and entity relationships, but I'm not sure they concern themselves with the physical implementation, and the structural elements I speak of are the physical implementation. For example, I do not think indexing is in the realm of the Data Modeler.

Posted by David Fulton on 18 May 2009

Sam,

Thank you for your reply.

Best Regards,

Dave Fulton

Posted by Cris E on 19 May 2009

Sam, great piece, and I enjoyed your follow-ups as much as the initial post. Twice I had a reply half composed and as I kept reading you laid out my thoughts for me.  Bravo.

Posted by Sam Bendayan on 20 May 2009

wingenious:  Yes, further clarification is warranted.  There really are 2 phases of Data Modeling: the Logical Phase and the Physical Phase.  I said earlier that "much of their work is in the Logical Design Phase", but what this implies (and I neglected to mention) is that the 'other' part of what they do is in the Physical Design Phase of Modeling, in which you construct the Physical Data Model for a specific platform.  In this phase is where you handle the gory details of implementing your DB structures on a specific platform, so things like what actual datatypes to use, the details of implementing RI and your Unique Keys, etc. fall under this area.

As far as indexing goes, it gets a little more nebulous.  Indexing for performance falls into the realm of the SQL Developers, since they are the ones writing the queries and they know what indexes will be beneficial for performance only.  However, indexing for integrity (Primary Keys and  Unique Keys) falls under the realm of the Data Modeler.  So 'Indexing' as a whole really straddles both areas, in my opinion.

Posted by artilugio on 26 May 2009

Solid and well written article, covers all bases, thanks for posting it.

Posted by jacroberts on 8 June 2009

Sam, A nice concise article, nothing unnecessary, very pleasing read.

Leave a Comment

Please register or log in to leave a comment.