Hi Nibha
I would try to argue the position the reason why enabler roles are bad and not just this is how I design/build. There seems to be a fixation wtih administrative overhead but no considered to security risk
Splitting out organisational values from other fields within in an authorisation is not best practise. It breaks the SAP Security Model for PFCG/SU24; upgrades/enhancement packs/etc. But more so, how are you able to restrict display and change access? Master data is a big one (and claiming you haven't given the transaction code is not going to be a guarantee that it's restricted).
Going from 10% to 100% transition to SAP calls out a need to revisit the security architecture. Part of solving this is to look at end to end provisioning as well as role build effort.
Personally, I don't like composite roles but am starting to revisit that view (in light of NWBC menus and IdM provisioning).
So, basically they have removed all organizational level object from other single roles which they have assigned to composite roles.
And added all org. level value to one single role with no activity (01, 02, 03.. etc..) in it.
Where does the Activity values go? Trying understand how they split out an object like F_BKPF_BUK.
is there any other better structure(s) that I could propose them without increasing number of composite roles.
Number of roles in isolation should not be the argument. Again, how is this being provisioned and what is the user base? If the user base is increasing then perhaps automated provisioning could be useful with derived/single roles.
Good luck on your argument. If you search SCN you will see this discussion come up a bit.
Regards
Colleen