I've found the thread on DBA workload valuable and interesting. It endorses points made repeatedly over the past years, basically the highly variable nature of the job.
This variability is giving us a small problem. Our dba work (shared between two of us) tends to function in the background, and of course because we do it so damn well (!!), our impact on the running of the organisation is pretty low. Kind of 'reverse exception' effect, if you will. There is now a desire to formalise the role of the dba function within the organisation, and nobody has the first idea of how to define, in an organisational / structural sense just how the dba role slots in. I'm talking about organsiational charts, herarchies etc, that sort of thing. Not just across the org, but particularly within the IT domain too. Specifically, dba impacts from the low-level hardware side, right up to application development, with everything in between. And that already spans several existing lines of management responsibility. Our problem has added spice as we are (trying) to operate a matrix management system, which repeatedly throws up intriguing political dimensions. Anybody ever been down this particular route? Any thoughts much appreciated, peter edinburgh ********************************************************************* This e-mail message, and any files transmitted with it, are confidential and intended solely for the use of the addressee. If this message was not addressed to you, you have received it in error and any copying, distribution or other use of any part of it is strictly prohibited. Any views or opinions presented are solely those of the sender and do not necessarily represent those of the British Geological Survey. The security of e-mail communication cannot be guaranteed and the BGS accepts no liability for claims arising as a result of the use of this medium to transmit messages from or to the BGS. The BGS cannot accept any responsibility for viruses, so please scan all attachments. http://www.bgs.ac.uk ********************************************************************* -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Robson, Peter 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).
