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

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_at_yahoo.com] Sent: Monday, April 24, 2006 10:24 AM
To: sfaroult_at_roughsea.com; oracledba.williams_at_gmail.com Cc: stephenbooth.uk_at_gmail.com; sam112233_at_gmail.com; oracle-l_at_freelists.org 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_at_roughsea.com> 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

--
http://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.


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