Disclaimer

Any statements, opinions and remarks made by me in this community post are personal. As such, they are not representing any official stand of my employer. The text here is reflecting my personal experience working 8 years in the ServiceNow ecosystem as partner, customer and now as a ServiceNow employee. Needless to say, I draw on the insights of all the smart people I have had the pleasure to work with during my professional career.

Introduction

In this very first Now Community post of mine, I'll briefly concentrate on:

• approaching CSDM
• foundation data - life cycle thinking

My goal is to write a few articles under the broad CSMD topic during 2021. The overall intention is to look behind the whitepaper.

Approaching CSDM

Do you ever get this feeling when working around CSDM?

Believe me, you are not the only one. I see this feeling often derive and result from taking a wrong approach to begin with. Something that works for an organisation may not be the best fit for yours.

One exact golden rule to follow does not really exist in my opinion but there are a few things to every organisation consider. These include topics that help you formulate a fit for purpose approach for you organisation. Let me give a few pointers.

CSDM is not an outcome but supports achieve desired business outcomes

Being CSDM 'compliant' (such does not really even exist) does not in itself take an organisation forward. A better approach is to tie actions and phases to your desired outcomes and overall roadmap.

Let's imagine your initial scope is ITSM. You surely have some business reasoning to have made the move to ServiceNow platform. Any expected improvements to support modernising your ITSM operations should also drive actions taken from CMDB viewpoint under CSDM framework.

Define your critical use cases for your processes including reporting first. This fuels the must-haves for CMDB setup governed by CSDM. Acknowledge what you may not be able to do initially based on your chosen approach. For example, targeting infrastructure at first and leaving service layer to smaller attention will:

• reduce business context around various operations; e.g. assessing actual business impact of a change request requires service awareness
• reduce ability to execute service driven service level management
• reduce ability to manage actual service outages

The key is to not only understand what the chosen approach enables but also what the implications are. So, instead of than just documenting technical data classes along with your phases, it is better to also include what the particular data enables for your operations giving it more business context. Internal discussions around this are never easy but are easier when this type of home work has been done.

Translate CSDM to your business

Your business likely has a set of terms or language that is commonly used. The fact is, your business language will not change. At least, such a change would be very hard to accomplish. Neither will change the official terms and descriptions prescribed by CSDM.

There very likely will be the time when you have a set of data of importance to you required to be managed in CMDB while it may seem hard to fit directly in CSDM prescriptions. This requires translation which should not be done hastily. In addition, ensure that a sufficient participation of decisive stakeholders takes place. Involve experts from your implementation partners as well.

E.g. the term service is used various contexts. Officially, a service is an outcome expected by a customer. A service goes along with action. Something tangible does not really constitute towards a service.

Scale CSDM efforts for your organisation

Whatever you do, do not target for something your organisational structure cannot support. Do not establish something that cannot be maintained.

The play is utterly different in a scenario where there is a dedicated and centralised config team with a defined CMDB process in place vs. having a single config manager or not having a CMDB process formally in place.

Why should you try to model and establish something comprehensively that lacks e.g. clear ownerships? There might even be some internal debate on how manage different types of data. Better to start small allowing room for expansion than trying to guess on behalf of your internal subject matter experts.

In practice, it is not really realistic to explicitly follow CSDM suggested phases crawl, walk, run, fly or the dedicated outcome based approach either. In reality, it is very likely you'll end up having a mix of phases ongoing for different types of services supported by different types of technology.

Preserve time for OCM

Funnily enough, often CSDM/CMDB is not mentioned in communication or training plans. Instead, the focus is fully on training some admins initially as well as getting the agents up to speed. I say that CSDM/CMDB should have its own dedicated place in these plans.

ServiceNow CMDB is very extensive even without complementary products such as ITOM. The current CMDB Fundamentals class is 3-day training alone. Acquiring basic understanding what is out there is a step closer to your success.

You may want to consider involving the CMDB process key stakeholders in establishing any policy, guideline and process documentation. Plan and deliver recurring info sessions, maybe even for targeted groups such as service owners, infrastructure teams and agents working on cases.

Prepare documentation that explains why things are done in your predefined way including the value aspect for different audiences. Internal complaints are more than likely. Preparation helps manage these situations.

CSDM is a framework

Finally, embrace the fact that CSDM is a framework. This is also stated in the first sentences of the white paper. I derive a few things from this:

• frameworks are not a exact rule book
• in real life scenarios, frameworks cannot really be leveraged fully by the book due to resource, technology, budget, compliance, regulation etc. constraints
• CSDM is not something you implement, CMDB is

Having said this, there are matters that are given and which should not be bypassed:

• no need to deviate from the prescribed relationships
• understand how the different types of services are defined
• * a colleague of mine will write an article about Application Services giving more technical aspect to the class in the near future. I'll link the article here once it is available.
• understand how the different types of applications are defined
• many ServiceNow products lean on data being defined in prescribed data classes; leverage the CSMD product views and consider this when planning for platform expansion.

Foundation Data

I chose foundation data for this article as it affects each and every organisation and therefore their CSDM/CMDB efforts as well. I know what you are thinking. Your are thinking that your foundational data quality is not good. Get over it! Generally speaking, other organisations are not better off with this topic.

For many organisations, foundation data becomes widely visual across the organisation when they start using ServiceNow. This may be the first time the organisation tries to workflow something relying on their foundation data. I am not going into further details here on example issues but you can view this blog post by @mikkojuola discussing resulting issues.

The main differences between organisations around this topic are:

• how data deviations are managed overall
• lifecycle thinking for foundation data

I'll concentrate on the life cycle thinking here. When establishing foundation data you need to:

• understand and document the full data flow chain resulting in having foundation data in the platform; documenting the primary source for ServiceNow is not enough
• define what concludes a data object to be obsolete
• define what actions are taken for obsolete data objects and when in relation to first sighting of such occurrence
• describe how data deviations are managed

Unfortunately, foundation data is often part of platform core configuration and rushed for getting into process implementations. Surely, the related debt is to be paid later on.

Why this life cycle thinking is important also for foundation data?

Firstly, just think of the user object in ServiceNow and how many other data objects relate to it. Many of these data objects are just as well obsolete when the user is ultimately invalid. You do not want to have this kind of data mixed with current operational data.

Secondly, without life cycle thinking it is harder to execute reliable reporting and/or data audits against your CMDB data. This can lead to a scenario where the expected attributes are in place while they are false in reality. I.e. audit activities may indicate green status while the situation is more towards red under the surface.

Ending words

First of all, thanks for reading! I would be very pleased to hear your tips and experience around the two main topics of this article in the comments below:

• approaching CSDM
• foundation data - life cycle thinking

I'll close the article with the below key takeaways:

• remember CSDM is a framework, not a rule book providing answers to your unique scenario
• CSDM is not something to implement but your CMDB management can be adopted to follow CSDM
• understand to your best ability any implications your chosen approach has beside what it enables
• broaden your thinking around foundation data from plain data imports to valued data having a life cycle