Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 1234»»»

Does the Role of the DBA Need to Evolve? Expand / Collapse
Author
Message
Posted Saturday, December 10, 2011 11:13 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, January 10, 2014 7:20 AM
Points: 175, Visits: 723
Comments posted to this topic are about the item Does the Role of the DBA Need to Evolve?

Brad M. McGehee
Microsoft SQL Server MVP
Director of DBA Education, Red Gate Software
www.bradmcgehee.com
Post #1219839
Posted Saturday, December 10, 2011 1:24 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, April 09, 2014 10:23 AM
Points: 5, Visits: 125
The DBA will continue to be the "plumber" getting the data to the superstars who analyze it. Can you depend on the interpreters of the information to manage the pumps and pipes? I doubt it. They are different tasks.

That said, I watch the data and try to understand its relevance and measure its integrity. I can't meet the consumers of the data halfway otherwise.

It's refreshing when they meet me halfway too, and I reach out to them. But when they don't respond I am not surprised, just disappointed. (Frequently they are disappointed too, eventually.)
Post #1219853
Posted Saturday, December 10, 2011 6:35 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, March 05, 2012 12:42 PM
Points: 8, Visits: 17
There's another source of endless information which doesn't seem to be mentioned very often: Twitter has a deal for every Tweet to be archived at the LOC (Library of Congress). That'll easily outweigh the Google 20 Year Usenet Timeline (http://www.google.com/googlegroups/archive_announce_20.html)
Post #1219876
Posted Saturday, December 10, 2011 7:10 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, October 26, 2012 3:41 PM
Points: 2, Visits: 20
Yup,

We be plumbers.

But, in medium/small businesses the goal has always been to deliver information, not just data.

I am currently I am working with a large group of superstar analysts. The only issue is that they are superstars at a very narrow body of knowledge.

The end result is that there will always be a need for generalists that can get the job done when it is needed, without highly specialized domain knowledge.

So, IMHO, the editorial is sorta off the mark to begin with. Us SMB DB monkeys have always had to curate data and always have had to deliver usable information.

Brad

Do not forget that overspecialization has usually led to extinction.

Post #1219879
Posted Saturday, December 10, 2011 8:09 PM


Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, January 23, 2014 9:23 AM
Points: 63, Visits: 468
I worked at a university as a data analyst using statistical software in 1983-- yes, 1983. I struggled to manage data relationships using SPSS. Then I was introduced to Ingres 1.0. Relational database has been my credo and my paycheck since then, with statistical software and Excel in supporting roles. Even though the Ingres database server crashed too frequently and it was my job as DBA to recover from crashes and work to prevent them, I was recognized as knowledgeable about data as well as database server. I taught relational database design and index design for Computer Associates in the mid-1990s.

I work on short term contracts, mostly fixing SQL Server problems created by application developers who may be good application programmers, but not database programmers. Microsoft created a monster by presenting SQL Server as a room in the Visual Studio rather than supporting the role of the DBA as separate from the role of application developer. True, the programming built into SQL Server eliminated the need for a dedicated DBA to manage the database server and databases, but what role understands the data relationships? Typically, application developers do not recognize or respect many-to-many relations-- for instance. A data-oriented DBA is a much better database designer than is the combination of a business analyst working with an business-intelligence-challenged application developer.

Companies that hire me typically expect that I will make a fix to how SQL Server DBMS works on Windows and their hardware -- "tuning." Typically, they don't welcome a demonstration that performance can be improved dramatically by teaching database programming to their application developers. (Really now, do you think it's more likely SQL Server and Windows fit together badly or that your application is not using SQL Server optimally? How many programmer analysts does Microsoft employ, and how many big applications has your lead developer delivered?) Object-oriented programming ("data is dead but must be persisted when not being viewed through this application") and security-mandated separation of development from production have pretty much succeeded in persuading IT managers that data is owned by applications and the database is just a box.

>>Will the DBA role evolve naturally from being a "caretaker of data", to "interpreter of data"?

I would like the DBA role to RETURN to include "interpreter of data."



_________________
"Look, those sheep have been shorn."
data analyst replies, "On the sides that we can see.."
Post #1219884
Posted Sunday, December 11, 2011 9:23 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 10:06 PM
Points: 35,978, Visits: 30,269
From the article:
Will the DBA role evolve naturally from being a "caretaker of data", to "interpreter of data", for the good of society?


I believe that anyone who doesn't already think so, has missed the proverbial boat.


