This is something that i've thought about for a while to be honest. You see all of the different job titles out there, all with varying levels for each (Junior, Senior, Principal, Lead).
What do I think they all mean? Do we all think the same? - hopefully the collection of responses in this month's TSQL Tuesday may go a little way to answering that.
We know we're all different, but often Database roles get a strange bunch or reactions, from those who think we are all identical (The Agent Smiths, both male and female). Or maybe worse, for some roles, no longer required.
I'm not going to plummet into discussions about all of the different levels to be honest, as i've found this massively varies between organisations, regardless of skillset/responsibilities. Also, I have the luxury of hiding behind the fact that this month's post isn't meant to be about that.
To complicate matters further, throw these into the Job recruitment machine, and you can often end up with:
Company 'A' thinks job title 'A' does 'x', 'y' and 'z',
...whereas company 'B' thinks Job title 'A' does '1','2' and '3'.
Confusing, and horrible if you get to the interview stage and realise that the actual job role isn't what you expected it to be and its not primary skillset.
So what are these hash buckets I think I can cast people into?
Database Administrator
Ah, "Don't bother asking", "Does b*gger all" etc. I'm sure we've all heard many others.
I generally see these as split down into two very broad areas, but rarely advertised as such. Often there is a sliding bar between the two roles at different companies. By that I mean the role responsibilities often cross the borders between the below, at differing levels. Or there is no distinction between the two roles and the "DBA" does all.
Production DBA - the Proddies.
These are your DBAs that monitor systems, respond to requests and incidents, check backups, test restores, support releases and deployments etc. These folks may have wandered in as the "Accidental DBA", sometimes from an Infrastructure background.
and:
Development DBA - the DevDBAs
More towards looking at the code running, new code reviews, analysis of what's out there already, tuning, design/redesign, database architecture etc. And these folks may have come from more of a development background.
Just segregating these two off for a moment, I often see these classed under the same job roles as 'DBA', with no distinction between the two and role responsibilities often stating both sets of requirements above. However, I do also often see those same roles not stipulating a Prod or Dev DBA title, but distinguishing as to whether the role is primarily OLTP or DW workload based. Interesting that.
Note, I consider a Development DBA a different skillset to a SQL Developer - the Devs.
Database Reliability Engineer. - the DREs (or DBREs)
I've spent a bit of time with this hat on.
These folks sit alongside the SREs, but handle the data side of the SRE landscape, Focusing more on monitoring what's going on with the database infrastructure, with one very large eye on Observability (my overly long take on that for SQL Server can be found here). They can often be the go-to SMEs for the database technologies employed by the organisation.
Automation plays a huge part to reduce day to day toil and there can be a requirement to make systems self healing, again to reduce effort. Finally, they generally have a greater responsibility to design and maintain database deployment pipelines to aid further automation than a DBA would.
Personally, i've always had the mindset of automation and monitoring thankfully, for two main reasons.
Automating frees up my time from the menial boring stuff, and gives more time to do the cool stuff.
I need to know what's going on in my systems, so the proverbial hitting the fan can be explained, or preferably predicted and avoided altogether.
So you may find these particular DRE responsibilities being done by DBAs also. Another crossover.
Data Engineers - The DEes.
Data Engineers often have more of a code and data background, and have responsibilities including:
Design/Creation/Maintenance of the infrastructure and pipelines to supply the required data to consumers.
Cleaning of data, ensuring data quality - Data Wrangling*
Skillsets often include more scripting languages, so heading into the realms of R and Python. Knowledge of data lakes/hadoop, streaming technologies, such as Kafka, and processing / analytics technologies such as Spark.
Also SQL knowledge, with DB querying via code a must and Data Warehouse operation and design being high on the list as well. Lots of everything still use
Credit where credit is due though, i've worked at a company before now where the Team name for where the 'Data Engineer Techs lived was: "A Walk in the Spark". Class.
Data Scientists - The really clever people.
My experience is that these folks have a lot of brain going on, and that's no disrepect to any other role here.
They have to provide analysis for lots of data (often provided by the Data Engineers above), and try to identify trends and patterns within that data. For this they may build data / statistical models, and machine learning algorithms alongside. So their knowledge requires: coding of multiple languages (a much deeper understanding of R and Python for example), mathematics, machine learning, statistical analysis, and even visualation skills for the above. Honestly, this is one of those roles that I know basically what they do, but not a great deal about how they actually do it.
Final thoughts.
That's about it out of my head, apart from perception. (You had a feeling that was coming didn't you?) Many database teams often do a combination of roles, and fall into a different bucket above without even knowing it. And how people view the roles that have been around for a lot longer may get less love.
Point in case is i've worked in DBA teams who automate, have the mindset and generally perform most of the role above of a DRE, but are just called the DBAs regardless.
Even worse, is that sometimes, unfortunately, this gets a more negative perception of "Why have you still got a DBA team?". They do what is required, and if they were called "Database Reliability Engineers" or some fancy title like "Data Availability and Security Protectors", they'd get less flak from others.
Wierd? Yes.
Unfair? Definitely.
I'm past that point in my career personally to care about a job title, its the required job responsibilities that matter to me but it does still for a lot of people, and I get that.
As ever, thanks for reading my ramblings.
Rod
*Buzz word Bingo! Line! House!