Re: venting my spleen

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