The KIM group and role BOs both have memberships mapped with JPA annotations so the membership information is fetched whenever one of those BOs is retrieved using JPA. This is a significant performance problem when the group or role becomes large. At IU we have a few roles which have tens of thousands of users so whenever one of those role BOs is retrieved it causes a significant performance hit. It would be better if unbounded collections like these were not mapped up directly and instead went through a new API to explicitly fetch the role membership which is needed at any given point in the code. This will likely be a major refactor since the membership seems to be referenced in many different places in the code.
A while back IU contributed a performance improvement which includes the RoleBoLite class. I'd think that you could do away with that since it would be exactly the same as RoleBo once the membership mapping is removed.
Analysis: Review changes from RoleBoLite; Provide details on refactoring; Review for any impact for other projects