Billy Bosworth (Blog (not updated recently)), the head honcho of the database business unit at Quest Software, has been posing an interesting question lately: “Are DBAs losing their power?”
We used to be all-powerful. When we walked into a development team meeting, we could pound our fist on the table, demand a primary key on every table, and get our wish granted. We held the power to stop a bogus application from going into production if we thought it wouldn’t scale. We pointed at security risks where someone might steal our customer data, and developers jumped to fix it. These things appear to be happening less and less.
So who’s usurping the power of the DBA?
Project managers buy systems without talking to a DBA or an architect first. When the check is written before the requirements are, inevitably the solution doesn’t meet all of the requirements. The systems violate security standards, run as SA, don’t work with current versions of SQL Server, and worse. For examples, check out the comments on Tim Ford’s contest about vendor problems.
Virtualization admins tell company executives, “We need to save money by using virtualization to reduce power, cooling, and licensing expenses. Everybody else is getting great results. The DBAs are being problem children.” The executives agree, and everybody throws the DBA under the bus. Next thing you know, the SQL Servers are getting virtualized.
Compliance auditors have crippled DBAs by demanding more and more busywork to produce complex audit logs. We’re not allowed to upgrade our servers to auditor-friendly SQL Server 2008, so we’re forced to reinvent the wheel to get even the most basic compliance information out of SQL Server 2000 and 2005.
SAN admins tell the DBAs not to worry – everything on the SAN is just fine. The DBAs ask for proof and ask to see performance & configuration reports for the SAN, but their requests fall on deaf ears.
Cloud vendors are touting internet-based databases that don’t require any DBA time. Developers get excited about this because they never really liked DBAs to begin with, and they’re looking for something that scales like crazy. Cloud vendors say they have the solution, so developers go that route.
Excel users are seeing the promises of BI-for-everyone in the coming version of SQL Server 2008 R2. They’re getting excited at the thought of slicing and dicing million-row spreadsheets without a pesky DBA telling them they have to procure resources ahead of time and plan schemas.
Are problems like this having an impact on you and how much power you wield?
13 Comments. Leave new
I’m not sure things are much different. I’ve seen DBAs for two decades have to battle constantly in the PC world for changes to be made, both on Oracle and SQL Server. Developers have always won their share of battles because of the desire for work to get done.
Maybe it was different in the mainframe or mini days, but I think for the entire existence of SQL Server, DBAs have had to fight for everything.
Having been on both sides of the often-discussed “fence” between developers and DBA’s, I would agree with Steve that those battles have, indeed, been going on for years. I started in the client-server world in the early 90’s and they were certainly alive and well then. But the changes I’m talking about today go beyond that “normal” tension with the app teams.
Take backup and recovery as an example. I know of several of our DBA customers who are losing more and more control over their backups. They are either being “solved” with mirroring solutions, or the central backup team is taking control, or the virutalization team is taking control at the image level. In many cases I have encountered (and in companies of varying sizes) the DBA’s are not even being asked about the backup and recovery strategy. I find this nothing short of disasterous for the companies. When something goes wrong it will be the DBA’s that get the tap on the shoulder and in many cases, they will be ill equipped to help in the timeframe the business is going to expect.
Another area is virtualization. Because of extreme cost-cutting measures, and the political battles they create, virtualization is being forced upon the SQL DBA at alarming rates in our customer base. I see this more and more with many of the accounts I visit. Certainly enough that I would now call it a “trend”. In many cases, this the the way “consolidation” is being forced upon SQL Sprawl. Again, I’m finding the (what I believe to be disasterous) omission of the DBAs during the architecture discussions happening more frequently. One DBA told me: “They’re moving a dedicated 8-way physical box to a shared, virtualized 4-cpu box because they think the physical one is overprovisioned. Good luck with that.”
Lastly, in this volatile economic climate, I’m seeing that most everyone (not just DBA’s) is reluctant to stand in the way of cost-cutting projects for self preservation reasons. “Make too much fuss, and you may become part of the cost-cutting” kind of thing. So, the DBA’s I’ve talked to are basically sitting back and saying, “This is gonna blow up at some point. When it does, I will get much of my influence back in the aftermath.” I tend to agree with them.
It’s just like balance of power politics 🙂
Surely if you can get a project management certification ( I personally recommend PMP ) that thwarts the non-technical PMs from making uni-lateral decisions for you hopefully, depending on the structure of the organisation (matrix versus departmental, with projectised hybrid the best…).
Or, better yet, that you’ve been pro-active enough to also be the PM for your own cost cutting projects, which, are for the most part right now, the Virtualisation and Consolidation of SQL Instances (flavor of the month cost-cutting, albiet revolutionary in itself).
I am still mad they won’t let me run the SQL service as a domain admin any more. WTF is that all about! 😉
Yea, many things goes for the big changes, but interesting info from this site:
http://www.indeed.com/salary?q1=SQL+DBA&l1=&q2=Oracle+DBA&l2=&q3=SQL+Developer&l3=&q4=Oracle+Developer&l4=&q5=MySQL+DBA&l5=&q6=MySQL+Developer&l6=&q7=C%23+Developer&l7=&q8=VB.Net+Developer&l8=&q9=LINQ+Developer&l9=&tm=1
You can add any job title to compare and to see what are the results about them, include any job title and post the link here…
More Results about more job titles:
http://www.indeed.com/salary?q1=SQL+DBA&l1=&q2=Oracle+DBA&l2=&q3=SQL+Developer&l3=&q4=Oracle+Developer&l4=&q5=MySQL+DBA&l5=&q6=MySQL+Developer&l6=&q7=C%23+Developer&l7=&q8=VB.Net+Developer&l8=&q9=LINQ+Developer&l9=&q10=Application+Developer&l10=&q11=Application+Architect&l11=&q12=Database+Architect&l12=&tm=1
Just when i got the hang of SQL Server, now I need to go take some Oracle classes… I want that 100k baby 😉
2 words for those pesky Excel (and MS Access) users and their million row queries and Cartesian products:
Resource Governor.
Mwahahaha, Mwhahahha, Mhwahahaha!
G. D. – got some bad news for you. The new BI stuff is hooked up to Analysis Services, not the database engine, so your Resource Governor is powerless.
Your absolutely right, Brent. And if I’d thought about it, I’d have realized it before that last post. Still, perhaps I could use “The Guv” to punish them later for their past transgressions?
😀
Cheers.
G
Just remind them of the Segregation of Duties, We can simply remind Developers that complying with the Rule of Law isn’t really an option (many state it is overhead), especially if running a controlled environment for a public or govt. organisation: http://www.sqlservercentral.com/blogs/hugo/archive/2009/02/15/the-importance-of-the-segregation-of-duties-with-respect-to-internal-controls.aspx
Hugo – agreed, but the number of people working in an environment with true segregation of duties is pretty low. Do you have SA rights on your own server? If so, you have the ability to turn off database auditing, and you yourself are violating segregation of duties. Do you have access to delete to your own database server’s backup files? You’re violating it there too.
Brent,
I agree with the comments made in this article. We as dbas merely have to accept any system that is placed in our care and we get the blame for it , quite literally we feel it in our pockets .