Archer Administration Vs Archer Development (Segregation Of Duties)
My management have asked me for definitions and responsibilities of Archer Administrators and Developers. The difficulty here is I am a one person operation who inherited the app from another one person operation so these distinctions have not been necessary since I perform both functions as needed.
My first reaction is to say if it needs a package then that is development but as you know, you can do most things in production as an administrator and packaging is used when you want perform development type activities in the correct order and test the functionality in the development environment prior to production with also keeps the GUIDs in sync between the DEV and PROD Environments.
This is what I have so far:
- Full Prod Access/ Read-Only Dev Access
- Reviews developed packages and promotes them to production
- Makes requested field, notification, report, and iview adjustments as needed in both Dev and Prod when they arise
- Maintains system security and creates or updates existing access roles as needed
- Read-Only Prod Access/ Full Dev Access
- Reviews development requests for level of effort estimates
- Produces Proof of Concept applications or advanced existing application modifications in the Development environment for any approved development requests
- Produces any Dummy data or gets prod refreshed data to present the new product to the business and the Archer Administrator
- Creates Test accounts to validate security and updates access roles as needed then includes them in the package with an explanation of what changed.
Please let me know how this differs from your understanding of the differences....thanks
Check out this presentation by Doug Campbell from Charge 2016: Don't Just survive - Thrive without System Admin access!
What you've listed aligns with what we defined in a prior role of mine, but definitely agree that in one-person shops, you are both. I assume they have an issue with the full PRD access. Could you set yourself up two IDs, and the one with elevated rights to PRD you have to check out through some process that logs the reason and in/out times?
We are also quickly getting closer to having to deal with this issue of role separation. I have to chuckle, because I feel like everyone is starting to run into this problem.
Anyways, I have started to actually try to go even further (with the understanding that you may still need someone wearing multiple hats, simply because that's is the only resource available).
Essentially where you just have an administrator, I would break that up a bit further. i.e. One person is the classic system administrator, but another who is more of the configuration manager or SCM. This person is the one who does have some administrative privileges in production. This helps differentiate who can actually apply Archer changes (and also provide a gate keeper) from the someone with local admin access to a server.
I've also included an Access Control Administrator. In the long run, you just simply can not keep up with that on your own and the work needs to be trained and farmed out. By having this role separate from a configuration and system admin, you maintain a check/balance on overall access as well.
Not sure why you'd have an administrator only have read only access in Dev? You would need someone who has full rights to both environments, and I'd think that you'd have the admins as that, right?
As companies grow and mature with Archer, most eventually reach a point where their corporate policies mandate they have to segregate the duties of the platform. Someone who can develop a new, or modify an existing, application should not be able to promote to production. Similarly, someone who can modify production should not be able to develop. This forces a hand-off and review process from developer to admin in order to move something to production as a form of change management control.
We're creating Development, Support, and Deployment roles. In some cases, someone may have more than one.
What is frustrating is that we have not figured out a way to give someone Read Only access to application builder in order to view configurations in production (for support purposes) without allowing them to change them. I have tried making access roles that only have "read" to application builder, but then you can't do anything other than run reports, which is not very useful.
There is a way to do this, as we did it at my old company. It involved creating a Group for every module, or group of of like modules, and then assigning only that group as the App Owner. Let me double check on the role permissions required and I'll get back to you.
Just tested in my local environment, and the following worked to provide read only to app builder for Findings as an example.
- Create a group called "SoD: Findings".
- Create a role, auto-assigned to the group, "SoD: Module Reader".
- Assign role with Read rights to the following pages under the Application Builder application:
- Manage Applications
- Manage Questionnaires
- Manage Sub-Forms
- Add the group from step 1 to the Findings module as an Application Owner.
- Add user(s) to the group from step 1, and they will get read only to see the app config.
A few notes:
- I suggest creating one group per module that you have, and then anytime a new module is made you have to make a new group as well and assign it as the App Owner.
- This model assumes that the users are not in the System Admin role, or any other role granting them more than read access to the listed pages. If they are, permissions are optimistic and they will get the extended permissions.
- Anytime a user needs to see another module, they just need to be added to the group for it.
Scott - that's really close to what I'm trying to do, however adding as Application Owner gives the admin access to potentially sensitive data, and that would fail audit.
Hi Andrew, did you find a solution for this? We have the same issue and adding a group as Application Owner gives it access to the records.