Re: Where should DBA's be placed in an Organization

  • From: sdlockhart@xxxxxxxxxxxxx
  • To: rhjulienne@xxxxxxxxx
  • Date: Tue, 25 Apr 2006 08:56:41 -0500

Randy,
It is a great idea to have the DBA's work with the Developers sooner than later 
regarding architecture issues, load issues, and the like.
One downside of having the DBA's "embedded" in with the developer troops is 
that the developers will ask to be instantly serviced regarding space issues, 
permission grants, etc. etc. etc.
This will skirt any established request hierarchy that may or may not already 
exist.

I've worked at several organizations that firmly believed in some physical 
separation of the DBA's and Developers by intent, so that ad hoc requests were 
minimized.

As a DBA, I personally preferred to be colocated with the Sys Admin ranks, 
especially if they have their own Operations Center environment.
That way, hardware issues, especially related to space issues, performance 
tuning, and backup/recovery issues could be worked on in a joint and timely 
manner.
But then, maybe the Sys Admins didn't like sharing their spaces with the DBA's 
either. :)

A nice compromise may be regularly scheduled meetings with the Developer ranks 
so that they do get adequeate time with the DBA's to discuss their design 
issues, coupled with a Request System so that user requests are made known. 
That way the DBA's physical location is less of an issue.

Regardless, its a thorny issue. Best of luck with your resolution.
Scott Lockhart

----- Original Message -----
From: Randy Julien <rhjulienne@xxxxxxxxx>
Date: Tuesday, April 25, 2006 8:04 am
Subject: Where should DBA's be placed in an Organization

> This question has been tossed around for many, many years.  Most 
> of the places I have worked tended to put the DBAs in their own 
> space, which is often between the sysadmins and the developers.  
> This always comes after hiring DBAs without any organization and 
> placing them as individuals on development teams.  The embedded-
> with-developers model creates havoc as their is no vision on where 
> the enterprise is going database wise.  The problem with 
> centralizing the DBAs into a group (and often placing them in 
> infrastructure) is the loss of early interaction with the 
> developers.  We have that problem now.  The developers come up 
> with hideous designs, load billions of rows, show management what 
> they have got, management likes what they see, the DBAs finally 
> get a look and it results in a rewrite because it doesn't scale or 
> perform.   
>  Overall, if you can get the developers to include the DBA team 
> during design, the centralized model benefits the organization 
> overall.   
>  Good luck!
> 
>               
> ---------------------------------
> Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously 
> low rates.
> 

--
//www.freelists.org/webpage/oracle-l


Other related posts: