Is the DBA Title Dying?
-
Comments posted to this topic are about the item Is the DBA Title Dying?
-
I would tend to agree. My remit these days is to look at a number of different data technologies. There's definitely a role for people who can get down in the details of a database system but if most companies can get away with an AWS RDS instance how many companies have need for a DBA role? A deep fundamental knowledge of how a DBMS works will make you a better database developer even if you never have to apply that deep fundamental knowledge. To give an analogy learning C++ made me a much better VB programmer.
I see this as an opportunity and a threat. The threat comes from the lack of a driver to get down into the atomic detail of a DBMS. If you don't have to worry about IO on a SAN, aligning block sizes with extents etc where does the driver to learn that stuff come from?
The opportunity comes from the variety of data engineering challenges that are out there. There has never been a better time to learn. Even SAS has a community learning lab these days. Teradata have their virtual appliance. Hortonworks have the Hortonworks Sandbox, Cloudera have their CDM. The future is bright for anyone interested in data engineering.
-
Spot on.
The "driver" of detailed knowledge of a DBMS will shift to the people that actually implement all the automation tools and obviously to the people developing the DBMS. So, the need will still be there, just shifted. -
I think, in general, we are seeing less specialized IT people. I think we are starting to see job responsibilities crossing over into other areas. This maybe based on IT budget pressures, lack of people but still need the work done. The old adage of do more with less.... DBAs as a little bit of developers and maybe server engineers etc... With the advent of cloud computing almost anyone can spin up and WIndows server with SQL Server on it, go to YouTube and see how to create a database, table and userid and not really know much about what they are doing.
-
I don't think the title is dying, however I would say that there are becoming more specialized jobs within the scope of database work. So a company that may have had 10 DBA's in the past now has 2 DBA's but still has the same 10 people doing DBA, Database Development, Data Architecture, Data Analysis etc...
- ZZartin - Wednesday, April 4, 2018 1:42 PM
To emphasize that point...
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
I still think there is a need for someone with specialized DBA skills. I see far too many developers with less database knowledge making poor mistakes that impact production performance. There is still a need for a "Gate Keeper". Depending on the company, the DBA wears many different hats and works with many different database technologies. Some organizations still require a pure Prod DBA while others require a DBA/Developer/Architect role.
- Jeff Moden - Wednesday, April 4, 2018 2:17 PMZZartin - Wednesday, April 4, 2018 1:42 PM
To emphasize that point...
haha... downloaded and saved for future use!
- I believe these debates are necessary. We constantly need to evaluate jobs and their titles. I know that my job is in constant flux. I work on many different databases which includes SQL, Oracle, Progress, Informix, DB2 and so on. I still do administrative type work. We have an architect and we also have many developers. I don't do any of that type of work.Is this a job that is going away? No the job will be here long into the future. However, I do agree that the title will change, there will be subdivisions which may have different titles. But the work of the database administrator isn't going away too soon. However, I also agree that using the DBA title may become a thing of the past. The best thing to do is to always let the job title and description be your guide.I find I had the best luck finding a job by using specific wording that the perspective employer used. Therefore, they would understand me better, if I spoke their language. For someone who has been in the business for 30 years - I say roll with the punches. If the title is different, but the job has skills you are suited for and match your skill set then that is the job for you. Before I used DBA, I also used the title Database Analyst which is pretty much the same job. Don't get hung up in titles. Resumes are works in progress, don't print 100 and send them out. Only look for jobs that are relevant to your skill set and adjust your resume to the job request. Best of luck in the future.
-
I see "DBA dying" in the topic I click. 😀 Totally agree with your last paragraph. Sums it up.
I'm actually moving out from my 8 year role from infra DBA (70%) and App DBA (30%). Just a different team, same company. My new title is "Database Designer/Architect". I'm a bit uneasy with the new title and I tend to agree more with "data janitor" as a more explanatory of what I do.
All else aside, I can definitely see myself doing more dev, cleansing, and analysis than actual administration. Is this a bad thing? I don't think so. It's just the general climate. The zeitgeist if you will. I think the guys who are left in my previous team will be nonetheless doing more of dev, cleansing, and analysis too.
The bad thing I guess is not realizing this is the direction forward and failing to reinvent one's self. Yes there will always be places where the traditional DBA/data janitor is needed, but it will be fewer and fewer places I reckon.
- Summer90 - Wednesday, April 4, 2018 1:01 PM
I agree. I also see a lot of less specialized IT people in my company. Not to look down or anything, but these are guys with electronics or pure business management background, math, even political science fields. It's just they got in ahead and had time to learn (10+ years ago).
I think with the ease on how to spin up stuff in the cloud, companies will less reason to keep them and the businesses will focus on hiring more of the specialized IT people, but still fewer people overall.
i.e. if we have 100 employees with 50 less specialized and 50 specialized, we will probably have 50 people 10 of them less specialized and all the 40 are highly specialized in their fields. But being in touch with reality, I still think it will mean less jobs to go around.
-
Administration as a DBA is becoming only a small part of a larger job function. When was the last time you installed windows from scratch. How about setting up a server from scratch and installing windows server. You have a script that will create virtual machines and provision them. The skill set is moving up the ladder. A DBA now has to have more business knowledge and programming skills to deal with developers and architecture specialists The infrastructure stuff is becoming automated and things like backups and upgrades are becoming part of VM machine creation.
-
The titles will definitely change and DBA will be phased out. I've always had a Database Developer or Database Engineer type of title, and even that is being phased out in favor of the more generic Data Engineer, since our jobs are becoming ever more geared towards dealing with data overall, and maybe not so much in a traditional "database".
I've always been a relational db person, first Ingres, then Sybase, then SQL Server, but in the last year I've been learning tons of new techs as my company is phasing out SQL Server due to costs. I've been learning AWS databases, Postgres, and Scala/Spark as the new ETL tool instead of SSIS. It's been awesome fun.
-
For a long time DBA meant "person who did what the database should have been doing but was too stupid to do."
I mean, why isn't the query optimizer smarter (not that it isn't amazing now, because it *usually* gets it right)? Why are we still tuning queries? Managing database sizes? Doing the silly things the database should be smart enough to do for itself. Yes, that sort of DB smarts is rocket science--for the database creators. Those who created SQL Server need the kind of expertise that was wrongly (IMO) shifted to the DBA.
Steve raised a second point, about the increasing complexity of environments, tools, OSes, etc. This, I believe, is an unsustainable situation. It indicates we're in the earliest part of the "do it well" stage of the triune of capability: 1) do it at all, 2) do it well, and 3) do it right. 🙂
As an industry we seriously need to kneecap this complexity monster before it smothers us. For an analogy let's take automobiles. I dare say not one of us could successfully own and drive one of the earliest mass-production cars. Dealing with a choke? Crank starting? Disassembling the engine routinely to clear coke deposits from the cylinders???? Are you kidding me!
Of course simplicity of operation does not translate to simplicity of construction. 🙂 Any one of us can now own and drive a modern car but how many of us can repair one?
So it will be with software. As maligned as it has been, Microsoft Access got an amazing amount of stuff right when it came to conquering complexity. Forms, reports, database, and automation all in one (relatively) simple package. It really was an amazing product when you sat down and delved into it.
Now compare that to SQL Server with a .Net application with Crystal Reports...shudder. Then there's SSIS (moan) and SSMS and all the other SSxx soup. This is better? I'm thinking it's actually a 1.5 on the triune of capability--we aren't even doing all that well.
DBAs should never have been needed. Database designers? Absolutely. Developers? Always. But simple things like the database keeping itself tuned up and minimizing its own resource needs? Never!
-
I actually wouldn't want the server to do a whole lot of stuff auto-magically. Humans would have to write the code to get it to do all that and I strongly disagree with how many humans do things in SQL Server. It's a part of the reason why I don't work with Oracle anymore.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Viewing 15 posts - 1 through 15 (of 37 total)
You must be logged in to reply to this topic. Login to reply