Oracle-L: RE: Slightly OT: Development Vs. Production DBA

From: Webber Valerie H <Valerie.H.Webber_at_irs.gov>
Date: Tue, 28 Jan 2003 09:08:53 -0800
Message-ID: <F001.0053C342.20030128090853@fatcity.com>

I agree 100%. I am fighting this battle as we speak. Many Duhvelopers think they can do it all until something goes wrong then guess who they call to bail them out. Then Damagement is breathing down your neck to get it fixed when you have no idea what happened.... neither does the Duhveloper!

I think an organization needs to have clear policies in place and enforce them to the end.

Valerie H. Webber
Management Systems Designers, Inc
Database Administrator
valerie.h.webber_at_irs.gov
704-566-5321

-----Original Message-----
Sent: Tuesday, January 28, 2003 8:04 AM
To: Multiple recipients of list ORACLE-L

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:Ranganath.Krishnaswamy_at_blr.hpsglobal.com] 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: Ranganath.Krishnaswamy_at_blr.hpsglobal.com

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: ListGuru_at_fatcity.com (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: BoivinP_at_mar.dfo-mpo.gc.ca

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------

--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: Webber Valerie H
INET: Valerie.H.Webber_at_irs.gov

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------