ServiceNow is pioneering the way forward when it comes to change modernization. Over the past few releases, we have introduced dynamic Change Approval Policies allowing teams to easily tailor automated approvals to individual change conditions. In Paris, Change Success Score delivered numerical expressions of each team's change success history similar to a karma or credit score. In Quebec, we introduced another level of automation with Multimodal Change (Change Models) to deliver “fit-for-purpose” change combined the ability to leverage ML to predict change risk using Now Risk Intelligence capabilities.
The benefits of change automation are further realized with recent enhancements to Affected CIs and the Refresh Impacted Services capability. In Rome, we added support for Dynamic CI Groups as target CIs (Primary and Affected) and we have added a related list for Impacted Business Applications to reflect the full impact of a proposed change. The ability to accurately assess change impact using automation is vital when it comes to finding that exact balance of velocity, stability and governance. Unplanned change related outages are avoidable when the change impact is known. To fully leverage the power of this capability, it is important to understand the difference between Affected CIs and Impacted Services.
Change Properties
There are three property settings on the Change Properties page that ultimately determine how Impacted Services and Business Applications are derived. The records in the Impacted Services/CIs, Business Applications, and Service Offerings related lists are updated according to these settings.
The first property in the screenshot above change.refresh_impacted.include_affected_cis property is key when it comes to the behavior of this feature. In short, if this property is set to yes, all the services from svc_ci_assoc table are retrieved. If the property is set to false, then services are retrieved from CIUtils script include.
Before we dive any deeper into to the specific flows and outcomes associated with the related methods and properties, let's make sure we are all aligned on the key terms associated with this important capability.
Affected CIs
The Affected CIs tab is where a knowledge worker can add one or more CIs that will be influenced or touched by the proposed change. Since the CI field on the record represents the primary or target CI for the change, we add that target CI to the Affected CIs related list automatically. Additional CIs or Dynamic CI Groups can be added to the change request via the form view (Target CI) or via the Affected CIs related list. This can be incredibly powerful when it comes to determining the full intent of the proposed change.
When a Dynamic CI Group is added to the affected CI list, it is automatically unpacked so that the affected CI related list can be easily groomed to reflect the actual change scope. Unpacking the Dynamic CI Group allows grooming of the related list along with the ability to remove one or more individual CIs in the event the group scope is larger than then the intended scope of the change. This is a really cool capability for applying changes to a group of related CIs that share a common set of characteristics other than just class (e.g. location, type, portfolio).
Impacted Services / CIs
The Impacted services/CIs related list is populated with services that may be impacted by the change based on the CIs that are contained in the affected CIs related list whether added manually or automatically. This is achieved by looking at the Affected CIs and then dynamically tracing their relationships to the Services dependent on the CI. The Impacted Services related list renders a list of impacted services automatically but derives the actual impact assessment values differently depending on how the property (change.refresh_impacted.include_affected_cis) is set (True / False).
Execution Triggers
Refreshing impacted Services on a change request form is executed by one of the following triggers:
Trigger: Conflict detection:
Refreshing impacted services can be initiated when conflict detection is triggered. The property within the Conflict Properties page “Automatically include business or application services related to Cis with conflicts in the Impacted Cis/Services related list” (change.conflict.populateimpactedcis) controls whether the related list should be refreshed or not. If this property is enabled, then a call is made to the ChangeUtils script include that subsequently calls the "refreshImpactedServices" method for the current change request.
Trigger: New State Transition
When a change request is moved from the New state, the impacted services are then refreshed to correctly reflect the services impacted for the Affected CIs. Once a change request transitions from the new state, the Affected CI’s related list can no longer be modified. When the business rule is triggered, the same call is made to the Script Include “ChangeUtils” calling a method of “refreshImpactedServices” for the current change request.
Trigger: Refresh Impacted Services UI Action
To manually refresh the impacted services related list, there is a ui action in the context menu to trigger the refresh. When triggering the ui action, the same call is made to the Script Include “ChangeUtils” calling a method of “refreshImpactedServices” for the current change request.
The “refreshImpactedServices” Method
This method checks to see if the configuration item(s) to be used should be limited to the primary configuration item or all the items listed in the Affected Cis related list. This is defined in the Change Properties using the property “change.refresh_impacted.include_affected_cis”.
Include Affected CIs Property (change.refresh_impacted.include_affected_cis)
Behavior when Property is "False"
If this property is false then the primary configuration item on the change request form is used and any subsequent configuration items in the Affected CIs related list are ignored. In this case the relationships are read via the CMDB to get related record. The Configuration Item on the form is passed through to the CIUtils script include via the method "servicesAffectedByCI". This method iterates through the CMDB tree for that configuration item and if any related configuration items are of type "cmdb_ci_service" or "cmdb_ci_service_discovered" then these are then added. This keeps iterating through until the end of the tree has been reached or the max_depth (default to 10) is reached.
Behavior when Property is "True"
If this property is true then all configuration items listed in the affected Cis are checked. These configuration items are checked against the application services mapping table (svc_ci_assoc) as this is a faster process as well as this returns a more concise relationship picture. When true, all the configuration items listed in the Affected CI related list are used to find impacted services. Due to the possibility of having a large number of configuration items, this refresh is done via an event and once the processing is complete then the user who initiated the refresh would be notified of the completion. It is not an immediate process and can take some time.
Event Processing
Prior to Rome if the "Include Affected CIs Property" is true then the processing of all affected CIs by running the refresh as an event. If this property is false then the traversal of the CMDB tree is done in the user transaction. This can lead to transaction timeouts of the CMDB tree is large.
As of Rome There is an introduction of the property “com.snc.change_request.refresh_impacted.event” which allows the running of the refresh of impacted services via an event regardless of whether the refresh is happening on the Target CI or the Affected CIs.The event process does not use the CMDB tree to find the related services but rather queries the Service Configuration Item Association table "svc_ci_assoc". This table contains the associations between a configuration item and its related service. The list of services that are returned from this query are then added into the impacted services related list.
Conflict Property (change.conflict.populateimpactedcis)
If the change.conflict.populateimpactedcis property is set to true, then additional services are retrieved from ChangeCollisionHelper and added to the list of services. The method called in this script include checks the configuration items that have been identified in the list of conflicts against the same association table that was check earlier (svc_ci_assoc) as well as checking to see if there are any business services that are directly impacted. This is checked against the cmdb_ci_service table.
All groups of services are then correlated into one unique list that is used to populate the Impacted Services related list.
If the Service Mapping plugin is active, then Application Services are retrieved. These are retrieved, whereby, the association type is Runs On, and the association child is one of the CIs in the affected list.
Once all these services are correlated, a new list is added, and the existing items in the related list are removed, where the manually_added flag is set to false. The list of services is then used to populate the Business Applications and Service Offerings if the properties are enabled.
Impacted Business Application Property (com.snc.change_request.populate_business_application)
Change Managers are now able to add a related list to show impacted business applications when a change is being proposed and/or evaluated for approval. You must first set the property for impacted business applications and then add the related list to the form. This installed as part of the “Service Management Basics" plugin. It creates a new related between task and the cmdb_ci_business_app tables. It is linked with the “Refresh Impacted Services” to populate table from the task and its CI(s). It is property driven in terms of whether to populate or not.
Impacted Business Applications uses the (task_cmdb_ci_business_app) table to link the Business Applications to a task. This feature calls the method (refreshRelatedLists) which has been added to the TaskUtilsSNC Script Include. It also includes a customer editable script that extends TaskBusinessAppSNC along with the TaskBusinessAppSNC script which is called by the above method to remove previously added record and add new records.
Rendering the Results
These CIs and Services are rendered back to the user in a few simple and easy to use related lists. The Affected CIs and Impacted Services list are visible OOB on all zBoot instances but customers may need to add the Business Applications and Service Offering related lists. This makes it super easy for the change initiator or change approver to automatically assess the proposed change impact.
Service Offering Property (com.snc.change_request.populate_service_offering)
When this property on the Change Property page is set to true, the Service Offering related list will be populated from the Impacted Services / CI related list.
Conclusion
The ability to accurately assess change impact using automation is vital when it comes to finding that exact balance of velocity, stability and governance. It can reduce change failure rates and avert unplanned service outages.
3 Comments
