• I have to say, I think both articles are right. I see the role of Production DBA seeming to shrink in terms of importance even as it becomes a more clearly defined role due to the compliance requirements you outline.

    My own experience at our company finds us placing more and more emphasis on the development DBA as the more senior position. Instead of simply writing stored procs, we're the DB designers and the guys that come in to address performance problems, deadlocks & blocking. The production DBA's are managing security, backups and deployments. We've found that instead of releasing garbage and then cleaning it up, we need to take the time to clean it up in design and development, which places the onus of knowledge and skill at that level instead of downstream. We have developers writing procedures that we then review for standards compliance and performance. We're much more DBA than developer, but we really do have to straddle the fence (which can be quite painful at times).

    As far as skill set goes, constant improvement and expansion both in terms of breadth & depth has to be the rule, or you will be relegated to being the backup monitor guy.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning