Archer Governance Practice
I am developing a governance practice for Archer and wondered if anyone had one in place already? I’m looking for more of a roles and responsibilities type of practice rather than how-to. Also specifying the flow of imports into the different environments, etc.
-
We have a chartered steering committee with representation from each of the functional areas utilizing the platform (solution areas). It is chaired by the project/platform owner. Defined roles include the Steering Committee Member, Archer Admins, Configuration Admins, and Users.
Changes are proposed and voted on by the members who each have one vote.
Regarding the flow of imports do you mean raw data from other systems/sources of truth or w/in the Archer environment?
0 -
Hi! Thank you for the response. Do you have a physical document that you would be willing to share with me for the charter? I can share my email if need be.
In regard to your last question, I am talking about moving packages from each environment and the correct flow they should be moved DEV - TEST - PROD. We would like to be as specific as possible in our guidance.
0 -
I have a word file I could scrub and share. I'll send you a message with my email.
0 -
Hello, in regards to packaging, there is much to consider. We have 3 environments. 1. DEV- this environment is where all the Unit Test, Development and everything else goes until your software, updates, etc. are ready for packaging. 2. TEST- this environment houses the User Acceptance Test portion where all your Stakeholders and others get to 'test' the product and give a thumbs up that it is ready 'as-is' to Production. 3-PROD- your production environment where all will use the product.
What does it mean "Ready for packaging?" It means, everything functions as you intend it to. All emails (ODNS) are triggered and emailed out. All ACTION button (if using an advanced workflow, if you are not, disregard this post.), are visible and function when clicked on as well as any DDE's (actions/rules) associated to your layouts work as well.To consider this, you must know if an existing version (older where the newer is being deployed as an enhancement or you are deploying fixes) exists. If NO, then you are set to package up. Also, SaaS versus On Premise is something else to consider. SaaS (Software as a Service), the system itself will always be at the most recent version. However, the Use Cases, and anything else you downloaded to be installed will not be unless you keep it recent. You may need either Support or Professional Services to assist with this one, because they can provide a list of what you have and their versions so you can make an educated decision before packaging up. Now if you are On-Premise then you may have to figure out what versions you have to ensure all environment match those versions. Your TEST environment should mirror PROD. Your DEV environment should mirror TEST. Only exception is when you are developing or fixing in DEV then your versions will be out-of-sync until you get your updates(fixes/enhancements) into Test then into Production.
You always want to package from your lowest environment first. This will provide several benefits deploying into TEST. 1) You will gain the experience of packaging and what it will take to deploy into another environment. 2) Also you will get to experience what may occur when deploying to prod. Another Excellent reason to ensure your environments mirror each other. 3) If it does not go well, you can resolve in DEV and then redeploy back to TEST - OR you can restore TEST (forgot to mention this. Always Back up before deploying), using your back up package to what it was before you deployed to TEST and start over.
One last thing I will mention, because I experienced it and it is not fun to unravel. Make sure all your fields 'match' meaning IF you have an EXISTING version in your TEST environment and you are deploying Updates, enhancements, fixes, etc. the fields Must Match. If you do not ensure this, you will have extra fields and other fields populated with content that you though you were mapping correctly and did not. This is a nightmare.
Another thing to consider is if anyone else is "working" in those environments - be careful to ensure you are not impacting them or them you.
There is good information on packaging on the online help. Moving packages from each environment and the correct flow they should be moved is exactly as you typed it. From DEV to TEST then to PROD. As for the specific fields and items you should choose, the developer or person who is providing the fixes should have a great idea. Online help was my friend for many months. Hopefully it will be good for you too.
Just sharing my experiences. Hopefully it was not too much.
0 -
I would be interested in this doc as well if you wouldn't mind sharing with me too. We are similarly working on documentation and a steering committee and this would be extremely helpful. Thanks!
0 -
Hi! Thank you so much for all of the information you provided. I am developing a procedure and am mainly looking for inspiration as to what all to put in there. I am a certified Archer Admin Specialist and work in there regularly. The issue is getting it all out of my head and onto paper. Does your business use a document like this?
0 -
Sure - let me clean it up a bit this week and I can post to this thread.
0 -
Thanks Linda, this is a great overview. For your organization what is the delineation of responsibilities between Archer admins and your organization's IT group? Is UAT testing facilitated by the Archer focused group or the team within IT?
Ryan
0 -
I have started and stopped. Like you, it never seems to get ‘fully’ out of my head. I am extremely technical, which makes it even harder. I can provide a few ideas to get you started. I would recommend 2 documents. One for you, the other for the Super User.
Online Help is your friend: Here is a link to get you started: https://help.archerirm.cloud/platform_615/en-us/content/search.htm?q=packaging
- Know your Audience – who are you writing for?
- Before you begin – Pre-Requisites
- What do you want to deploy? (i.e. Application, Questionnaire, etc.)
- Is it leveled? Are there any permission fields, Global Value Lists Fields – was it promoted or left as-is?
- If Application: Run thru a quick Unit Test (or UAT (User Acceptance Test)) Ensure everything is the way it needs to be.
- Back up your database – very important
- Know the Packaging Rules
- Create the Package (Easy to begin – hard to map)
- Anyone who has been in it as long as we have should be able to grasp it. If not, they can use the online help or reach out to you for assistance.
- Generate the package
- See Reviewing the Package Installation Log
- This will be easy, once the package is generated, then review the log. When I did this the first time, I inspected every line. Then I knew at that point on what variances to look for, what to dismiss, and what to be concerned about. I have learned this experience is unique to each instance.
- Then download. Upload into the Target and install.
- Parent and Child Object Mapping
- Here is where it is tricky. Source fields should match Target with minimal exceptions – if this is a fix.
- Best if New Source to an empty canvas (if you know what I mean)
Then you can begin with one for yourself – Troubleshooting. Because that’s where the issues hide is in the experience. Document them. Afterwards you can begin a Knowledge Base.
I’m looking forward to what rplong is going to provide. I have struggled, to map a good one, but I always get too much down into the weeds. Hope this helps a little at least.
0 -
Hi rplong, thank you. I am still learning, seems never ending with Archer, but I enjoy it immensely! We are using SaaS so Archer maintains the platform upgrades and we maintain the Solution/Use Case versioning. IT is not involved unless they are needed to assist in development. Makes it super easy for them and places the responsibility onto Archer.
0
Please sign in to leave a comment.
Comments
10 comments