Last week I ran into an argument I’ve had since I left the mainframe space decades ago. A developer told me “DBA’s don’t design databases.” The inference was that DBA’s (i.e., Database Administrators) only worry about hardware, security, OS, database backups, things like that. He seemed amazed that a DBA would ever do “data” work.
It may be the name. Perhaps the “admin” part confuses developers. Also, it is true that in some shops, a systems admin does double duty with Windows, SQL Server, and perhaps even mail and web admins.
But there are a LOT of DBA’s, or as the term I like to use, “Data Professionals”, that actually DO get down in the trenches and design databases, write Transact-SQL code and stored procedures, and do almost everything in the database other than write middle-tier or User Interface (UI) code. Some I know even do that.
So what if there is a miscommunication on this? Well, the ramifications can be huge. For one thing, there’s a lack of respect. That’s not called for ever, no matter what anyone’s role is. Also, one of the most impactful areas in a database is the design. When a DBA is asked to export data, tune a process, or troubleshoot an issue, it invariably involves the design. So when a DBA doesn’t get to do the design, they have to live with the results. And anything you’re responsible for when you don’t have the authority over is a recipe for stress.
Another issue is that DBA’s “inherit” all kinds of data structures form around the company. From Microsoft Access to Excel, to amateur Business Analysts creating databases in the Express Editions, they deal with bad design day after day. The newer “modeling” languages that are coming into vogue will make this problem much worse. These languages do not take scale, extensibility, security or performance into account – they just make sure that the data ends up in the right place for that particular design, which is a recipe for data disaster when the “small application” the developer writes becomes a “mission critical” system the DBA has to troubleshoot at 2:00 A.M.
So in case you’re a developer, and in case you think DBA’s “just do admin” – think again. DBA’s spend their whole day in this world, and can be a valuable asset to your development efforts. Bring them in early, bring them in often, and whatever you do – don’t design alone. Business Analysts, Developers and Data Professionals are needed to make a good, sustainable, secure, well-performing database.
i think there is a lot of confusion about what a DBA "does" daily. For each shop it is a different set of tasks. As a result even developers that have an idea about what a DBA does may not fully appreciate the wide range of skills and expertise we can bring to any project.
As Microsoft continues to push tools to the end users to allow them the ability to build their own solutions, then our expertise is going to become more and more valuable. What most shops really need is a formal architecture group that has final say over the tools that are allowed and how they are to be used.
This architecture group should oversee how development tools get deployed and they should also oversee the SDLC for every application (in house and vendor) so that there is a defined process in place for how systems are to be supported. The DBA team would play a vital role in every aspect of the SDLC as well as the tools that fall into play at an architecture level.
Not only should "DBA's" be calling themselves data professionals, but they should start calling themselves "Database Architects". Maybe if we can get that label used frequently we might be able to get others to understand just how valuable we are to any organization.
Excellent article. I always find the attitudes and walls described in your article rather amusing.
Our development department is 50-strong (company size: 135), and from what I can tell, we are radically different from most outfits out there.
Our web developers are all, at the very least, mid-level DBAs. In addition to the normal duties of a web developer (screen design, user interface, web forms, server-side scripting, etc.), each developer is completely responsible for the data storage, structure, retrieval, and back-end design for their modules. They design their own tables and indexes, write all their own stored procedures (no inline SQL allowed!), and are responsbile for performance of their SQL as well.
I believe our system is much stronger, and works better, as a result. If there is a problem, you go fix it, no matter where it lies. Our developers certainly are stronger. There is no finger pointing, no rivalry, and no caste system. You rise and fall by your ability to master the whole round trip.
I didn't realize until our company "grew up" and I started attending conferences that we are not the norm. But I wouldn't have it any other way.
JFOS - thanks for sharing. And you're correct - the whole point of this post is that each shop is different. Some DBA's do admin-heavy work, others do data-intensive work. But it's never a clear line - I've seen DBA's do all admin, and stored procedures but nothing else! And I've also met DBA's who don't have any more T-SQL under their belt than BACKUP DATABASE foo TO DISK = 'C:\backups\foo.bak'.
It's a challenge for us here at Microsoft to write software for all these professionals, but one I think we do a pretty good job at. Sure, there's room for improvement (always) but by and large it's simple enough to learn and expand into either end of the spectrum, from Sysadmin work to database design.
Thanks for reading!
Amen, we are all data dude's!
Last week I was trying to "educate" some developers why the SQL generated by the Entity Framework, does not meet the bar, since it fills up the plan cache and there is zero,as in no, plan reuse and we simply cannot accept in to our environment for obvious reasons if you are a database professional. Same goes for supporting stored procedures for CRUD operations from inside the Entity Framework, which it does not support.
One day I hope we will get a true data platform, with a single type system from store to application, which I can model, deploy incrementally, detect differences in versions etc. Until that day arrives we need more database professionals to make sure things keeps working and keep sane, end-to-end. Too many developers treat the database as a opague bit-bucket, where indexing is the magical sauce to performance. Database design, modelling, indexing review, data path analysis, what do you mean? Last week I had the opportunity to go to the PDC the first time in my life, and I got scared. If developers are going to rely on M, what will we end up with, it reminds me of the Access Upgrade Wizard, I am thankful it provioded me with tons of work.
The most scary thing which proofs that Microsoft does not understand what DBA's realy do is the new "data tier application". More levels of abstraction that add no value. More work for the database guys to control the applications on top!
Good article. It days it well.
What you state is true, but only half the truth. DBA's develop, and on the other hand some DB developers administrate their hard- and software (nearly) completely. And nothing is wrong about that as long as you communicate and co-exist with your sys admin, and the sys (+ db) admin does the same with the developers dependent on him. This is just one further good example that without doubt leads to the conclusion that respectful co-working is better than hierarchies, hybris and isolation.
This is a common problem for DBA's, Programmers, Testers etc alike.
I am a programmer by background, however, DBA and testing (beyond unit testing) duties come my way as standard. Business analysis work too. Nothing different from anyone else. As a freelancer I see that very few places now have anything approaching pure roles.
Rudeness, however, is not limited to developers. Neither are all developers disrespectful. I find that, banter aside, there are roughly equivalent proportions of respectful and disrespectful people in each category.