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