Configuration Post Go-Live
Managing Change in the Production Environment
During implementation, you will likely be working with a consultant from Alemba to configure and deliver the ASM application. It's reasonable to assume you would be making these initial configurations in Production, but what happens after it has been delivered and your organization is using it on a day-to-day basis? How will you continue to keep the system updated and relevant, or even safely add new capabilities?
Audience: System Administrators/ASM Developers with sufficient rights to update, change, and configure ASM, ASM Screens, and ASM Workflows.
System Change and Configuration Options
Customers have two options after they take delivery of the ASM Application for how they will manage changes to the ASM application. Our recommended approach follows Option 1.
Immediate vs. Delayed Effect Changes
All changes to the production version of ASM have the potential to appear to the user's and analyst's with immediate effect. Many times we make immediate changes when the change is small and does not require testing or where UAT is not possible or may not even be necessary. Even with these types of changes, you should still log a Change Request if you are practicing Change Management.
Standard Changes that typically can be made in Production that do not need testing - These are a few examples (there can be many more):
You have been asked to correct the spelling or change the text of a label on a screen.
A workflow task is assigned incorrectly
You need to add Analysts to groups
An SLA needs additional criteria added, it needs a new expiration date, or renewal
Your organizations Business Hours change and you need to update the Hours Matrix
Delayed Effect Changes - Concealing Changes from Users and Analysts
Where possible, you will want to make changes only in PRD, test the changes in UAT, and then get approval prior to making the changes visible to the end users (Enablement) in Production. How can you begin working on a change in the Production system without exposing it to the Users or Analysts until it is ready? Make use of ASM's RBAC and other security features.
To do this, you will generally create special IPK Groups, Workflow and Approval Groups, special Subscriber Groups and Security Roles. The groups and their related RBAC and settings will effectively allow you to wall-off your changes until such time as you are ready to enable them. We will cover this in more detail later.
Changes That Can Be Isolated From Users and Analysts
Screen Changes
New Screens
Message Template Changes
New Message Templates
Workflow Changes
New Workflows
Workflows and screens tend to be large and complex and we wouldn't want to manually set them all up in both environments. In this case, we will do the build in Production and then copy PRD down to Test for UAT. We will simply shield it from view in PRD until such time as it has passed UAT.
If QA rejects the build, you will get your list of defects, fix them, and then copy a fresh image of production back to UAT for the next test cycle that includes your fixes.
UAT issues are fixed in the source, Production, and a fresh image is deployed to Test.
When to Break the 'Rules'
Few things are ever totally black and white. There is often a grey area and developing in ASM is no different. Some changes, particularly those that impact the Portal Skins or behavior, or integrations should be made in UAT when there is no test cycle running (e.g., when UAT is dormant) and the change validated against any unintended consequences.
For example:
Portal Skin and Styling Changes cannot be hidden from your end users unless:
You have created a test Portal on the Production system
Only Developers have access to that portal
You are not changing and global style sheets or default image files in the file structure of ASM (changes in the GUI are fine)
**Changes to global style sheets or default image files in the file structure of ASM will be immediately available and should be avoided in production until they have been tested.
Service Catalog Changes unless:
You have created a test Portal on the Production system
Only Developers have access to that portal and the Service Actions being changed, e.g., you are not changing "Live Actions".
Service Level Management Agreements unless:
The Agreement is inactive AND
You do not intend to test it before making it active
Message Type Maps (Setting which email goes out and when)
Some small changes probably can be made without testing, such as Message Subjects or updating templates to message types, however
A major overhaul should be accomplished in the Test System First
Subscriber Groups unless:
You are merely maintaining an existing group such as
Adding or removing subscribers
Federated CMDB actions (this does not include general and normal maintenance and record keeping)
Integrations, mapping, sources, etc
Critical or Global System Administration Settings such as:
System Security and Protocols (e.g., enabling SSO)
Partitioning
Screens and Template purges
CMDB Item Type Cleanup
When you are sure of the safety and the intended result, you can make the immediate change in Production.
When in Doubt - Test it Out!
Imagine if you changed an integration in production and suddenly wiped clean thousands of records? Better to make that mistake in the UAT environment. If you blow up the Test system, you can simply have it restored.
Typically, its not too much trouble to make the changes listed above in UAT to test them before then going to production and recreating the settings manually once you are fully aware of the consequences and validity of the change..
Last updated