Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Why an organization would need an enterprise DB team

Re: Why an organization would need an enterprise DB team

From: Robyn <robyn.sands_at_gmail.com>
Date: Mon, 19 Mar 2007 10:58:16 -0400
Message-ID: <ece8554c0703190758ue6b81d1qbf798e10d08001cf@mail.gmail.com>


I am liking the idea of 2 DBA groups more and more these days. I've always tried to stay involved with what's going on in development and share information with developers, and to work with platforms to design and implement a stable system, but it's getting harder and harder to stay on top of both sides. Add to that, some of the best DBA's for supporting developers aren't always the best at designing an architecture to support the full life cycle of the system and vice versa, and there may be good reason to have DBA's that are focused in one area or the other. We've got some DBA's that are really good at implementing a fast solution that addresses a business need, and they somehow manage to trash the overall architecture in the process or implement a solution that takes an enormous amount of care and feeding.

I've had this idea lately of the database as a platform - probably heard this phase some where else, but I don't recall where. Databases should be managed similarly to the way the OS is managed; consistent installs, patches, files systems and schemas. The components should be interchangeable - moving a database from one server to another should be seamless. Development DBA's could work with the developers to determine the best design, but it would have to fit the database platform architecture before it was promoted to production. SLA's and Sox are pushing us in this direction whether we like it or not.

And on the other side, understanding the business needs, the data and the latest development techniques is a critical skill set and working with the developers to visualize and implement the best solution is easier to do when you're not locked into a production support mindset.

The biggest drawback is making sure that we don't just move the wall that development work gets thrown over - if the development DBA tosses their changes to the production DBA without any real collaboration, the situation essentially stays the same with an extra layer of red tape in the middle. In theory, the two types of DBA's should be working together throughout the process, but in theory, the developers and DBA's should have been working together as well.

fwiw ... Robyn

On 3/18/07, Robert Freeman <robertgfreeman_at_yahoo.com> wrote:
>
>
> Just to chime in a bit since this is somewhat related to a presentation I'm
> doing at Collaborate...
>
> I agree with Dennis, we have to get closer to where the work is! We old
> DBA/DA types need to keep up. Data modeling really has not kept up with
> Object modeling well, and now with evolutionary development methods like
> Agile out there, we really are going to have to get caught up or we are
> going to find we will be left behind. I don't think that companies are going
> to be content to slow down application development so the database
> designer/architect/developer can "Get it right" up front anymore and we have
> to find a better way to work.

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Mar 19 2007 - 09:58:16 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US