A "development DBA" is a developer who wants to design the schemas his/her
application will rely on.  I prefer calling them application designers,
because that's what they are.  Sometimes you have another role, that of
"Application Administrator."  This second group is for larger applications
that sometimes require constant attention, esp. if user accounts have to be
created, or custom views etc. ... or if the application wasn't ready for
production and was placed into production anyway -- then it will require
constant babysitting.

Consultants come in usually to implement new projects, or to add features to
an existing system.  That makes them application designers or application
developers.  Sometimes (rarely) consultants are hired to tune systems, that
would be a blend of DBA and application designer.  This is rare though,
usually the database layer is working properly it seems to me, if the DBA
has been there for more than a year, has read a book or two, and has at
least the echo of a conscience.

A "production DBA" is responsible for ensuring that the structure beneath
the application stays up and is tuned properly.  He/she works with the
system administrator(s) to ensure that the hardware and the Oracle software
(rdbms, developer server, iAS, networking,...) are all working properly and
as expected.

I don't fully understand why developers (some developers) strive to be
called a DBA.  Here is my guess:

Perhaps this distinction stays fuzzy in organizations because there is a
constant tug-of-war for control over resources between the development and
production groups.  If an overlap can be created, then there is an
opportunity to take over some of the other group's resources.  Also, when
responsibilities are not delineated clearly, there is an opportunity for one
side to blame the other and management can never figure out who is doing
what.  I worked in a lab where we were implementing Good Laboratory Practice
(GLP) for the Food and Drug Administration (FDA), there was supposed to be
no overlap between positions.  I noticed that the managers who played games
and only thought about their own advancement didn't like GLP at all, they
fought it tooth and nail.  I liked the idea of separate each person's circle
of responsibility myself.  Why can't IT shops strive to do the same?

Speaking as a DBA, it is my perception that developers tend to be
project-oriented.  That's fine, it's why they are there.  But that tendency
also means, when they see their deadlines coming, that they sometimes aren't
keen on thinking long term.  Perhaps it's not their fault, it's because of
the way projects are funded.  Which client wants to hear that for every
project, money will have to be allocated for ongoing costs of maintenance,
operation, upgrades every 2-3 years?  No one wants to think about that when
they only want to think about the great new things they will be able to do
with the new application.

Also, no one wants to spend more money than necessary, so there is a
tendency to try to cut corners to get to the end of the project.  That is
probably why projects tend to be rushed into production.  Once the projects
are in production mode funding to finish the product dries up.  That
sometimes leaves the application designer off the hook and leaves the
"production DBA" holding the bag.

Finally, if you are designing a new project, the tendency is to try to
retain control over as much of it as possible.  If you declare yourself to
be a "development DBA", then people are less likely to insist that you
consult the DBA(s) during the design phase of a project.  "What a bother
that is, having to listen to other people -- it's "my" project!  It will
only slow us down... Worse, I will have to share the credit once the
application works properly.  That won't be as good for my career."  If you
know that the DBA in the organization is stubborn and intractable, then this
is the route the application designers will try to take.

I could draw up a list of things that can go wrong when DBAs are not
involved in the design phase of a project, but I think all people need to do
is brainstorm for ten minutes to get a list of 10 or more things that can go
wrong...  Then try to put a cost value to each of these items.

Can you think of any examples from your work place?

; )

Regards,
Patrice Boivin
Systems Analyst (Oracle Certified DBA)

[this is my opinion, not the opinion of my employer... etc. etc.]

-----Original Message-----
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 4:29 AM
To: Multiple recipients of list ORACLE-L


Hi Listers,

        I would like to know the differences between Development and
Production DBA w.r.t. Roles and Responsibilities, Scope etc.  Is there any
difference in the role(s) played by a DBA in OLTP and DSS environments?
Your invaluable viewpoints in this regard is most welcome.

Thanks and Regards,

Ranganath
WARNING: The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee.  Access to this message
by anyone else is unauthorised.  If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message in
error. Thank you.
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Krishnaswamy, Ranganath
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boivin, Patrice J
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to