ServiceNow CSDM: Evolution & CSDM Examples - Data Content Manager (2023)

(This article was originally published in 2019, republished in 2021 and updated according to CSDM 4.0 in 2022)

ServiceNow published the Common Service Data Model over three years ago. Ever since the ServiceNow community has been craving for CSDM examples and more details on how to implement the model in the real world.

In February 2019, I wrote a blog post discussing the model from the Service Portfolio’s perspective and trying to figure out how to interpret the whitepaper in practice. I thought now would be a good time to rewrite that post and think about how the model has evolved and how the Business Service Portfolio part looks like today.

You can read the original post here and see how things have changed, or have they?

The Evolution of CSDM

ServiceNow has updated their Common Service Data Model (CSDM) whitepaper a few times since the original publication in 2018:

• Version 1.0 introduced the model and split it into three different domains: Business, Service, and Application together with high-level data model diagrams and relationships.
• Version 2.0, released in 2019, updated the domains to Design, Manage Technical Services, and Sell / Consume. It also introduced the implementation phases Crawl, Walk, Run and Fly and emphasized the value of implementing each phase.
• Version 2.1 wasn’t really a new version of the whitepaper. It was rather a set of “Product views” or “Use cases” on how CSDM relates to other ServiceNow Products such as ITSM or Incident Management.
• Version 3.0 is was released in September 2020. This release introduced Foundation Data as a new domain and set some Key Principles. Product-wise, CSDM started to show as CSDM related features on the platform (e.g. dashboards, navigation, form views, etc).
• Version 4.0 draft is the latest version and was published in January 2022. This release introduced a new Build domain, relationship to Service Portfolio also from the Technical Services and some new elements and ideas related to Foundation data and Life Cycles.

In October 2020 we had the pleasure of co-presenting a series of Webinars on the 3.0 version together with Mark Bodman from ServiceNow. You can find our thoughts and a summary of the CSDM 3.0 Webinar Series from here.

And again a year later, we had a CMDB 4.0 Examples for a Data-Driven Portal webinar together with Venni Mäkäräinen also from ServiceNow.

All our previous webinars are available as recordings on our Webinars page. Please take a look.

Consistent Key Messages Across the Whitepaper Versions

Since 2018, updates to the whitepaper have continued to provide more details and CSDM examples while the overall idea and message has remained the same. Here are some of the key messages from different versions of the whitepaper:

• Service-related definitions span the ServiceNow product portfolio and the New Platform. (CSDM 1.0, 2.0, 3.0, 4.0)
• Customers should follow the model in order to utilize the platform to its full potential, realizing a full value chain alignment, improved quality, transparency, better insights, automation, and lower costs. (CSDM 1.0)
• ServiceNow products are standardizing their use of data from the CMDB. That standard is the CSDM. (CSDM 2.0, 3.0, 4.0)
• Without this data in prescribed tables, you may not receive the full value of the ServiceNow platform. (CSDM 2.0, 3.0, 4.0)
• CSDM should be used as a reference for mapping your IT services in ServiceNow. (CSDM 1.0, 2.0, 3.0, 4.0)

In the original post I talked about the lack of an actual data model. The whitepaper only provided a very high-level conceptual model and a list of actual tables vs. the conceptual model, and a list of relationships to be used between the classes. Therefore, I also gave some CSDM Examples.

We will talk more about the data models later, but here is a quick blast from the past, the CSDM Conceptual Model v1.0:

Evolution Towards Tables

Later CSDM versions include more details in their still conceptual data model diagrams and, most importantly, differentiate between Technical and Business services. This evolves towards a model where these records would be managed in different tables instead of just using a Service Classification on a common Service CI Class.

Since CSDM 2.0, technical and business services belong to their own domains and different stakeholders are identified for each. Version 4.0 introduced a new Build domain, but relationships to Services via Application Services still remained the same.

The picture below illustrates the services part of the 2.0 and 3.0 versions which are equal for this part. The same applies to 4.0, since the Build domain is optional between the Business Application and Application Service classes.

Application Focus

CSDM has a very heavy focus on Applications. This has been criticized quite a lot. Different customers are eager to see more common CSDM examples and use cases that do not necessarily involve Business Applications as prescribed.

4.0 version emphasizes applications even more with the Build domain that is only related to application-related services.

I personally feel that “Application Service” could be replaced with a “Configuration Item” where, depending on the service, any CI could be directly related to Service Offerings, also on the Sell / Consume domain.

Therefore, one interpretation of a more generic model could be like this:

I left the Design and Build domains out of this CSDM example picture on purpose, mainly to highlight that there can be services without a relationship to Application Services or Business Applications.

Think about End User Services, for example: a single Workstation CI should be directly linked to the Business Service Offering that describes exactly how that Workstation is delivered to a consumer, and what Catalog Items, Service Levels and other commitments are related to the service.

Different types of Service Relationships

This also brings up the question of the relationship type used between the Business Service Offering and the Application Service: Depends on. This is a logical relationship type when a business service depends on an application (or any other CI) in its delivery. However, what about the CIs that are “Provided by” the service? Like the end-user devices in the earlier example.

This is something worth considering when implementing a service portfolio. If you decide to use different relationship types for different use cases, then just stick with it. Only change if some out-of-the-box feature requires you to do so and you’re truly using that feature. In any case, it is easy to make changes to a data model, once you have one and you’ve been following it.

Business Applications, such as Microsoft SCCM or Intune can relate to Workstations from the technical point-of-view. Different CIs managed under same Technical Service Offerings can still be packaged to end-users with different terms and commitments. In this sense, a “Standard Workstation” Business Service Offering can Depend on SCCM for example, but it also Provides or Delivers, or Supports the actual Workstation CIs.

