Re: venting my spleen

"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 :-(