Hello Peter We have an infrastructure division that divides into two departments: system programming and DBA.
Organization chart for us will be: CEO -> CIO -> Infrastructure -> DBA. Yechiel Adar Mehish ----- Original Message ----- To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent: Thursday, September 26, 2002 11:13 AM > > 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Yechiel Adar 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).
