ServiceNow published the Common Service Data Model roughly two 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 the current version that 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).

Last fall we had the pleasure of co-presenting a series of Webinars on the latest version together with ServiceNow. You can find our thoughts and a summary of the CSDM 3.0 Webinar Series from here.

The entire webinar series is available online as recorded sessions. Please take a look.

CSDM Evolution

Figure 1 Evolution of the Conceptual model from CSDM 1.0 to 3.0

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)
  • 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)
  • Without CI data in these prescribed CMDB tables, you may not receive the full value of the ServiceNow platform. (CSDM 2.0, 3.0)
  • CSDM should be used as a reference for mapping your IT services in ServiceNow. (CSDM 1.0, 2.0, 3.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:

CSDM 1.0 Conceptual Model

Figure 2 Conceptual data model from the CSDM 1.0 whitepaper 2018

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.

In CSDM versions 2.0 and 3.0, technical and business services belong to their own domains and different stakeholders are identified for each.

The picture below illustrates the services part of the 2.0 and 3.0 versions which are equal for this part:

CSDM - Services

Figure 3 Simplified CSDM 3.0 for Services

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.

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:

CSDM Generic Services

Figure 4 Generic version of the CSDM for any Configuration Item

I left the Design domain 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 - Conceptual to Physical Model

Figure 5 Conceptual Model to Physical Model according to CSDM 3.0

Another figure from the white paper describes the relationships between different classes as shown below:

CSDM - Prescribed Relationships

Figure 6 Prescribed Relationship according to CSDM 3.0

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 3.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 3.0, the data model could look like this:

CSDM - Service Example

Figure 7 Business Service Offerings data model

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.

 

Adding Foundation Data to the CSDM Example Model

The latest version of the CSDM, 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.

CSDM Service Example with Foundation Data

Figure 8 Business Service Offering data model with Foundation Data references

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.

 

CSDM - Service Example with Service Details

Figure 9 More generic Business Service Offering data model with CIs, Subscribers and Commitments

All the additional relationships shown in these examples are based on an out-of-the-box setup of the Paris 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 19 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:

CSDM - Service Example for Crawling

Figure 10 Business Service Offerings data model for “crawling”

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 defining data 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 contact me or book a demo to see how Data Content Manager can help you on your journey towards CSDM compliance and better return on your ServiceNow investment.

You also may want to check out our CSDM Solution page, where we have compiled all of our CSDM related things.

CSDM 3.0 Webinar Series

Crawling

CSDM 3.0 - Crawling with DCM

Presented on September 22, 2020. Click to View On-Demand!

Giraffes Walking

CSDM 3.0 - Walk & Run with DCM

Presented on October 13, 2020. Click to View On-Demand!

Hawk Flying

CSDM 3.0 - Flying with DCM

Presented on November 3rd, 2020. Click to View On-Demand.

Mikko

Mikko Juola

Chief Product Officer at Qualdatrix

LinkedIn

Built on now
Share This