It seems that I'm finding myself gravitating towards two non-technical discussions related to the world of the DBA these days. The first is the nature of the changing world of the DBA. The second has to do with support, using support efficiently and getting what you want from support.
In this Blog post I think I'll address some of my thoughts on the changing world of the DBA. I've talked about this at several presentations and have gotten good feedback on some of my comments. In fact I'm thinking of putting together a presentation on this topic as a whole.
The bottom line is that our world (as a DBA) is changing. It used to be that we were all kept busy with the day-to-day drudgery of managing our databases. We were busy trying to keep the thing up and and running, responding reactivity to user requests and imminent fires and really didn't have time for much of anything else, or perhaps we didn't make time for anything else. I think many of us liked working in reactive mode, liked being the hero in spite of the 2am calls. We liked being the DBA, who was talked about in hushed reverent silence in the halls because of our awesome skills and how we saved the day. This kind of thing appeals to our ego, and is a very positive reinforcement behavioral loop. We were DBA's, Database Administrators.
I'd like to propose a new definition of the acronym DBA. I'd like to change it to one of the following:
Database Advocate
Database Articulater (which I don't think is a word, but I'm not above making words up if they serve my purpose).
The point is that DBA's (administrators) can no longer afford to do our jobs in a "Business as usual" type of mentality. If so you will find yourself becoming a dying breed. We can no longer spend our time huddled in our cubes (or at home!) looking at tablespace available space, looking for disk space, helping users tune SQL statements, creating accounts, unlocking accounts, and so on. All of these things are time consuming tasks that are easy to automate.
Why are we spending our time tuning SQL statements? Why are we spending out time fighting COTS applications that don't work well? I propose that the reasons we are doing these things is because we are not doing the job we should be doing, and that we have not communicated effectively to management and the business what our jobs really should be and what we should be doing to really provide the best value to the enterprise.
I'll have some more thoughts about this in my next post...
Robert
Subscribe to:
Post Comments (Atom)
6 comments:
Robert, thanks a lot for bringing up this issue! I am trying to fight the same battle for years - from the development side of the IT.
Sometimes ago I came with the notion of "Development DBA" - a senior specialist that would have enough knowledge of database architecture "to be dangerous", but mainly be involved in two key areas:
- working on impact analysis/advanced research for the senior management.
- being a bridge between all groups (educating developers about new features, translating to "real-DBA" all needs of developers etc, making sure that architects are staying in this Universe etc).
The biggest question is whether "real-DBA" and "development-DBA" should be two people or one (with different tasks)? I think, they represent two completely different sets of skills and have to be split. Would anybody agree with me - or would it be a concept "too-hard-to-sell"?
There is a word articulator which has three meanings: One who speaks, as in "an articulator of administrator's concerns;" the organs of speech, as in teeth and tongue; and a dental device used to make false teeth.
So DBA could stand for Darn Big Articulator, meaning a big mouth who goes around beating a drum. :-)
Of course, many of us have to extract requirements from users, which is like pulling teeth, so sometimes we have to just make our own dentures.
Over here I go for DBA standing for "Dysfunctional Bloody A***hole"...
;)
Still: your next to last paragraph says it all.
I've seen the expression "Database Engineer" proposed to cover what we should really be doing and I couldn't agree more!
As an engineer by training myself I always had extreme difficulty in understanding the whole "religious awe" thing about DBAs.
In fact for a long time I refused to let anyone call me a DBA! Consultant, database designer, yes. DBA?
No: the term means nothing, really.
We do not "administer" databases when we spend our time fighting fires or patching up or tuning some third party app that should never have been purchased in the first place.
That isn't administration, that's alchemy. Or worse: show business! In the bad sense of those terms.
In the end, it's just terminology. But I still feel it's important that folks realize the old concept of the "arcane dba" is dead. And for very good reason!
Although capacity of hardware and functionality of software has changed greatly over the years, the role of a DBA hasn't, at least for me. It's still "explain why this happened", "what's causing this error or slowdown", "can we get our data back to time ...", "can you put that in terms a manager/customer can understand?".
At least for the near future, there's always a need for someone who understands enough of hardware, software, and networks to put it all together and explain what's going on. And because we tend to have our hands in everything, we usually take the blame anytime something goes wrong and obviously there always needs to be scapegoat.
Maybe DBA = Dutifully Blamed Always.
In my opinion a DBA is a guardian of data.
Firstly that is a role to ensure that data is never lost, or if there is a theoretical possibility of loss then that is explained clearly to whoever controls the purse strings.
There are many secondary responsibilities, performance, uptime etc.
The role doesn't change but the tools available to achieve that role change!
If the changes to the tools are good then you will be able to fulfil your role with either more databases, more data or to another higher standard.
High level - I don't think that the role ever changes!
Dave
IMHO.
I always say "Applications retire, but Data lives on forever". A DBA's role is to provide efficient access to data that is stored in the (Oracle) Database (performance and application/database design), making sure that data is protected (backup and security) and ensure it is available for access at all times (availability and redundancy). The tools and techniques that a DBA can use to get this done is continually evolving, and the DBA who does not keep up will be assimilated or outsourced. The DBA who is able to both articulate the requirements and issues around these activities and is able to quickly and effectively use the available tools and techniques to solve issues when they come up will survive.
Post a Comment