Re: venting my spleen

Ed Stevens wrote:

> On Tue, 25 Jun 2002 20:56:31 +0100, "Niall Litchfield"
> <niall.litchfield_at_dial.pipex.com> wrote:
>
> >"Ed Stevens" <spamdump_at_nospam.noway.nohow> wrote in message
> >news:3d1883ad.4962926_at_ausnews.austin.ibm.com...
> >> Part Duex.
> >> This gets scarier by the minute! Since my first posting, the team lead
> >has
> >> called us about every 30 minutes. Now it turns out that they have scripts
> >for
> >> createing the tablespaces themselves -- even to the point that they insist
> >on
> >> naming the files . . . and scripts within scripts within scripts, so that
> >they
> >> are reluctant to ("Can't") change anything.
> >>
> >> I know from past experience that DBA will have no weight at all against
> >the
> >> development team, and yet will be expected to make this all work when it
> >goes to
> >> production. The best I can hope for is to start educating my manager and
> >going
> >> on record with the anticipated problems.
> >>
> >> Additional input anyone?
> >
> >I think that my *stand* if such it were would be to try and determine some
> >ground rules. I'd pitch for the following.
> >
> >1. Full documentation and build procedure for the app. That means full which
> >table is used for what purpose, what the estimated data volumes will be etc.
> >
> >2. What you as a DBA are allowed to change and what needs to be sent through
> >to the vendor for support. ISTM that if you cannot name and place files
> >yourself for example any space monitoring actions you might wish to take
> >would have to be passed by their tech team as part of the support contract.
> >
> >3. That performance tuning should be the reponsibility of the supplier under
> >the support contract.
> >
> >4. That application setup and configuration management should be the
> >suppliers responsibility.
> >
> >In other words that you will be a babysitter only for the database - perform
> >backup check thats it is running etc - *under the present regime*.
> >
> >in the same document you should offer to work with the software engineers
> >from the supplier (nb this may well not be the implementation team) on best
> >practices in your nvironement and for your customisations.
> >
> >What I'd hope to get out of all of the above is official recognition that
> >one of two things apply.
> >
> >either the whole thing is the suppliers responsibility under contract; Or
> >
> >that you are a competent DBA and that supplier and purchaser should work
> >together each recognising each others strengths. .
> >
> >In other words I'd want to be positive and proactive but to suggest that if
> >the system is implemented over your head without your involvement you cannot
> >be responsible for it. A savvy supplier will want to build a relationship
> >with you because you are one of their best hopes for understanding the
> >client and its data. A warning that says I want to work with you but treat
> >me as a professional may well work wonders.
> >
> >
> >--
> >Niall Litchfield
> >Oracle DBA
> >Audit Commission UK
> >
> >
> >P.S. Its always interesting to ask suppliers/consultants for an ERD and a
> >text description of the purpose of each table. They know they should be able
> >to do it but somehow they can't quite find the docs.
> >
> >P.P.S. This doesn't apply to in house projects obviously because then you
> >might have to document your own practices and that would never do :-(
> >
> >
> Nial,
>
> I certainly appreciate everyone's response. This particular response gives me a
> workable (in my situation) course of action. I'll spend some time today working
> on "request for information" list to give to the lead consultant. I think I
> will also have an informal talk with the project manager, just expressing my
> concerns and letting him know that he needs to keep a close eye and short leash
> on the consultants. He has a technical background (programmer/analyst,
> part-time DBA) and I've worked with him off and on for many years and have a
> good relationship with him. We'll see how it plays out. I'm actually rather
> surprised at the amount of response this has gotten from the group. I'm sure
> I'll be back here to vent some more before this is over!
>
> Thanks to everyone for listening!
> --
> Ed Stevens
> (Opinions expressed do not necessarily represent those of my employer.)

Please don't come back and vent. We are not a support group. We are not trained psychologist. We don't prescribe Prozac.

If after trying your best to correct the situation, should you fail, be pro-active, find another job, and walk out the door. It is a job ... not a commitment 'til death do you part.

Daniel Morgan Received on Wed Jun 26 2002 - 12:13:59 CDT