Re: Splitting production and development/test at the DBA level?

Splitting the two groups can be advantageous, in that it will naturally force your shop to:

1. naturally migrate into 4 environments for all your code and database related products (dev, test, uat/qa, prod).
2. force additional testing for all code in multiple environments and ferret out any weird installation issues far before it gets to prod
3. force more and better documentation, better installation instructions, forces the use of configuration management and version control for all your code, all of which are good things in software development shops.

But such a split only really makes sense in very large organizations that are sufficiently lifecycle-development saavy to understand the delays inherent to maintaining all the documentation overhead mentioned above.

If you're in a position where a few dbas work in all environments and want to move to a split group, the business process change will be difficult. It will be tough to get your star development dbas to relinquish control of the prod system and oracle user passwords. You'll suffer during production issues as a result, since the lead development dba usually is your lead troubleshooter. Just be aware.

my 2 cents, todd

>
> We had the DBA split at my last employer. The biggest problems we had were
> lack of communication between the two groups, unrealistic expectations
> from management, and policies/procedures for each group not clearly defined
> and documented. The split itself was not the problem.
>
> As was mentioned earlier though, I would definitely review the workload for
> each group to see if the proposed numbers for each team are appropriate. We
> had a fairly even split--3 production, 4 dev/test.
>
> Sandy
>

--
http://www.freelists.org/webpage/oracle-l