RE: Why an organization would need an enterprise DB team

The split can work, but it's tricky. IMO, the worst set up is where there is no one with DBA knowledge working with the developers. We had previous management that tried to enforce that, it ended up with me giving advice and help under the table but a lot of bad design coming through that I had no power to stop.

For the split to work, there must be strong communication at all times between the operational and application DBAs (at which point why not just have them in the same group?). We have just had this split and the battle we're fighting is that we don't hear about anything until it's ready to go into production. We get emails like, "Project X is ready to go into production, please have the database ready for us tomorrow."

Our response is, "What is project X? What are the servers? Is there a DR requirement? What is the size, what is the expected growth, and incidentally the firewall ports aren't opened for us to access the server so you're going to have to wait a lot longer than 'tomorrow'."

Jay Miller  

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Phil Singer Sent: Wednesday, March 21, 2007 9:11 PM
Cc: oracle-l_at_freelists.org
Subject: Re: Why an organization would need an enterprise DB team

EPA wrote:
> Hi guys,
>
> I guess I was not enough clear. The coming re-org wants to separate
the DBAs
> between 1) operational (backup, recovery, upgrade...) and 2)
application
> (logical design, physical design,...) and move the 2nd group to
application
> services team. This means they will report and follow AS
managers/directors.
> And I would like to proof and keep them in one group.
>
> I don't have any doubt about having DBA competency in development
team, what
> I am looking is the cons if we separate the team and pros if we keep
them
> together.
>
>
>
> Thanks again,
>
> Estifan Panosian
>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.11/723 - Release Date:
3/15/2007
> 11:27 AM
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.12/724 - Release Date:
3/16/2007
> 12:12 PM
>
>
>

The company I work at does this (actually goes even further). I think it's a bad idea, although I don't have any reasons that would make sense

to a management type.

The reason I don't like it is that it has led to the "central" DBAs (the

ones who doe the backup/recovery/operational tasks) becoming very isolated from the actual applications, so they don't know the details of

how they are supposed to work. As a consequence, all Oracle Instances have to be very plain vanilla (or else they won't know what is going on).

Meanwhile, the application DBAs are unable to have the DBA role (since those tasks are reserved for the real DBAs). So there is very little experimentation going on. Sort of like Oracle evolution stopped with release 7.3.4.

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


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