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

They were/are going to do that at the last place I worked. I'm in two minds about it.

In it's favour dedicating DBA resource to development does improve the quality of both code and design. I like that a lot. I also like the idea that those responsible for development are also responsible for the release package being of sufficient quality and standard that someone who hasn't previously run it can do so successfully. I also am totally behind the idea that you don't let development into production (fighting that battle here, relatively easy with in-house staff, impossible maybe with 3rd parties).

I don't like the idea of having a team of just 2 (my last place had 4 permanent DBAs and part of the 'reason' for the split was that both production and development needed 3 dbas but didn't recognise it yet). A split of 2/6 suggests to me that the perception is that a 3rd of the workload is in test and development put together and 2/3 in production. It would be interesting to see if that reflects reality, I'd almost expect it to be the other way around but a review of support tickets/work records would show that assumptions truth or otherwise.

As far as not knowing what is coming, if the current culture is that development don't talk to production about a release schedule you've got bigger issues than who does what.

On the whole I don't think it a bad idea provided that the team is big enough in both areas and that dbas still get to work on what suits them (might mean mixing and matching the teams from time to time) so that you maintain the interest and career development of the guys.

On 12/12/06, Michael Kline <mkline1_at_comcast.net> wrote:
>
> I've got a client that is considering splitting devl/test and production
> at the DBA level.
>
>
>
> There are only about 8 Oracle folks, and that would put 6 on Production
> and 2 on test and there are about 70-80 databases.
>
>
>
> This all has something to do with a Gartner paper that was some 7-8 years
> old.
>
>
>
> Has anyone tried this before and what were the results?
>
>
>
> Migrating new code forward just sounds like it will be horrible because
> now TWO DBA's will be involve and probably be almost totally unaware of
> what's coming and the like.
>
>
>
> The strange thing is, this client is into "pools" big time where you get a
> DBA from the pool to work on what ever. That is pretty much how they were
> doing it now. Yet, being "in line" with this pools thing, they now want to
> make two pools and then make it so prod would have no access to devl/test
> and devl/test will have no access to prod. It reminds me of like WalMart
> type stores. "Sorry, that's not my department." It's got the DBA department
> quite concerned.
>
>
>
> The paper was supposed to say this was the thing to do, and perhaps would
> make SOX happy.
>
>
>
> Michael Kline
>
> 13308 Thornridge Ct
>
> Midlothian, VA 23112
>
> O: 804.744.1545
>
> Fax: 804.763.0114
>
>
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

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