On Facebook last night, I posted the following:
An operational DBA isn’t just a manager of a traditional RDBMS, transactional system. An operational DBA manages the data platform, whatever it is, when it hits production. Their goals are not traditionally the same as someone focused on development. They are looking to keep the system secure, performing well, and ensure it is recoverable in case of failure/disaster. This could be over a traditional system, a no-SQL solution, a warehousing solution built around star/snowflake schemas, or anything that has to do with data storage, management, and retrieval. If you think an operational DBA is a manager of just a transactional system, please update your definition. Operations has changed greatly in the last decade to keep pace with development and business.
The reason I posted this is because I saw some indications that there is a misunderstanding of what an operational DBA is nowadays. Not surprisingly, this misunderstanding came from folks who aren’t in an operational role. Here’s the gist of what an operational DBA is typically concerned with:
- Production security
- Production performance / reliability
- Production recovery
I’m not ranking those in order of importance. The order of those three items depends on the environment. I’ve been in environments where security was more important performance / reliability or recovery (military). I’ve also been in environments where performance /reliability was king.
Note that I didn’t include a particular type of platform. That’s on purpose. I also didn’t indicate whether or not production was on premise or hosted. That’s also on purpose. If you’re still thinking that an operational DBA is only concerned with the care and feeding of an on-premise transactional SQL Server, Oracle, DB2, MySQL/MariaDB, etc. platform, it’s time to update your thinking. An operational DBA takes over when a system transfers from Dev/QA/UAT to production, when it becomes operational (hence the name). Platform, type, where it’s hosted, and those types of details are irrelevant if the system is about data management and it just rolled to production. While there are some operational DBAs who solely focus on transactional systems, that’s not true of all operational DBAs. And that’s not what we operational types mean when we say, “operations.”
Databases - Infrastructure - Security 
Jun 27, 2014 @ 13:18:20
It might be helpful if you add a little context as to what this post is referring to since not everyone uses facebook (it’s true). It seems like something has you really pissed.
“DBA” is a nebulous term. “Operational DBA” is not and your definition seems OK to me. Lots of nosql products claim not to require a “DBA” in their marketing material. This is appealing to business people who sometimes struggle understanding why “production security and recovery” are really important…and difficult. They also don’t understand how this is different from “that DBA who writes my reports and that other DBA that tunes our stored procs.” To them, it’s just data and we are all DBAs. In reality, as your nosql installation grows larger, your need for an “operational DBA” grows too, for all the reasons you mentioned. Maybe the “DBA” that those nosql products refer to is a “Dev DBA”?
Unfortunately not everyone understands the difference between a “DBA”, an “Ops DBA”, a “Dev DBA”, etc. Especially some business folks. But you say, “not surprisingly, this misunderstanding comes from folks who aren’t in an operational role.” I’m not an Ops DBA nor do I play one on TV, but I know an Ops DBA when I see one. And I know the important role they play, how to interview and hire one, how to manage one, and how to listen to one. It’s unfair to categorize people that may not be in an operational role today.
So, if you could provide context as to what this blog post is referring to it would be helpful. I’ve seen some posts and comments lately on Andy Leonard’s blog and Grant’s blog that I’m guessing you are referring to. But in neither post did I see the “Operational” qualifier to “DBA”, nor any reasonable synonym. Sometimes when people say “DBA” it’s really just “data professional in general.” Ops DBAs shouldn’t take offense to this, nor should Dev guys.
I’m not sure everyone would agree with your rigid definition of “operational DBA” either. Many DBAs I know that would classify themselves as Ops won’t touch performance. And some Ops DBAs do handle Dev/QA/UAT, too, to ensure they match closely with prod. Other Ops guys couldn’t care less about security because their users are fine with db_datareader. And some Ops DBAs also handle change and release management.
Can you provide context?
Jun 27, 2014 @ 14:09:01
There were folks who were classifying ops DBAs as only touching on-premise transactional RDBMS platforms. Some ops DBAs do handle other environments, but what sets an ops DBA apart is the focus on production.