Re: Where does the DBA function sit in the organisation structure?

I think you hit it perfectly...  the DBA IS A GATEKEEPER.....................

Unfortunately, as such, and because many of them are overly concerned about preventing ANY change to the production environment, they spend far too much time telling developers all the reasons they CAN'T have what they want instead of figuring out a way to get it done.

The most successful projects I've been on in the past 5 years, have NOT had DBAs involved with the design or development... We designed the databases, generated the DDL and handed it to the production DBA to be spread around as they wished. We didn't care how many spindles they used, what they called the tablespaces, or how they tuned things, as long as they didn't change the names............... That way the design/development function and production DBA were separated. Naturally, the designers had test databases they created and managed to make sure the DDL worked, but the separation SIGNIFICANTLY reduced the number of battles between the two groups. The designers and/or developers acted as their own DBAs for the non-production systems...

Now, I suspect this idea grates on the extremely competent, very capable DBAs out there, so IT DOESN'T APPLY TO YOU. Instead, think about the paranoid, mediocre, or incompetent DBAs you've met. And think about trying to meet tight project deadlines in an environment where this person is guarding the gate...

A GOOD DBA is a jewel to be treasured. As such, they should be able to spend their time organizing, reorganizing, tuning, and insuring that the production environment is optimized. I've never seen any environment where there were enough DBAs to leave them with so much spare time they were able to juggle their real job with designing and developing other applications... Something ALWAYS got short measure...

"MMK Productions" <nospammmkprod_at_bellatlantic.net> wrote:

>I don't think it is as important about where the DBA sits, as how he is
>backed up.

>Situation:
> Developer: we need to make a change now, its an emergency!
> DBA: what/when/why/where...
> Dev: no, no, just do it
> Mgr: yes, it is probably fine, just do it, please

>Professionally, the DBA is a gatekeeper. In this realistic scenario, he is
>now a doormat. It is very important the the SOPs be set up, agreed to, and
>then enforced. When you do this, build into the rules the protocol for
>emergencies because we all know they will happen. The DBA has to know what
>he can and cannot do in these situations. No one wants to feel like they
>have been dismissed from the decision making process because of "an
>emergency".

>As a former developer, I know that it is no fun to have important changes to
>be held up for silly reasons also. So, the best interests of the env. must
>come first. I think that all of these concerns are best maintained when the
>rules are written down an enforced - and updated later if needed.
Received on Wed Nov 25 1998 - 09:20:35 CST