--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." -- 04 August 2013
(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1219932
Posted Monday, December 12, 2011 12:26 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, August 21, 2012 1:15 AM
Points: 191, Visits: 224
katesl (12/10/2011)
I worked at a university as a data analyst using statistical software in 1983-- yes, 1983. I struggled to manage data relationships using SPSS. Then I was introduced to Ingres 1.0. Relational database has been my credo and my paycheck since then, with statistical software and Excel in supporting roles. Even though the Ingres database server crashed too frequently and it was my job as DBA to recover from crashes and work to prevent them, I was recognized as knowledgeable about data as well as database server. I taught relational database design and index design for Computer Associates in the mid-1990s.

I work on short term contracts, mostly fixing SQL Server problems created by application developers who may be good application programmers, but not database programmers. Microsoft created a monster by presenting SQL Server as a room in the Visual Studio rather than supporting the role of the DBA as separate from the role of application developer. True, the programming built into SQL Server eliminated the need for a dedicated DBA to manage the database server and databases, but what role understands the data relationships? Typically, application developers do not recognize or respect many-to-many relations-- for instance. A data-oriented DBA is a much better database designer than is the combination of a business analyst working with an business-intelligence-challenged application developer.

Companies that hire me typically expect that I will make a fix to how SQL Server DBMS works on Windows and their hardware -- "tuning." Typically, they don't welcome a demonstration that performance can be improved dramatically by teaching database programming to their application developers. (Really now, do you think it's more likely SQL Server and Windows fit together badly or that your application is not using SQL Server optimally? How many programmer analysts does Microsoft employ, and how many big applications has your lead developer delivered?) Object-oriented programming ("data is dead but must be persisted when not being viewed through this application") and security-mandated separation of development from production have pretty much succeeded in persuading IT managers that data is owned by applications and the database is just a box.

>>Will the DBA role evolve naturally from being a "caretaker of data", to "interpreter of data"?

I would like the DBA role to RETURN to include "interpreter of data."


Great post, I agree with this.


/@devandreas
Post #1220016
Posted Monday, December 12, 2011 7:23 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, April 17, 2014 8:12 AM
Points: 2,627, Visits: 19,093
Jeff Moden (12/11/2011)
From the article:
Will the DBA role evolve naturally from being a "caretaker of data", to "interpreter of data", for the good of society?


I believe that anyone who doesn't already think so, has missed the proverbial boat.
Wherefore, good sir? I think each role has so much importance that to combine the two might dilute the results. Making sure that such large volumes of data are available, backed up, up to date and consistent seems as important in the future as it is today (only becoming more so as you deal with more and more data). On the other hand, a true understanding of the data without having to worry about where and when it is stored is required to make business decisions, and time taken to do both of those things takes away from the value of whichever one is your primary goal.

I would think it similar to a fighter jet; you want your pilot to be rested and ready to fly the damn thing, not worry about upkeep, that's the mechanic's job. Both highly specialized, both vital, not a crossover position.


---------------------------------------------------------
How best to post your question
How to post performance problems
Tally Table:What it is and how it replaces a loop

"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
Post #1220247
Posted Monday, December 12, 2011 7:54 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Monday, April 14, 2014 1:34 PM
Points: 15,442, Visits: 9,588
I agree with the split. DBA = admins the database, Management = analyzes data and makes+implements decisions based on it, Analyst = support for management when specialized knowledge/skills are needed to turn data into information.

Conflating the functions is a mistake. We don't have managers (generally) who are expected to maintain the air conditioner for their office, so why expect them to admin a database or server? And we don't expect the HVAC engineer to analyze the company, the markets, the government, et al, and make decisions about the business.

I've been in both positions (DBA and management; I haven't done HVAC work in over a decade), and they require complex and different skillsets and knowledge. Managers are the ones who have to analyze data and turn it into information that can be used for planning (or reacting, depending on the urgency). Sometimes (often) they need help on that from people who are trained in areas like statistics, but that's the role of a researcher, not a DBA (DB Admin, not DB Analyst).

Those are people who deal with determining correlation vs causation, et al. It's mainly stats, scientific methodology, etc. Again, they don't need to know how to design a good database (relational or cubes or whatever), they need to know how to spot relations in complex data. "Customers who buy toothpaste also often buy dental floss" has a probable causal relationship to interest in personal hygiene, vs "Customers who buy diapers also often buy beer", which turned out to be a correlation with no real causal relationship (real-life data mining scenario). That's not something based on classical DBA skills, like normalization, SARGability, b-tree indexing, et al, or DR, backups, log shipping, replication, et al, depending on which version of DBA you mean.

Specialists cost more, but have the opportunity to be better at what they do. I view that as a positive thing.


- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #1220263
Posted Monday, December 12, 2011 9:21 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 2:51 PM
Points: 159, Visits: 465
There's a real difference between the DBA and DA roles. And the DA role which Brad McGehee suggests seem to live at the junction of IT and many of the social sciences - the latter not being something with which today's DA (much less DBA) is usually familiar.

In our shop - part of a public agency - most of the analytics and data mining is actually conducted by the GIS staff. We are fortunate to have a tried, true, and trusty DBA who excels at providing the data to GIS - and it seems likely these roles will remain unchanged here into the foreseeable future.

Yours truly,

Hari Seldon

=)
Post #1220337
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse