Trying to understand the "APM" roles

[MEBoatman]

When we implemented Enterprise Architecture, it was back in the days it was called "APM". At that time, we were not using the EA Workspace and we only had need for sn_apm.apm_admin, sn_apm.apm_user, and sn_apm.apm_read roles. Our roles are assigned via group memberships. So we assigned  sn_apm.apm_analyst to the same group as sn_apm.apm_admin.

Fast forward to today. We are on Australia. We want to start using EA Workspace more actively and I am charged with determining how to do that. In digging into that, I want to be sure that we still don't have a need to differentiate between sn_apm.apm_admin and sn_apm.apm_analyst.

My understanding up till now is that apm_admin was the "highest" access level, followed by apm_analyst. The apm_user role is essentially the update role and we assign that to IT App Owners. And the apm_read role is for everyone else. If I am interpreting this page correctly, that's essentially what it says: Access roles • Australia Enterprise Architecture • Docs | ServiceNow.

However, as I've started digging into this, I'm starting to question my interpretation. It appears that the apm_admin role is CONTAINED by apm_analyst. This leads me to ask - what is the difference between apm_admin and apm_analyst?

It appears that both apm_admin and apm_analyst can configure EA Workspace. What I was originally expecting to be able to do is assign apm_analyst to the rest of my team and leave me in apm_admin and then I would be able to configure EA Workspace and the rest of the team would be able to use it and do anything else that EA should be doing in the tool. But it appears that there is no OOB way to achieve that. Am I missing something here?

[sachinvic]

@MEBoatman 

Your understanding is mostly correct. In Australia, sn_apm.apm_admin is the higher-level role and includes the permissions of sn_apm.apm_analyst.

The important distinction is that apm_analyst is not simply a lower-level “admin.” It is intended for Enterprise Architects who need to create/manage portfolio data and perform specific governance activities, while apm_admin adds the full administrative/configuration capabilities for EA Workspace.

So you can keep your administrators on apm_admin and assign apm_analyst to architects who need the broader EA working capabilities but shouldn't have the full administrative access.

Also note that some capabilities require membership in the Enterprise Architect group in addition to apm_analyst; the role alone is not sufficient for those governance actions.

The current Australia documentation therefore does provide a meaningful distinction between the two roles; I wouldn't treat them as interchangeable.

[MEBoatman]

Thanks for the reply @sachinvic ! That makes sense to me except for one thing... In my PDI (a fresh Australia PDI with EA installed), the apm_analyst role CONTAINS apm_admin... And apm_admin does NOT have apm_analyst...

Hence my question and confusion...

[MEBoatman]

I'm not an admin (but I play one on TV 😁)... But I think I've captured the right version info:

Appears as though I have the latest and greatest installed. I also installed TRM and TPM... Oh and BCM...

[yogesh41]

Hi,

Thank you sharing your use case with us, it will be valuable input for us. 

Here is current approach one should follow to refer apm_admin over apm_analyst.

Use apm_admin as administrative role for users who need to set up and maintain the APM data model — defining application profiles, configuring metrics and risk parameters, managing classifications, and running assessments and certifications.  

Use `apm_analyst` as highest privileges users who need to both administer the configuration and consume the analytical output — viewing application scores, indicator scores, TPM risk scores, and the applications landscape to inform portfolio decisions.

We would like to here your perspective on it and any additional roles that you expected the application should supports. 

Yogesh