ServiceNow: Building a business case for CSDM

By Jan Procházka, GuideVision Principal ServiceNow Consultant and CMA

For many ServiceNow users, it’s not about the common service data model. It’s about the configuration management database (CMDB), its setup and content as such - how to deploy and maintain a healthy CMDB and how well it serves their IT and business needs.?

The common service data model, or CSDM, is nothing new. It’s been here for a couple of years. The first officially published version was launched in 2018 and now it is reaching version 4.0 (draft published in January 2022). With CSDM increasing maturity, we see an interesting trend: It is not only us actively injecting CSDM thoughts into our new projects, but also our customers have started to ask about CSDM very pro-actively. And their questions and comments are illuminating:?

• It seems great, but we need to find out the real benefits of its implementation in order to obtain funding.
• Show us concrete use cases where CSDM can help in our environment.
• What was the value it delivered??

And then there are comments of a more neutral sentiment:

• Our CMDB works somehow, so why do we need to bother with CSDM? If it ain’t broke, don’t fix it. What’s so good about it? Does it change or restructure something?
• This is interesting. How much time and work will it take to implement?

Eventually the sentiment may turn negative:?

• It seems quite complicated. What is the real value it brings us?

All these questions are natural and well-founded. They’re right. From a business standpoint, it is the value CSDM can bring that matters.

To answer these questions and connect CSDM theory with business practices, we hold workshops with customers and try to find the business case for CSDM for them. The business case is not one-size-fits-all. It may differ for every company. In my own mind, it’s about coming to the correct understanding of what the customer’s real needs are. And the appropriate approach seems to be quite different for already existing implementations with CMDB not following the CSDM and new projects where CMDB is not yet built.

Common Service + Data Model

The spoiler is that the Common Service Data Model just gives a name to something that’s already there. It’s a mind shift that enables you to see things holistically. On one side you have Common Service. It’s a standard and shared set of service-related definitions that will enable and support true service level reporting. On the other side you have a Data Model. It’s a recommended standard CMDB Data Model across ServiceNow modules and applications that will enable and support multiple configuration strategies and ensure that different parts of the ServiceNow stay working together.

The CMDB may have a lot of information in it, but without relevant and well-structured data, it can become an obstacle. It’s something we can see technically, but it’s not enough. We need to understand how these technical resources meet business needs and build a structure to support them. And herein lies the perception of Common Service Data. It’s about how to interconnect the technical world and the business world.

CSDM hype and frustration

This next part may be controversial. Let’s talk about what’s viable and how it is perceived. The first question sounds simple: What does CSDM offer? The by-the-book answer is that “The CSDM provides service reporting and guidelines for… haven’t I lost you already? You may need to read something like this before you go to sleep instead of counting sheep.

The usual definition includes a lot of general information, a bit like definitions from some framework, correct? And to be honest, it must be like that. That’s how definitions work.?

This is the problem our customers have - seeing the value in these definitions. There is information in the white papers, but it’s sometimes difficult to understand and get the value out of it. But we will get there if we try to understand it.

The four worlds of CSDM

In the common service data model, there are different domains. The biggest benefit of CSDM is its power to interconnect quite different worlds and standardize how these worlds are working and cooperating.

The first of these is the world of Design, which is inhabited by enterprise architects and application owners. Here we’re trying to understand primarily the business goals of the organization and define the business capabilities needed to fulfill these goals as well as business applications to support them.?

The second world is Sell/Consume. This world’s inhabitants include business relationship managers and customer service managers. It’s where value is exposed to its consumers. It’s where value is made manifest via business services and the business service offerings organized in catalogs. Simply put, it’s the place where money is exchanged for trusted services.?

The third world is the well-known world of Managing Technical Services. Living in this world are the application service owners and technology service owners.?

The fourth world is called Build, and it was newly added in CSDM 4.0. It reflects our constantly changing environment, where things need to be built, changed or enhanced rapidly. An example: I have an application and need to adapt it because the business needs have evolved. Here we find the teams which build the company’s applications.

Underpinning all of these worlds are a shared set of Foundations. These include straightforward things like locations, users and groups, contracts, and organization structure in the form of a hierarchy of companies, business units and departments. But it also includes more complicated things like products or life cycles. Without these, the individual worlds of CSDM could not exist. Experience shows that attempts to cut corners or skip the foundation part are tempting but doing so proves eventually to be quite painful. Such attempts cause the four CSDM worlds to malfunction because they cease to understand each other.

CSDM and CMDB: What’s the value???

Once you start to see a company’s business in this way, you’ll realize that it really isn’t just about having a lot of items in the CMDB. The value emerges as the individual CSDM worlds start to come together in synergy. When building a solid business case for CSDM, the trick is to build it upon the mutual cooperation of all these worlds.

CSDM helps us to understand services, their makeup and accountabilities, and how individual components connect to each other. One of the main benefits is end-to-end visibility into how the organization uses its technology, and vice versa, how technology supports the business. Measurement of how well the whole structure works up-and-down is the crucial part of building up the business case.

We can take a bottom-up view of these measurements, or we can take a view from the top down. Either way, we’re looking at a prioritized understanding of the services and how they support primary business capabilities and goals.

From the bottom up, you can identify insights from operational activities related to services. When the CMDB is already in place, populated and supporting practices like Incident or Problem Management, or Change Enablement, the CSDM business case can be built based on the right measurement of their performance and on identifying weak spots and pain points the customer has. We’ll go into greater detail about this in the second part of this article.

ITIL4 introduced the concept of value co-creation. The successful strategy for the organization is not about the technology itself, but rather the result of the cooperation enabled by the technology. In my opinion, CSDM follows the practice-oriented approach we saw in ITIL4; it moves away from isolated processes toward a more holistic view. The main idea here is that nothing exists in and of itself - everything is connected. This approach is based around cooperation, and CSDM builds upon this approach. But how you navigate this is the key part of articulating the business case for CSDM in your organization.

The benefits here include increased efficiency - seeing the structure in the place where you need it. Being able to do impact analysis in change management - answering questions like: “What all business services will be impacted and how when we stop this server?”. You can solve your incidents quickly if you have the right information quickly - the answer to what is wrong usually lies on a far different CMDB layer than where the incident was raised. But to get to a tangible business case, we need to quantify it - what is your efficiency right now? What is your mean time to resolution? How is the hierarchical CMDB information helping you in both the ordinary daily routine and in the most difficult strategic decisions? This will help you build the business case.

You can also prioritize critical events based on service-related information. The benefit here is higher productivity, because it’s about the viability of information and seeing it in the common service view can help you identify what’s important and what’s not.

Finally you can understand service health, including availability, customer satisfaction (CSAT), vulnerabilities and inter-process communication statistics. The primary benefit in this is informed decision-making.

So now we’re getting somewhere! The CSDM business case is beginning to become more tangible - we now understand where the value is for the business. CSDM helps to connect the four worlds, and that’s where the greatest value lies. These are things ServiceNow’s architecture supports out of the box, and this is where everything starts to come together. When you use a CSDM approach when designing your ServiceNow implementation, what you’re building in is sustainability and maintainability. But in my opinion we’re still speaking in terms that are too vague and generic. We’ll still have to include more tangible examples normally used in business cases. In Part II, we’ll take a look at what can help.

Jan Procházka is a ServiceNow Certified Master Architect and is a Principal ServiceNow consultant at GuideVision.