Question (somewhat long): Guidelines for collaboration in Oracle shops.

I would like to hear some general guidelines from experienced Oracle shops out there as to how members of an Oracle team can successfully collaborate.  Specifically, what job titles exist within your team, and how are various tasks mapped to those titles? My personal experience has been that many IS managers are non-technical/non-involved and leave issues of who does what and when to their staff to duke it out amongst themselves. In the worst case scenario, things get done according to who knows the passwords, rather than according to policy and consensus.

I have recently been reading "Oracle Design" by Dave Ensor and Ian Stevenson from O'Reilly. This excellent book seems to echo the paradigm suggested by the names of Oracle products -- there are "Designers", "Developers", and "DBAs". This seems like a natural breakdown, but specifically what does each of these roles do? Is there a hierarchy implicit in these titles? I read a comment in Oracle's "DBA Handbook" to the effect that "for DBA's, managing developer's is like herding cats". True perhaps, but, excuse me, why would DBA's be managing developers?

My own experience is that Oracle is a new product for many shops in my region (the Midwest). A company typically purchases an Oracle license and hires a DBA all in one step -- knowing for certain that this immense chunk of software will not run itself. Or, alternatively, an existing staff member is sent to a week of DBA training. Beyond these actions, no other structure is established. Is the DBA going to be in charge of disaster recovery and I/O tuning? Is the DBA going to design databases and establish coding conventions? Is the DBA going to collaborate with or run the applications team? The answer seems to be pretty much up to the DBA.

How are your teams structured? Received on Sun Sep 07 1997 - 00:00:00 CDT