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

Home -> Community -> Usenet -> c.d.o.server -> Re: Where does the DBA function sit in the organisation structure?

Re: Where does the DBA function sit in the organisation structure?

From: Neil Hulin <nospam_at_*NOSPAM*litech.freeserve.co.uk>
Date: 1998/11/19
Message-ID: <731aje$g9o$1@newsreader3.core.theplanet.net>

Hi Brian,

One of the best organisational arrangements that I've worked in had the DBA separate from the developers, under the operations manager, but the roles were closely coupled. The DBA was solely responsible for the DBA function. In a small shop this could be shared but you have correctly pointed out that conflicting requirements arise.

You don't mention UNIX systems admin in your note. Is that done separately, or does the DBA own that as well?

Reasons for keeping the DBA separate from development:

  1. Keep the developers honest - in reality this means being removed from the problems sufficiently to provide an unbiased technical evaluation of proposals. Too often, developers will be a long way down a dead end path before admitting that they've got it wrong - this is not a slight on developers, its just a fact of life. A DBA who is close to the developers (but not under the development manager) will be able to identify this long before your budgets and deadlines are blown.
  2. Allows the DBA to investigate technical alternatives and the trickier problems that development face without being under pressure to deliver "something". This can provide unquantifiable benefits, but benefits all the same.
  3. Allows the DBA to keep up with advancements in the product set that may have a direct influence on the project at hand. It certainly allows the DBA to keep up sufficiently to ensure that they understand the implications of the version of Oracle that the product will be delivered on which may be quite a bit more advanced than what is in development.
  4. May help avoid the developers wasting time chasing RDBMS versions as the DBA can be unbiased in the evaluation of "supposed bugs" discovered by the developers. In this case the DBA performs independent checks on these "bugs" and liaises with Oracle for their resolution. The DBA can also reduce development downtime by being able to plan the migration of the RDBMS through versions during the development cycle. Too often I've seen developers want to down tools just to get the latest Oracle release in whether they needed it or not.
  5. When it is time to migrate the app from development to UAT/System Integration/Functional Test/whatever the development team aren't slowed down by this activity as it can be handed off to the DBA to perform a clean build of the development deliverables into the target environment. This helps focus the development team on their deliverables. I've experienced so much hassle in the past with developers not even knowing what their deliverables are - let alone being able to produce something that can be built in a clean environment.
  6. The DBA can become the central point of feedback between the testers and the developers because the DBA basically "owns" the application once it has been delivered from development. This again aids developers reducing the background noise that they have to deal with and simplifies development management by keeping the feedback centrally managed.
  7. Once the application becomes the property of the DBA, the DBA can put on their "Operations" hat. This means that they now have all of the deliverables and the experience to package the application for delivery to the final customer. There will be no surprises when it comes time to do a complete install. By way of "Operations" hat I mean all the things that developers assume will be taken care of by someone else (they really mean the DBA or System Administrator, but won't admit it). The DBA in this case could be the most suitable person to address these issues - things like datafile layouts, table storage parameters, data conversion environments, cron jobs, actually getting batch interfaces to work (they never do when first delivered - don't know why but they don't, even when they've had a dedicated development team working on them), etc.
  8. The DBA becomes the primary interface to the Systems Administrators reducing their workload by giving valuable insight into the workings of the application. A good DBA can get an Oracle to work very well on UNIX but I've met few true-blue UNIX administrators that even cared about Oracle, thinking it to be "just another application". In this situation a good dedicated DBA can be the difference between success and failure for a project at least from the customer's perspective.
  9. The DBA can keep ahead of the backup and recovery issues for the developers without requiring the developers to impose their own discipline. Most of the problems I've experienced supporting developers have been "finger problems" and the ability to recover a single table without wasting the DBAs time is important. Without someone owning that issue you could loose valuable development time.

I realise that I'm opinionated. I've only worked as an Oracle DBA and UNIX systems administrator for about ten years (since the days of Oracle 5.1.11 and HP-UX 3.2/6.5). I fully expect to upset some developers, and possibly some system administrators by what I've said. As a DBA I know where I would like to be in an organisation to provide the best value for money and be in the best position to help the project succeed. Maybe you can guess that from what I've said here.

--
...neil {actually: neil [dot] hulin [at] litech [dot]
freeserve [dot] co [dot] uk}
Received on Thu Nov 19 1998 - 00:00:00 CST

Original text of this message

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