I believe it's more than developers and architects; creating developer access, end-user access is one thing, but they/we are usually not involved with compliance, audit, segragation of duties,
In otherwords, during the traditional BW/ECC times
1) we had developers/end-users using the application to build/use solutions usually taking care of by application security teams.
2) we had DBA/BASIS teams to take care of tablespaces(no such thing in HANA), table adjustments, indexes etc..
3) we had change control boards/teams used to approve the usual changes knowing the impacts - now not very sure if for example approving a HANA revision upgrade, or SLT patch is going to impact the HANA ecosytems( HANA, SLT, Lumira server, HANA live etc...) adversely or not.-
4)GRC team to monitor usual activities.
5) And we had internal/external auditors who have built practices, methods for traditional databases over the years. Now with the options availabe within the HANA studio and security, a not very familiar person or extremely aware developer can do a lot - ea, a HANA admin can turn on/off audit trial and not many coompanies know if there is even such a thing.
So what I am asking is a gudience from SAP and feedback from others who have been using HANA while we're building our own.
That would be nice if we all particiapte and create a material
Tansu