My first post received some great comments and so I want to continue with the theme of the changing world of the DBA. Back some years ago there was this Collaborate (or Open World I can't remember now) session that was DBA 1.0 vs. DBA 2.0. In this session, our gallant 1.0 DBA stepped up and used scripts, and the equally gallant DBA 2.0 used OEM to manage the database. This was in an effort to prove the virtues of DBA 2.0, using the automated tools that Oracle makes available and so on. I thought it was a great session and I think that it might not quite have proved the case for DBA 2.0. DBA 1.0 was still pretty in the thick of things with his scripts, but I will say that I like the GUI's for lots of things too.
I submit though that we need to move beyond the DBA 1.0 and 2.0 world, and become DBA 3.0.... Maybe we should have been DBA 3.0 in the first place and we just didn't realize it.
In one comment from Michael "Misha" Rosenblum there was a suggestion of a "development DBA". He sugested the following attributes for a development DBA:
[he would be] 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.
[he would be 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).
This would be a good start I think, but I think that DBA 3.0 goes deeper than this. Some organizations have development DBA's, some have architects, the job of database and data design can be pretty watered down at times. However, it seems to me that in most (there are always exceptions) places I've seen, be it a development DBA, a regular DBA, an DBA architect, what have you, we are often late to the ball.
We often show up at the door after the party has started, the decorations are up, the music has been selected and the guests have arrived. We are late to the party to find that the guests are all under age, the drinks are all alcoholic, the party favors have not been delivered nor ordered, the seats are missing pieces to make the sit up properly, and we don't have enough budget money for speakers because someone forgot that when you order a stereo for the DJ, you might just want speakers and the cables for those speakers (or just as likely the speakers were ordered with the cables that are incompatible).
The point is, that we were not involved at the beginning. Why was this? We probably had heard somewhere about the party that was coming, heck we even got an invitation to it at some point. We knew that our skills would probably come to bear at the party since we know a thing or two about planning parties. So why did we not get involved.
There may well be a lot of reasons for that. It could be that party planning is just one of our many responsibilities. It could be that we have many parties going on, in different stages and at different locations. It could be that we are just sitting back at our station, watching the monitors, making sure that people are doing the things they are supposed to be doing. We are looking at the things we know have to be going on, but not really thinking about the things that are not going on (like the ordering of the alcohol).
Perhaps management has turned us into mere security guards, watching these monitors because that is what management thinks we do. Have we told them differently? Have we tried to tell management that we need to be pro-active and not reactive. Maybe we are comfortable sitting and watching those monitors, is that possible? There sure it a lot less risk doing that.
Still, time after time we see the disasters happen. Party after party just does not work right, success is not repeatable. We see all the reasons why, but what can we do?
The same is true of many (not all) DBA's. At time, it's the DBA who is at fault. Some are comfortable sitting in their little space, controlling their little domain, keeping their heads down, being the hero when they tune every slow piece of SQL that comes across their desk. All hail the DBA who can tune anything. Really though, I submit that if SQL code continues to need tuned by the DBA then there is only one person at fault for that, the DBA.
There are the DBA's that enjoy a good laugh too. They joke when the hardware is not ordered on time, when the wrong components are ordered or when things are not configured properly. These DBA's live on the failures of others, making themselves look so much the better. But really, are we? As one commenter responded in my previous post:
"In my opinion a DBA is a guardian of data."
And I could not agree more and yet, do we really do all the things needed to guard that data if we are just sitting in our little cubicles and watching things happen. Waiting for parts to be ordered, delivered and put together.
Are we guarding that data if we are not there at the beginning, articulating to management what our role really should be. Are we there making sure we understand what hardware and OS that others are deciding we should use is the right choice? Are we there, fighting the good fights (loosing once in a while) or are we cowards, or so politically correct that we can't stand up and say, this isn't the right choice.
Are we on the front end of modeling, or are we allowing developers to start the modeling before we ever get involved. Are we cowering to demands from others that we allow tools to model the database for us, or that we don't need to model in 3NF because of this reason, or that reason?
If it because we really don't understand and can't articulate the reasons to model in 3NF? Is it because we can't articulate in a language that business and development understands the need for the use of best practices and that, 3NF performs just fine, thank you very much, if you think in terms of groups/sets rather than procedural thinking.
The point is, if we don't understand what we are doing, how can we hope to help others to understand how important these things are? If we understand but we can't articulate to others how important these things are, how can we hope to ever become DBA 3.0?
I submit that we must become DBA 3.0, and beyond. We must learn to change, we must learn to communicate, we must learn how databases work, why backups are important, why DR is important and learn to communicate that. We need to learn how to translate things like outages into dollars, which is the language that the business and management understands. I assure you a manager will understand "The cost of a two hour outage to this company is 3.5 Million dollars and that cost doubles every two hours." rather than "We need a DR plan, there are terrorists out there!"
Ok..... my flight is landing.... more later. Your thoughts are quite welcome!
Subscribe to:
Post Comments (Atom)
11 comments:
Easier said than done. Consider a corporate culture that does not want change and love doing things the same old way from decades ago. You might think, why just not quit and find another company. Easier said than done.
Did I say it was going to be easy? Noooooo.... in fact I'll talk about that a little bit in my next post. You are correct, Corporate culture is a challenge and always has been and always will be. Still, is part of that our own fault?
I am often reminded by my manager that you can lead a horse to water but you cannot force it to drink. There's a tradition, that's how we have always done it, it's our standard, regardless of whether it makes any sense or not. I sat in a meeting trying to convince a group of engineers how not to name a column of a table and failed miserably. I sent a email to HR with 4 choices as a solution and to rank the solution from best to worse. HR responded with the worse solution as the one that we are implementing. I thanked HR profusely because I thought I was crazy. HR responded, it was just common sense. To this day, I still don't have the answer as to why HR can see it and engineers cannot.
Whose fault is it when the horse had been lead to water, but the horse does not drink?
Hep! dba3.0 pays royalties:
http://dbasrus.blogspot.com/2008_08_01_archive.html
is the proof.
:)
Quite a few good questions and ideas shown here.
I still think we need to separate roles a bit.
But the traditional development/production dba separation is gone.
Development dbas are rare events, in this day and age of "outsource/offshore all thought processes to the cheapest provider".
And production dbas are asked to do a LOT more than tune SQL.
I still think we need to use a term like "database engineer", or maybe "data management engineer".
As in someone who has to work very closely with architects and management in order to provide and extract true value of the knowledge of the data.
But it takes a long reply to discuss all that. Thanks for posting what turns out to be an interesting and thought provoking series.
Royalties, check. 10% of nothing is nothing so we are settled! ;)
Maybe I should call it - DBA: The Next Generation ?
How can you tell I'm a DBA? I'm up at 1:30 in the morning and have to get up at 7am in the morning. That's a learned habit, after heaven knows how many years of being in this business.
Now that could be a topic of yet another blog post someday!! The long term life implications of having become a DBA. Interesting.
I feel like this is the DBAs version of Tom Cruise's epiphany in Jerry Maguire :P
On a serious note, this is a great series, and this article has definitely changed my outlook and approach towards my work. Looking forward to the next one :)
I think the part of DBA 3.0 is the idea of communication, alot of DBAs are just content sitting in the cube and pounding away at keyboard. The need to develop those soft skills and become the people-type person.
Certainly, the DBA has a lot of responsibility, but I don't like the concept of DBA as guardian of data. It puts the emphasis in the wrong place. If you really want to guard the data, pull the plug and hide the disk drives in a concrete bunker. Also, a guardian brings to mind a static sentential like the Buckingham Palace Guards. They don't have to proactively do anything. They just stand their and wait for a problem. Instead, I prefer the more dynamic image of DBA as 'facilitator'. As a facilitator, the DBA takes an ownership in 'making things happen' rather than 'preventing things from happening'.
Development dbas are rare events, in this day and age of "outsource/offshore all thought processes to the cheapest provider".
Thanks for making me feel special, Noons :-)
In my situation, which I can't really evaluate as to how special it is, I administer production, do development, customize vendor code and implement cheapest provider solutions, with all the DBA work all those imply. But for most of it, Robert is right, I'm late to the balls. He's not right that it is my fault though, if management culture thinks hiring the guru who wrote "The Ant and the Elephant" is enough to make people want to inspire their workers, that's their fault. It just makes me want to write a parody, "The Ant and the Elephant On The Beach."
We must learn to change, we must learn to communicate, we must learn how databases work, why backups are important, why DR is important and learn to communicate that. We need to learn how to translate things like outages into dollars, which is the language that the business and management understands.
That is nothing new, it has little to do with DBA versions.
LOL! I linked the wrong elephant, it should have been this one.
First of all, Robert, I am glad that my comment added something to the discussion. But looks like what I forgot to do is to underline a key part of my "development DBA" role - direct communication with senior management. That point usually makes the whole process of being at the right place in the right time much simpler (at least from my experience).
I understand, that reasonably small and focused team in Dulcian is very hard to compare to corporate-level structures, but a number of times I've been invited as an expert to oversee (read "save") existing projects. In that case a notion of "the expensive specialist" made management ready to talk to me (and me talk to them) - otherwise they had a heartburn while looking at the bill. That communication process gave me a chance to be in the logical center of the development - exactly as needed.
Post a Comment