5 Steps to make your CSDM WALK phase a success

Create a Technical Services and Offerings overview

The effectiveness of your Application Services largely depends on your Technical Services, in combination with their offerings. Examples of Technical Services are hosting (windows), internet access, Local/Wide Area Network, storage (SAN), identity management (like AD), anti-virus, etc. In enterprises, this list is usually shorter than the list of Application Services.

When listing your Technical Service Offerings, it is important to work with a clear definition. According to the ServiceNow CSDM Whitepaper, a “Technical service offering is a service offering type defined as a stratification of the technical service into options including localization/geography, environment, pricing, availability, capability, support group (for incident), technical approval group (for change), and packaging options (commitments).” Let’s take Identity Management as an example of a Technical Service. Associated offerings could be Active Directory Azure Cloud (external hosting) or Active Directory 2018 Prod / Active Directory 2018 Non-Prod (internal hosting). Looking at the internal hosting options, it is important to differentiate between Prod and Non-Prod, because their service levels differ.

Understand ownership and responsibilities

In order to capture the right data, you need to know who’s responsible. Therefore, it is essential to understand who is accountable (ownership) for service quality and service operations. Some have outsourced the responsibility for a technical service to an external supplier, like for Azure Cloud. Our advice is to focus your CSDM WALK efforts on the technical services that you manage inhouse or of which you are the asset owner. The latter situation occurs when organizations have outsourced network maintenance to an external vendor, but still own the majority of the network equipment (like routers, switches, etc.).

Determine criticality

Now that we have a list of Technical Services and Technical Service Offerings for which you are responsible, it is important to determine their criticality. We need to focus on highly critical services first, set up monitoring and implement changes in a controlled manner. Involve the Technical Service Owners to perform a Business Impact Analysis (BIA) and score your services. In case you aren’t using the custom tables provided in your ITSM bundle, you could use them to support this process to collect input from your service owners. If you’d like help with asking the right questions or performing a Business Impact Analysis, do reach out to us. We can share our best practices in area.

Tip: Start with your top 25 most critical Technical Service Offerings.

Link Technical Service Offerings to corresponding Application Services

Now that we have identified the critical Technical Service Offerings, we can link them to the Application Services they support. This overview is key, because once in place, a Technical Service Owner can see the impact of a change on related applications with a single click. The other way around, your Application Owners and Support Groups can see all dependencies and they know exactly who to contact when incidents occur.

Furthermore, it is important to keep in mind that the Technical Service Offering object is used to capture important information like Approval and Support Group. The data you capture at this level can now be easily copied to associated CIs, which makes maintaining this data at CI level much easier, keeping things manageable.

Identify and link critical CIs of Technical Service Offerings to critical CIs of Critical Application Services

Criticality is important in this step, emphasizing the need to do more with less. IT infrastructures are becoming more and more complex, so you need to focus on what matters most. For the 25 most critical Technical Services Offerings you are responsible for, we’ll now focus on getting the critical Configuration Items (CIs) in place:

• First, you need to map out the dependencies between critical Application Services and critical Technical Service Offerings. Since you have created this overview in step 4, this information is now easy to extract.

• Next, the Technical Service Offering owners need to identify the critical CIs, like your SAN instances, key network equipment and other large building blocks that are connected to the critical CIs linked to your Application Services (application servers, database servers, etc.). In case you don’t have these critical Application Service CIs, then you probably have forgotten some steps in the CRAWL phase.

• Don’t forget to map out the interdependencies between critical CIs as well

Final words of advice

The WALK phase provides some interesting possibilities, especially when you decide to use ServiceNow Event Management. Doing so will give you an instant overview of which critical CIs are failing and how this affects your (critical) Application Services. Not only will this reduce your Mean Time To Resolve (MTTR), it will also ensure better risk assessment for changes. Knowing which critical CIs are linked to one another will ensure the right precautions can be taken to avoid any unplanned downtime of critical Application Services, reducing the number of P1s and ultimately improving business performance.

As you move through the CRAWL and WALK phase, the amount of data you need to capture in your CSDM exponentially increases. Therefore, we strongly advice to look into automated discovery options to keep your transition manageable.