Evert -

I hear what you are saying… but that sounds like a people/process/code organization problem to me? Like if that was my organization, I would be putting the roles in an extremely slim core functionality application so that they could be deployed without breaking other code in production, and let each team work with it on their own. If the teams are *truly* this separate, then they shouldn’t be shared code other than libraries, in which case you still look like “C”.

Really what “A” is, some something where you see the “Customers” Application having roles that only apply to “Customers” and the “Invoice” Application having roles that only apply to “Invoices” and so on. “Customers” and “Invoices” always end up getting so connected with each other, that the roles need to be partially shared at *some* point, thus “C” and not “A”.

So what I really mean here, is that you don’t have a sole security module per environment… but you have a sole security provider for a truly unique piece of functionality. Really what I am arguing against, is the overly-separated code that I see happening sooooo often. It just causes problems.

J.Ja