From Conceptual to Logical Data Models

The actual data model is still on a quite high level and you need to combine details from different pages to come up with an ERD-like data model diagram.

Figure 5 below shows the actual tables in ServiceNow against the conceptual model described as the CSDM.

CSDM Examples and Actual Data Models

I have been looking for a data model that would combine all three:

1. A conceptual model…
2. with actual table names and
3. relationship types

Despite ServiceNow’s intent to update the ITSM reference architecture with an ERD for CSDM (CSDM 2.0 whitepaper), I have not found one. Therefore, please allow me to try to give some CSDM examples based on the CSDM 4.0 whitepaper, out-of-the-box tables and form views.

Let’s split the CSDM into smaller pieces using Data Content Manager as the visual design tool and look at some of the key CI Classes in more detail. Starting with the Business Service Offering, according to CSDM 4.0, the data model could look like this:

This CSDM example data model has been drawn from the Service Offering’s point-of-view. Different filters on the Service Offering and Service tables connect the model to Business Services instead of Technical Services.

The whitepaper does not really describe the exact relationships between Service Offerings and Request Catalog except that Request Catalog is the sc_catalog table. In the above example, this relationship is defined via Catalog Items that are made available for the subscribers of the Service Offering and belong to a particular Catalog.

More information about the Request Catalog relationships in our CSDM 4.0 webinar from November 2021.

Adding Foundation Data to the CSDM Example Model

The latest version of the CSDM puts more focus on Foundation Data but does not define how, exactly, Foundation Data should be related to the rest of the model. This part probably varies the most between organizations, depending on how they are structured and how responsibilities have been defined.

Below is an example, where I have simply added some User and Group references to the model to ensure that responsibilities are in place.

My Differing Opinions

A Service Portfolio can include many more details like SLA definitions and Service Commitments, Subscribers, and so on. One thing that still bothers me a bit in this model, is the prescribed relationship between Business Service Offering and the Application Service classes.

Another detail, where I have a slightly different opinion, is the relationship between Services and Business Capabilities. I would put that relationship on the Service Offering level, instead of Service. The same Service can have multiple different offerings where some of them relate to a capability and some maybe to a different capability.

Doing the relationship on a Service level means that you lose this flexibility in defining dependencies between different offerings of the service and business capabilities those offerings are providing.

Final Service Portfolio Model

My final version of the CSDM example model (as seen below) changes the Application Service into a more generic Configuration Item class and includes the Service Commitment and Subscriber relationships as additional examples. I left the Business Capability relation to Service as defined by CSDM. Overall, I consider my changes to be additions or extensions to the model and I’ve tried to keep it compliant with the original definitions.

All the additional relationships shown in these examples are based on an out-of-the-box setup of the Rome release, but not described as part of the CSDM. I cannot guarantee that these relationships will ever be part of the official model. However, they are already available Out-of-the-Box.

If your implementation is already at this level, then congratulations! You are one of the few and you probably have quite a mature Service Portal also utilizing all these wonderful service details and related capabilities.

CSDM Examples, Blueprint Templates & CSDM Content Pack

We have created these types of data models and CSDM examples as blueprint templates in our CSDM Content Pack. The Content Pack is freely available from the ServiceNow Store. You do need to have the Data Content Manager application installed to view the models, but there is a Free Trial available.

The current version of the Content Pack includes ~20 different blueprint templates for the CI classes mentioned in the CSDM whitepapers. They are organized according to the different implementation phases and domains. The templates can be used as CSDM examples and as starting points for tuning the model to your specific needs.

Implementation Phases for Services?

All in all, the CSDM example data models presented above are quite demanding and are indicative of a rather mature service portfolio model. Therefore, it’s advisable to approach this topic with small steps and ensure you are on the right track from the very beginning to the very end. Data Content Manager can be an extremely useful tool for this.

Business Services are introduced in the model only when you are already in the Run phase. However, in my opinion, you can implement each CI Class with a similar model where you start small and increase the complexity as your maturity to handle it grows. Related to this idea, you might also want to look at our 5 steps model for data management.

One way to “crawl” is also to limit the scope of data by selecting a subset of all your services before launching the model for everyone.

Crawl Phase Data Model for Services

In the beginning I showed a CSDM example data model for the Business Service Offerings in Fly phase of the CSDM. If your focus is Services (maybe related to Customer Service Management), you can also start crawling from the Sell / Consume domain.

In that case, the model for Business Service Offerings could look like this:

Just make sure that every Service Offering has a Parent Service and you have responsible persons or groups defined. Without clearly defined (and implemented) responsibilities there is no reason to move any further. You cannot succeed with CMDB (or Service Portfolio) without proper ownership.

Read more about establishing ownership from here.

More information

If you want to know more about how to enforce ownership and maintenance of different data models on the ServiceNow platform, please do not hesitate to ask. Book a meeting with me, and I will show you how Data Content Manager can help you on your journey towards CSDM compliance, and a better return on your ServiceNow investment.

Regarding “CSDM Compliance” and how out-of-the-box tools like the “CSDM Data Foundations Dashboard” can help, you should read this comparison to DCM.

You also may want to check out our CSDM Solution page, where we have compiled all of our CSDM related things, including a short demo video on how DCM helps with CSDM.

Talk to Us

Book a meeting with us and we will show you how Data Content Manager helps you on your CSDM journey – regardless of your maturity level.

Mikko Juola

Chief Product Officer at Qualdatrix

LinkedIn