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!