RE: Where should DBA's be placed in an Organization
- From: "Murching, Bob" <bob_murching@xxxxxxxxx>
- To: "'orclwzrd@xxxxxxxxx'" <orclwzrd@xxxxxxxxx>, "'sfaroult@xxxxxxxxxxxx'" <sfaroult@xxxxxxxxxxxx>, "'oracledba.williams@xxxxxxxxx'" <oracledba.williams@xxxxxxxxx>
- Date: Mon, 24 Apr 2006 10:47:16 -0400
Here, DBAs are part of neither application development nor
infrastructure/operations, but a separate group whose manager (me) reports
to our CIO. I don't think it's a long-term, sustainable model at this
particular shop. However, I do believe that it's the best model, or at the
very least an excellent one, and it's been a good run for us while it's
lasted. Within application development, DBAs tend to start seeing through
the lens of AD, or otherwise risk being dissenters within the ranks when
throwing out suggestions like "let's tune code before we buy more servers?"
in a room full of developers who report to the same person as the DBA does.
Within infrastructure/operations, same basic situation. When outsiders to
both, DBAs are uniquely suited toward being brokers for the dialogue on and
development of sound architectures. The only problem them is a loss of
authority - with little say over either the servers or the software, you've
got to make a case for that sound architecture and get people to trust your
technical cred enough to listen to what you have to say.
So, I'm in favor of packaging database administration, enterprise / data
security, enterprise / system architecture, technical analysis and perhaps
corporate data management into its own area.... a effective supplier of
vision and direction to the more execution-oriented parts of IT.
My 2 cents....
_____
From: John D Parker [mailto:orclwzrd@xxxxxxxxx]
Sent: Monday, April 24, 2006 10: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!
<http://us.rd.yahoo.com/mail_us/taglines/postman3/*http://us.rd.yahoo.com/ev
t=39666/*http://beta.messenger.yahoo.com> Messenger with Voice. PC-to-Phone
calls for ridiculously low rates.
Other related posts:
