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

  • From: "Cary Millsap" <cary.millsap@xxxxxxxxxx>
  • To: <orclwzrd@xxxxxxxxx>, <sfaroult@xxxxxxxxxxxx>, <oracledba.williams@xxxxxxxxx>
  • Date: Mon, 24 Apr 2006 12:06:58 -0500

I totally agree.

 

If anyone is not convinced that DBAs need to be closely affiliated with the 
developers, I hope that my paper "Accountability for System Performance" will 
help tip the balance. I'm presenting it tomorrow in Nashville.

 

 

Cary Millsap

Hotsos Enterprises, Ltd.

http://www.hotsos.com

Nullius in verba

 

Hotsos Symposium 2007 / March 4-8 / Dallas

Visit www.hotsos.com for curriculum and schedule details...

________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of John D Parker
Sent: Monday, April 24, 2006 9:24 AM
To: sfaroult@xxxxxxxxxxxx; oracledba.williams@xxxxxxxxx
Cc: stephenbooth.uk@xxxxxxxxx; sam112233@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: Where should DBA's be placed in an Organization

 

I just can't resist any longer! The "artistic soul" comment is the critical 
part. Speaking from personal experience, in a previous company we fought tooth 
and nail to avoid being moved from the development side of the house to 
operations side of the house. We did exactly the same job in both places. The 
issue comes about when you remove the DBA from the development stream. This 
applies even if they are just implementing outside applications. Without input 
from senior DBA personnel, you end up with unsupportable production systems. 

I'm now with a Remote DBA service and I haven't built a system in over 3 years 
and just watching the grass grow and resizing a tablespace now and then, or 
getting handed a system that performs poorly because no DBA has looked at it 
since the developer hatched drives me almost insane.

It's critical in my humble opinion(my 0.02$US) that the DBA's need to be 
involved on the development end as well as the production end. If DBA's are not 
involved in the full process, you end up with the "throw it over the fence" 
syndrome, developers work in a vacuum unaware of production concerns, 
infrastructure gets handed poorly built systems that no one in management can 
understand why they don't meet response time and uptime goals.

John
(DBA, physical design, kernel tuner, disk layout, OS perf, etc...)
certifiable, not certified!


Stephane Faroult <sfaroult@xxxxxxxxxxxx> wrote:

I just loved Dennis' "artistic soul"! This is, I believe, precisely the 
heart of the problem. Many DBAs are fairly creative types (sometimes 
under constraint) but the name "administrator" doesn't exactly reflect 
this and rather conveys a 5-year-plan, soviet style vision of 
production. For developers, they are often nothing more than the folks 
who provide them with a fresh copy of the production database.
I know a place where there is a development DBA and a production DBA 
sharing the same office (both fairly interchangeable, by the way), and 
another one where DBAs belong to the infrastructure team, but where a 
few "transverse" folks, tagged "DB specialists" more than "DBAs" try to 
get a foot early enough in the various projects, with the help of 
"production DBAs" who market them. I like this model fairly well. As 
Dennis points out, the existence of canned applications means that the 
infrastructure team *needs* DBAs. Moreover, being with the 
system/network/storage guys allows DBAs to facilitate problem solving. 
As we all know, users call DBAs whatever goes wrong because 'the 
database isn't responding'. DBAs often act as dispatchers.

My 0.02 euros

Stéphane Faroult

Dennis Williams wrote:

> Sam,
> 
> I think both Stephen and Lee have good points. I would tend to agree 
> that putting the DBA in the development group can produce better 
> coordination with the developers. Gives the DBA better opportunity to 
> attend early design meetings.
> On the other hand, the trend is moving toward companies purchasing 
> most of their software, rather than "rolling their own". In that case, 
> the focus becomes developing a competent infrastructure group with 
> strong standards (development, test, and production environments) and 
> consistent enforcement of these standards. I would argue that in this 
> environment focused on infrastructure, putting the DBA in the 
> infrastructure group might make more sense.
> Then again, the DBA is an artistic soul not easily bound by 
> organizational confines.
> 
> Dennis Williams



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



 

________________________________

Yahoo! Messenger with Voice. 
<http://us.rd.yahoo.com/mail_us/taglines/postman3/*http:/us.rd.yahoo.com/evt=39666/*http:/beta.messenger.yahoo.com>
  PC-to-Phone calls for ridiculously low rates.

Other related posts: