July 3, 2015 at 2:25 pm
Comments posted to this topic are about the item Is the role of the DBA really changing radically?
Best wishes,
Phil Factor
July 6, 2015 at 12:30 am
In my experience, people who use DBs at least an SSMS level fall into several categories (and often they overlap) and they are:
• People who design DBs;
• People who are responsible for the running, maintenance and security of DBs;
• People who are responsible for the running, maintenance and security of the server and OS;
• People who implement business logic and create/further/alter the interface between the DB and the application server;
• People who make reports or generate information from the data in the DB;
In the first decade of the new millennium of Systems Architect rose up and has taken over the first of these. The position of reports writer took over the last of these and I have also seen the Sysadmins take charge of the DB security as well.
And finally, in the last five years, with the development of devops, the developers have come to believe that they should do everything.
I, personally, am of the opinion that DBAs should have a say in everything to do with the DB and I believe in consultation [1]. I don't make any changes to the NT-server without first consulting the sysadmins. I don't assign read-login-rights without first consulting the product owner. No-one gets write-login-rights unless I am ordered to assign them. If I can optimise an SP, I will let the developer in question know.
[1] One of the developers thinks that he does too: since he knows that I hate any EF with a compexity of more than one join, he offered me a choice. He has to re-work the history of a widget and normally it involves an INSERT and an UPDATE. It had been done before with SPs. Not now, for they are old-fashioned, he said. Instead, the options he presented me with were:
a. TRIGGER based on an INSERT-statement in EF;
b. VIEW which determines the current state of the widget based on all of the entries in the change table;
c. Everything done in application server and changes written to the tables in question;
I chose d. SP — updated from the current version.
Apologies for the usual rant about developers.
July 7, 2015 at 6:28 am
Hi Phil, Sean,
Thanks for the thoughtful editorial and comments. It was very timely. At my company, our software developers have historically done all the front end coding as well as the underlying data model and database design, the stored procedures and functions, etc. That approach has worked well ... it is fast, efficient, and straight forward. In essence, we've been more like the "developer DBAs" you both described.
However as we've grown, we are now experiencing a need for more of the "operations DBA". Our applications have grown in sophistication and complexity and the amounts of data that we store and access has grown dramatically. Dealing with those sorts of things takes us further into the realm of database optimization, indexing models, maintenance plans, query optimization, etc. Simply creating a stored procedure and throwing in a cursor or adding a few foreign keys to a table is no longer good enough.
So your differentiation of the different types of DBA roles is very helpful. I plan to make use of it as part of a proposed reorganization and new position description. Thanks!
Mike
July 9, 2015 at 8:23 am
Liked your article. How about this one...a logical DBA and a physical DBA. You may be scratching your head with these two job titles, but this is what I deal with on a daily basis as an Enterprise Architect (with a DBA background as well as engineer (programming) background). Very confusing cross functional and cross team responsibilities, but I do get a laugh everyday when confusion arises.
In any case, to "answer" your question, I do believe the historical role of the DBA is not dying but evolving.
Thank you and I enjoyed your article.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply