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

You know, I think I may have seen almost the full spectrum on this issue.

I have seen development environments where a simple SELECT statement could not advance beyond UNIT test without first being reviewed, approved, and rubber-stamped (literally) by the DBA groups.

I have seen development environments where the DBA's first involvement in the deployment of a new application comes in the form of a request to add a tablespace to the production database (on "go-live" day!). I have seen a whole bunch that lie somewhere in between.

In general, I find that those environments where developers interact with DBAs at the earliest stages (ideally, no later than initial stages of physical data modelling) tend to have the greatest success. In fact, having seen it done (at least once) I would even dare to suggest that mandatory DBA review/approval of schema designs would be a good idea. Sadly, in most places, this is such a hard sell, its as good as impossible...

I can very definitely say that oraganisations that do not involve DBAs in the design process until it is time to create the the production tablespaces are pretty much begging for disaster.

On 4/25/06, sdlockhart_at_bigplanet.com <sdlockhart_at_bigplanet.com > wrote: 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_at_yahoo.com> 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.
>

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



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