Andy Leonard notes that DBA's are required personnel in any serious IT organization.
A friend (who shall remain nameless) recently told me his company interviewed a competent database developer and DBA. All seemed in agreement an offer would be forthcoming until the very end of the recruiting process. At that time, someone made the comment "we don't need a DBA."
It used to be oh-so-simple: there were developers and there were DBA's.
For a time, there was a hybrid job title of “Database Developer.”
But now, in the post dot-com world and in the era of good GUI based database design tools, many organizations think that the DBA role is a relic of the past.
Anyone with half a brain knows this isn't the case.
Developers are developers and now that OOP thinking has been in vogue for the past decade or so, developers tend to think in terms of objects.
Databases are relational animals, and any good data model will reflect that.
The problem is that developers don't think relationally.
When OOP developers design schemas, bad things happen.
The bottom line is this:
Where does your application retrieve data from?
Where does your application store data from?
Where does your application's transactions take place?
Databases are central to nearly enterprise level application and I can't tell you how many bad schemas I had to unravel to get at any real data.
And don't get me started with how many bugs I've had to resolve as the result of a poor database design.
Sure, developers can build decent data models and schemas, but if you're really after high performance, reliability and scalability, you will need a DBA on your team.