Managing too many Security Groups

[brinda.ts]

Hi,
We have an implementation that has over 470 Security Groups. Something tells me that this is not a good sign. It is getting too hard to mantain and manage. Is this common?
In our implementation, we have Cost Centers as an approval hierarchy in the Contributor. And there is a business need to give users access through individual Cost Centers. Hence, for almost every cost center, we end up creating a new group. Is there a way to implement this better?
What is a typical scenario in other implementations?
Any suggestions will be of great help.

[declanr]

If you have that mamy cost centres and people need access to only one of them then you are sort of stuck with a lot of groups.

Often users are linked with cost centres in a database somewhere else in your organisation anyway so thanks to additive security if that is the case you can automate assignment of users to group through TI and keep those groups separate from the rest of your security setup.

[lotsaram]

Having a lot of security groups is not necessarily a problem in and of itself. What matters is how the security model is maintained and users assigned and the performance if the model.

[jim wood]

I agree with Lotsa. Having many groups is sometimes something you can't get away from and when managed properly isn't an issue. What you have to think about is how you manage those groups. Obviously opening up the old GUI isn't going to cut it any longer. Also if you do use TI to manage the access / groups then you have make sure you keep the length of time that a security refresh takes. Is it quicker to insert access the details in to the control cube and then refresh or use security put? You'll only be able to say which method is better by experiementing. I guess it also depends on your down time window,

Jim.