CSDM 2.

0
White Paper

Common Service Data Model

This White Paper provides ServiceNow best practice guidance on
service-related definitions and service modeling within the CMDB.

Scott Lemm
[email protected]
 CSDM 2.0 WHITE PAPER

The Common Services Data Model (CSDM) represents a standard and shared set of service-related
definitions across our products and platform that will enable and support true service level reporting
while providing prescriptive guidance on service modeling within the CMDB. These service-related
definitions span the ServiceNow® product portfolio and the Now Platform®.

The data model is a CMDB framework across our products and platform that will enable and support
multiple configuration strategies. Included are best practices related to the proper modeling of data
using out-of-box (OOB) tables and relationships. Many ServiceNow products have a dependency on data
within this data model.
Common Service Data Model
A standard and shared set of service- A CMDB Framework across our products
related definitions across our products and platform that will enable and support
and platform that will enable and support multiple configuration strategies.
true service level reporting.

The scope of CSDM will continually be extended to include more prescriptive guidance in the use of the
data model.

Note: CSDM is NOT a product/SKU from ServiceNow. The guidance within CSDM is for the
standardization and modeling of the CMDB that is used by multiple ServiceNow products.
The CSDM is NOT…
• A process or implementation guide for ServiceNow products
• A set of reports
• Code to install
• An automatic fix for past implementations

Do I need to purchase a module/product to use the CSDM? ServiceNow intends to provide all CSDM-
related objects and CMDB core tables as part of the shipping out-of-box (OOB) CMDB regardless of
licensing. The following (figure 1) references CSDM activity within each of their referenced releases:

Figure 1 CSDM 2.0 Activity Through Each ServiceNow Release

To reiterate, as of the New York release there is no need to license a module to take full advantage of
CSDM referenced tables within the CMDB unless otherwise noted. Several tables, as depicted in Figure
1, have been available OOB since the Kingston release of ServiceNow. Thus, users may begin following
the CSDM beginning with the Kingston release of ServiceNow.

1
 CSDM 2.0 WHITE PAPER

How did we get here? In early 2017 a group of representatives from various business units within
ServiceNow were tasked with identifying how service reporting could be improved. Representatives
from ITSM, ITOM, ITBM, and others were present. After identifying the need for common definitions
and a prescriptive CMDB data model, the CSDM as a collaboration between ServiceNow product teams
was born. At the end of 2018, the formal CSDM 1.0 white paper was released to the public along with 14
standard definitions and data model guidance for the CMDB. Since then, we have been gathering
feedback from customers, partners and internal teams.

What’s new in CSDM 2.0? CSDM 2.0 is a culmination of the feedback from the field as well as a
maturing of products, definitions and data modeling related to the ServiceNow Platform. The intent of
this CSDM 2.0 white paper is to provide an introduction to CSDM while building upon the efforts begun
with the CSDM 1.0 white paper released in 2018. This includes an updated model that reflects new
additions from the New York (NY) release as well as mapping and architectural guidance for service-
related objects.
• Conceptual Model – updated for 2.0 • Relabeling of old tables:
• New tables out-of-box in the New York release: o Service table renamed in NY (formerly
o Information Object (new table in NY) Business Service)
o Service Portfolio (new table in NY) • Definitions for new CSDM tables
o Service Model (new table in NY) • Where to start with CSDM: crawl, walk, run, fly
• Existing tables now out-of-box in the New York • Applying CSDM: SPM, ITSM, Products
release: • Migrating into the CSDM – a prescriptive approach
o Service Offering (now out-of-box in NY)

The Common Service Data Model 2.0 Conceptual Model below (Figure 2) includes short descriptions for
quick reference purposes.

Figure 2 CSDM 2.0 Conceptual Model

2
 CSDM 2.0 WHITE PAPER

Later in this document will be more detailed descriptions, conceptual to physical mapping and mock-up
examples of data model implementation guidance.

While the intent is to provide prescriptive guidance, the model was specifically designed with
extensibility in mind so that customers could extend it as needed (For example add “clinical” as a service
classification type of a Service).

The various domains Design, Manage Technical Services and Sell/Consume are identified and color
coded so that they can be loosely translated to the various ServiceNow product lines. Additionally, we
introduce the concept of Manage Business Services that encompasses portions of all 3 domains. This
representation also accounts for how different persona architypes may consume, view, and populate
the model.

What is a Service? A service is a means of delivering value to customers by facilitating outcomes

customers want to achieve without the ownership of specific costs and risks. This is consistent with the
base definition of “service” in ITIL v3 and IT4IT. Services typically have three aspects: the interaction, the
offering, and the service system. While ServiceNow ships with three OOB service types, you can extend
these service types of classifications to align with the service types in your organization. The three OOB
service types are business, technical, and application.

• Business service is a service type that is published to business users, and it typically underpins
one or more business capabilities.
• Technical service is a service type that is published to service owners and typically underpins
one or more business or application services.
• Application service is a service type that is a logical representation of a deployed application
stack.

What is Design? Design is a CSDM Domain that represents those

tables currently utilized by Application Portfolio Management
(APM). These tables are used for design and planning thus are
NOT selected for ITSM: Incident, Problem, and Change directly.
These tables represent the logical design of the enterprise
applications to be deployed and utilized by the business. Though Application Portfolio Management is
not required to utilize these CMDB tables, APM provides enhanced capability to rationalize and manage
your portfolio of Business Applications, Technologies, Information and Business. The Business Capability
and Business Application tables have been available OOB in the CMDB since the Kingston release.
Information Object is a new CMDB table available OOB in the New York release of ServiceNow. Common
personas in this domain are Enterprise Architect and Application Owner.

Business capabilities
A business capability can be described as a high-level capability that an organization requires to execute
its business model or fulfill its mission. A business capability describes what the organization does, not
how work is performed. It is typically described in the context of performing specific tasks to achieve
one or more business outcomes. Business capabilities are often represented as verbs (For example
managing financials or providing IT support services). It is recommended that you establish a CI
relationship between the business capability and the business applications for visualization and
reporting purposes. Subsequently, you should establish a similar relationship between business

3
 CSDM 2.0 WHITE PAPER

applications and the application services to ascertain the technologies which pose risks to the business
capabilities. This is necessary since enterprise architects routinely assess technologies, information, and
services based on their relationships to business capabilities and business applications. An accurate
service model that includes the relationships to business capabilities can serve as the foundation for
strategy-aligned architectural decisions.

Business capabilities are recorded in the cmdb_ci_business_capability table. Business capabilities are
represented in a hierarchical model that includes a parent business capability that may be
underpinned by one or more lower level capabilities. These lower level capabilities are referred to as
“leaf nodes” in the business capability hierarchy and are typically represented by numeric values such as
1.0 for the parent and 2.0-6.0 for the leaf nodes. If a business capability hierarchy appears to require
more than six levels, it is likely a candidate to be decoupled into multiple business capabilities with the
lower levels representing processes and tasks, not capabilities.

It is recommended that you use the business capability form to create, modify, and extend business
capabilities. If you add a new capability, update an existing capability, delete a capability at a leaf node
level, the levels of all the capabilities for the leaf nodes in that hierarchy must be updated accordingly. A
preferred method for updating capabilities from the business capability form is to click the Update
Capability Level and HierarchyID related link to update the levels in the hierarchy so that the capability
map reflects the change. Additionally, the APM product provides a capability map with edit mode, a
more robust management of the business capability hierarchy for non-technical business users. The
following conditions should be considered when working with business capabilities.

Business capability update guidance

• When adding a capability, the hierarchy level is automatically assigned based on parent
capability level
• If a parent capability is updated in the hierarchy, the levels of all its child capabilities are
recalculated
• The total number of levels cannot exceed more than six in the hierarchy
• Only leaf node level capabilities or capabilities that have no child can be deleted
• Do not create circular relationships. In creating a parent capability, a child capability cannot be
its parent

Business applications
A business application represents all
software and infrastructure (For
example catalog of titles) configured
to provide business functionality.
Business applications are the logical
representation of all instances, used
to increase productivity and to
provide functionality to perform
business functions accurately (For
example payables, receivables,
Figure 3 CSDM 2.0 Business Application Form View
general ledger). Business
applications are typically the software used by business users, but also may represent the “products”
that the business uses for generating revenue or performing missions. They can span multiple

4
 CSDM 2.0 WHITE PAPER

environments and / or deployed per geography (For example dev, test, prod or Americas, APJ, EMEA).
You can use the business application form shown above (Figure 3) to add the applications that your
organization uses based on the business capabilities that they serve. You can record the details of a
business application manually via the form or import the list of applications from a spreadsheet or a
third-party tool. To import data, define a data source and transform map and run or schedule an import.
While the use of business applications is not required, it is a recommended data object to help plan
transformations such as M&A, divestitures, cloud migrations, or cost reduction.

Since business applications are a manually managed CMDB CI class, you will need to manually create
relationships between the business application and other CIs such as the deployed instances of the
business application: the application services class. If needed, two or more applications can be
integrated or connected to each other to establish a relationship between them, representing the
design level. This allows you to relate business applications to other infrastructural CIs such as database
and webservers as well. Using ServiceNow APM, you can add any business application needed to assess
and track for costs, usage, business value, functional fitment, and risks.

In the New York release of ServiceNow, the “architecture type” attribute on the business application
contains the choices “platform app” and “platform host”. These architecture types help represent
platforms as one type of business application and related business applications which depend on the
platforms separately.

Information Object
Information object is part of the new information portfolio and referenced by the business application.
The information object is a configuration item that displays information in an organized form. The
purpose of the information object is to logically describe the type of data (or the information) that is
interchanged between the application and the database. The database being the one that services the
application with data. Information objects are mapped to cmdb_ci_information_object table within the
CMDB.

The information object table may be used to identify the types of data a business application may
possess such as PII, PCI, and etc.

What is Manage Technical Services? Manage Technical

Services is a CSDM Domain that represents those tables
currently utilized by IT Operations Management such as
Service Mapping and ServiceNow Discovery. Additionally,
they represent the technical service portfolio of services
provided for the business to consume. The Manage Technical
Services tables are “operational” thus ARE selected for ITSM:
Incident, Problem, and Change. Beginning with New York, service offerings may be requested through
the Request Catalog. The Manage Technical Services tables represent the provider view of deployed
technology that the business will sell/consume.

Though ServiceMapping and ServiceNow Discovery are not required to utilize the referenced CMDB
tables, such capability greatly reduces the manual effort to manage/maintain configuration items and
their relationships. The Application Service table has been available OOB in the CMDB since London.
Configuration Items in the manage technical services space represent those discoverable items such as

5
 CSDM 2.0 WHITE PAPER

installed applications, servers, and networking. Common personas in this domain are Application Service
Owner and Technology Service Owner.

Application Services
Application service is a service type that is a logical representation of a deployed application stack. Using
application services lets you view maps and change history for services. If event management is
deployed, you can monitor service performance and identify health issues for application services.
Application service is the entry point for service mapping. Application services are mapped to
cmdb_ci_service_discovered and they underpin a business or technical service. The offering of
application services should be exposed via the related business or technical service offering. Application
service was introduced in London and will continue to service as a key relationship entity for ITSM,
ITOM, ITBM, and CSM in the upcoming releases. Its relationships include business applications, business
services, technical services, applications, and infrastructure CIs.

Application
An application is any deployed program or module that is designed to provide specific functionality on
specific compute infrastructure. An application defines behavior and has specific functionality associated
with it. Applications are typically discoverable instances and tend to provide a specific set of
functionalities for one or more services. In the context of ServiceNow, applications are limited to single
host to ensure they maintain a unique identification during discovery processes. Additionally, there is
not a one-to-one relationship between application and application service. In other words, a single
installed application such as a database instance, may support multiple Application Services depending
on the configuration and use of those applications.

The application table is not intended to be an inventory or portfolio of your applications. Those
inventory/portfolio objects belong in the Business Application table discussed earlier in the Design
domain. Instead, the application table and extended tables are meant to be those uniquely discoverable
instances of code running on a host. Applications are considered to part of the infrastructure
configuration items.

Infrastructure configuration items (CI)

Infrastructure configuration items (CI) are physical and logical components of an infrastructure that are
currently or soon will be under configuration management. CIs may be a single module such as a server,
database, router, or more complex items such as a complete system (For example web server, database,
infrastructure). The underlying infrastructure components or CIs are known and well understood in most
organizations. The complexity often surfaces as the data structures are layered on top of those physical
Cis, which is why ServiceNow recommends engaging a business relationship manager or enterprise
architect to define the various business capabilities and business applications.

Technical Services
Technical service is a service type that is published to service owners and typically underpins one or
more business or application services. Using technical services lets you view and manage the technology
you provide to the business. If event management is deployed, you can monitor service performance
and identify health issues for related infrastructure configuration items and application services. The
operational view of technical services are mapped to cmdb_ci_service with a service classification of
“Technical Service” while Event Management enabled technical services are mapped to
cmdb_ci_query_based_service. A technical service may have an operational view made up of one or
more technical service offerings.

6
 CSDM 2.0 WHITE PAPER

Technical Service offering

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).

Different levels of performance and features for a given technical service can be made available via the
technical service offering. A service commitment defines service delivery obligations agreed to between
consumer and provider. There is also a concept of a service offering subscription that records which
users have access to an offering.

Service offerings (SO) consist of one or more service commitments that uniquely define the level of
service in terms of availability, criticality, scope, and pricing, and other factors. For example, an
organization may offer two levels of support for an application service: a “Prod” offering of high
availability and criticality for the production instances with commitments of 5 minute response
guarantee 24/7: a “NonProd” offering of limited availability and criticality with commitments of 60
minute response guarantee between 8-5 on weekdays.

The technical service offerings are mapped to service_offering with a service classification of “Technical
Service.” Technical service offering is derived from service and refined depending on how the parent
serves a specific technical need. ServiceNow recommends that every operational technical service have
at least one offering. Beginning with New York, service offerings may be requested through the Request
Catalog.

What is Sell/Consume? Sell/Consume is a CSDM Domain

that represents those tables currently utilized by Service
Portfolio Management (SPM) and Customer Service
Management (CSM). Additionally, they represent the
business portfolio of services that may sell/consume
elements of the manage technical services domain. The
sell/consume tables are “operational” thus ARE selectable for ITSM: Incident, Problem, and Change.
Beginning with New York, service offerings may be requested through the Request Catalog.
Though Service Portfolio Management and Customer Service Management are not required to utilize
the referenced CMDB tables, such capability greatly improves the ability to manage workflows and
report on service-related data. Service offering has been made OOB in New York while Business Service
Portfolio is a new table OOB in the New York release of ServiceNow. Common persona in this domain is
Business Relationship Manager.

Portfolio
At the highest level, a portfolio is a collection of services, products, projects, or applications. Portfolio(s)
are used to manage like items together for a business. These may be grouped by objective, capabilities,
organization, or geography, etc. (For example ERP or financial management). ServiceNow supports a
wide range
of portfolio types such as service, project, and applications. In this white paper, the focus will be limited
to the service portfolio.

Business service portfolio

7
 CSDM 2.0 WHITE PAPER

Business service portfolio is a hierarchical collection of business services (products and services) that
define strategic business value and facilitates the management of their life cycle.

Business Service
Business service is a service type that is published to business users and typically underpins one or more
business capabilities. Business services are often orderable by business users. Business users are able to
select the desired offering and service commitments levels via a request catalog. A business service may
have a view made up of one or more business service offerings. The view of business services are
mapped to cmdb_ci_service with a service classification of “Business Service”.

Business Service offering

Service offerings are the starting point for configuring Service Portfolio Management (SPM). Service
offerings (SO) consist of one or more service commitments that uniquely define the level of service in
terms of availability, scope, pricing, and other factors. For example, an organization may offer two levels
of desktop support in your organization: a “standard” offering of upgrades and virus protection and an
“executive” offering with the standard commitments plus some type of response guarantee such as 30
minutes between 8-5 on weekdays.

A service offering is defined as a stratification of the service into capability, availability, pricing, and
packaging options. Different levels of performance and features for a given service can be made
available via the service offering. A service commitment defines service delivery obligations agreed to
between consumer and provider. The service offering is the specific record in ServiceNow that identifies
the business area being serviced and the entity where the service is delivered. There is also a concept of
a service offering subscription that records which users have access to an offering. Some business
services and offerings depend on application service. Service offering is derived from service and refined
depending on how the parent serves a specific business need. ServiceNow recommends that every
operational business or technical service have at least one offering.

Figure 4 CSDM 2.0 Service Offering Form View

8
 CSDM 2.0 WHITE PAPER

If offerings have different commitments (and they usually will), those differences should be represented
by different SLA definitions. If a customer has no offerings, their SLAs will almost always be at a process
level only (P1 incident, minor change, etc.) with no reference to the service offering being affected.
Services and offerings that you provide can be represented in the service catalog (by catalog Items) and
made active for consumers to see.

Request Catalog
A request catalog provides a consumable view of available business & technical products, services,
service commitment options, and offerings. Catalogs help manage what services a user may have access
to, and they are the initiation point for access to available services. For example, HR service catalog,
technical catalog.

Beginning with New York, service offerings may be requested through the Request Catalog.

Catalog item
A catalog item is a requestable item within the service catalog. Catalog items are the consumable
representations of service offerings. A given service is often made up of multiple catalog items. (For
example
employee onboarding). Catalog items are published on the service portal and are available to users who
are subscribed to services linked with them or have access because of specific catalog category/item
user criteria. One catalog item should be linked to one service offering.

What is Manage Business Service? The Manage

Business Service is a CSDM Domain that represents
portions of all three previous domains: design,
manage technical services, and sell/consume. For
many organizations, the service owner responsibility
includes more than the business services found in
sell/consume. For these service owners there is a
need to include oversight in the business
applications and their deployed instances known as
application services. It is by having this visibility and oversight that these service owners encompass the
true breadth of their responsibility.

For example, the Service Owner for HR may have financial responsibility for the business application that
provides HR services. Additionally, the HR service owner may be directly responsible for overseeing the
effective deployment of the HR application instances known as application services. Though the HR
service owner may not be responsible for troubleshooting and repairing these application services,
that’s the responsibility of the related technical services & offerings, they are responsible for the impact
the application has on the business.

How does the CSDM 2.0 conceptual model map to the CMDB? In this section, we will take a look at
how these conceptual objects from the CSDM map to the physical tables and CI classes. The mappings in
Figure 5 are straightforward, but please be advised that this mapping will continue to evolve as we
strengthen the relationships across the design, manage technical services, and sell/consume domains to
the degree possible.

9
 CSDM 2.0 WHITE PAPER

Figure 5 CSDM 2.0 Conceptual to Physical Mopping

ServiceNow also intends to update the ITSM reference architecture with an ERD for CSDM. Future
versions of CSDM will include more detailed information on how governance risk & compliance (GRC),
performance analytics (PA), customer service management (CSM), internet of thing (IoT), development
operations, (DevOps), security operations (SecOps) and project performance management (PPM) relate.

Why should I follow the CSDM? ServiceNow products are standardizing their use of data from the
CMDB. That standard is the CSDM which identifies where to place service and application related data
within the CMDB. Current and future products from ServiceNow that utilize the CMDB may require data
to be found in the CMDB framework identified within this white paper. Without CI data in these
prescribed CMDB tables, you may not receive the full value of the ServiceNow platform.

How do I get started with the CSDM? ServiceNow does not recommend trying to implement all
elements of the CSDM data model at once. Based on decades of experience it is not only acceptable but
highly recommended to approach the CSDM in a staged manner: crawl, walk, run, fly.

Crawl
With a focus on quick wins within IT service management (ITSM) we recommend a focus on
Applications. As you learned above, ServiceNow has 3 locations for application related data:

10
 CSDM 2.0 WHITE PAPER

• Business Application – OOB table in the CMDB meant to house your inventory/portfolio of
applications and their meta data. This is NOT an operational CI and should not be used in
incident, problem and change
• Application Service – OOB table in the CMDB meant to identify the deployments of the related
business application. You may have several application services representing each unique
deployment including environment (dev/qa/prod) and location/geography (emea/na/apac). This
CI will often be the object chosen when an incident caller identifies an issue with enterprise
application (fill in your app here). The application service is the glue that ties all the elements of
the CSDM together where applications are present.
• Application – OOB table since the start of ServiceNow CMDB. This table is NOT your inventory of
applications. It is meant to represent the discoverable instance of an application: code related to
a process running on a host. It is a technical CI created and maintained by discovery. Though the
application may be the final cause of an incident, without event management, it may not be the
initial offender. With discovery in place, applications will be automatically related to their host ,
providing an impact hierarchy from server to hosted applications. Manual population of the
Application table is not recommended.

Figure 6 CSDM 2.0 Crawl

What is the value of Crawl? As seen in figure 6, the crawl stage focuses on 4 OOB CMDB tables: business
application, application service, application (discoverable), and server/host (discoverable). Starting with
these objects provide the following value:

• Minimum CMDB requirements to provide ITSM: incident, problem, change

• Foundation for future APM use. When you license/utilize APM, your business application data
will already be in the right place which will improve your implementation velocity of APM.
• Foundation for future ServiceMapping use. When you license/utilize ServiceMapping, you will
have your application service data populated and ready to fill in your entry points for mapping.
• Foundation for Technology Portfolio Management risk details use, a capability of APM.
Technologies that underlie the business applications deployed in your business enterprise have
a shelf life that must be actively managed and diligently monitored to track their versions and

11
 CSDM 2.0 WHITE PAPER

lifecycle. When utilizing ServiceNow APM, ServiceMapping, and SAM Pro, customers can identify
these pending risks to using outdated software.
• Future products and enhancements to existing products will depend on data being populated in
these specified tables.

Walk
Deployed applications and infrastructure need someone to manage/support them. Many of the
“services” populated in customer instances today are technical in nature. The next natural buildout of
the CSDM focuses on the management of technology services. As you learned above, ServiceNow has 2
tables that identify the provider of technology:

• Technical Service – OOB table in the CMDB meant to identify the provider of the technology
that your business consumes.
• Technology Service Offering - Technical service offerings may be broken into options including
localization/geography, environment (prod/non-prod), pricing, availability, support group (for
incident), technical approval group (for change), and packaging options (commitments). The
technical service is derived from service and refined depending on how the parent serves a
specific technical need. ServiceNow recommends that every operational technical service have
at least one offering. Beginning with New York, service offerings may be requested through the
Request Catalog.

Figure 7 CSDM 2.0 Walk

What is the value of Walk? As seen in figure 7, the walk stage focuses on 2 additional OOB CMDB
tables: Technical Service (Service table with a service classification of Technical Service) and Technical
Service Offering (Service Offering with a service classification of Technical Service). Focusing on these
objects in the walk stage provide the following value:

• Management of configuration items. Many infrastructure CI’s are discoverable. Managing the
manual meta data on these objects such as support group and technical approval group can be
taxing. By identifying the technical service offering that manage these CI’s, you can configure

12
 CSDM 2.0 WHITE PAPER

ServiceNow to populate/synchronize this data onto these related child objects thus eliminating
the manual effort of maintaining said data on thousands of CI’s.
• Establish a view of those CI’s that the technical teams support within your organization. Allows
for additional stratification of their support structure along the lines of OLA’s and commitments.
Formalize the structure that already exists today through your use of varying support groups for
application and technology owners.
• Foundation for future service portfolio management (SPM) use. When you license/utilize SPM,
your service data will already be in the right place which will improve your implementation
velocity of technical SPM.
• Technology Service Offerings may be ordered through the request catalogue. Automation may
be configured as need to enhance the request workflow and update/create related CI’s.
• Foundation for ITOM products such as ServiceMapping and Discovery.

Run
A critical element of ITSM is understanding the impact technology can have on the business. The
business may consume the technology provided. Additionally, CSM has a similar dependency where the
business sells the technology provided. Such dependencies require a relationship from the technology
provided to the business that sells/consumes it. The next buildout of the CSDM focuses on
sell/consume. As you learned above, ServiceNow has 3 tables that identify the sellers/consumers of
technology:

• Business Service Portfolio (not a CMDB table) - Business service portfolio is a hierarchical
collection of business services (products and services) that define strategic business value.
• Business Service – OOB table in the CMDB meant to identify strategic business value that may
utilize technology infrastructure. Such a dependency results in the business service
selling/consuming said technology infrastructure.
• Business Service Offering – Business service offerings are the starting point for configuring
Service Portfolio Management (SPM). Business service offerings consist of one or more service
commitments that uniquely define the level of service in terms of availability, scope, pricing, and
other factors. The business service offering is derived from service and refined depending on
how the parent serves a specific business need. ServiceNow recommends that every business
service have at least one offering.

Figure 8 CSDM 2.0 Run

13
 CSDM 2.0 WHITE PAPER

What is the value of Run? As seen in figure 8, the run stage focuses on 3 additional OOB tables: Business
Service Portfolio (not a CMDB table), Business Service (Service with a service classification of Business
Service) and Business Service Offering (Service Offering with a service classification of Business Service).
Focusing on these objects in the run stage provide the following value:

• Impact assessment for ITSM: incident, problem and change. Within an incident or change you
can identify the impacted business assuming relationships exist between the selected CI and the
impacted businesses.
• Foundation for Service Portfolio Management capabilities with service owner workspace. The
service owner workspace delivers a workspace where service owners can monitor service
portfolios and effectively gain an overall understanding of service-related information. Such
information includes service trends, improvement initiatives, service performance, outage
monitoring, and more.
• Foundation for ITSM+ capabilities. Populate the related subscribe by table on a service offering
to identify more than what business is impacted. Identify “who” is impacted. Business Service
Offerings can identify subscribers by user, company, location, department, and group.

Fly
The complete CSDM 2.0 is made available in the fly stage. Mother always said, “don’t bite off more than
you can chew.” The CSDM is no different. Reaching the fly stage means you have accomplished all or
most of the crawl, walk, run recommended approach to the CMDB framework. The last stage of the
CSDM build out finishes the remaining elements of CSDM 2.0. As you learned above, ServiceNow has 3
tables that identify the remainder of the CSDM 2.0 effort:

• Request Catalog (not a CMDB table) - Beginning with New York, service offerings may be
requested through the Request Catalog.
• Business Capability – Business capability is a high-level capability that an organization requires
to execute its business model or fulfill its mission. These capabilities can be used to rationalize
and prioritize spend on business applications and business services.
• Information Object - Information object is part of the new information portfolio and referenced
by the business application. The information object table may be used to identify the types of
data a business application may possess such as PII, PCI, HIPAA, and etc.

14
 CSDM 2.0 WHITE PAPER

Figure 9 CSDM 2.0 Fly

What is the value of Fly? As seen in figure 9, the fly stage focuses on 2 additional OOB tables: Business
Capability and Information Object. Additionally, request catalog capabilities with Service Offerings are
valuable. Focusing on these objects in the fly stage provide the following value:

• Foundation for APM capabilities. Perform rationalization of your business applications with
APM. Are you spending too much or too little on your business capabilities? Should you be
increasing spend on emerging business capabilities?
• Foundation for APM with SPM capabilities. Perform rationalization of your business services and
related offerings. Like business applications, are you spending too much or too little on services?
Are they the right services compared to emerging capabilities?
• Foundation for ITSM+ capabilities. From the request catalog you can now relate a service
offering to a catalog item in New York. Enhance the request workflow to auto populate the
subscribe by user table.
• Manage business services in your environment as a service owner with a combination of CI’s
from each of the CSDM domains.
• Identify the types of data that may be contained/used within your business applications. A
common requirement for compliance, the new information object table will assist in identifying
the details of your information portfolio.

NOTE: The information object table may be required sooner in your data model
implementation. Your business requirements should determine the right stage for
implementation of the information object table

What relationships do I use between the CSDM CI’s? Configuration management is not effective
without the use of relationships between CI’s. Not all objects in the CSDM 2.0 conceptual model are
CMDB tables. Additionally, not all the objects have relationships. The following (figure 10) identifies the
relationships utilized.

15
 CSDM 2.0 WHITE PAPER

Figure 10 CSDM 2.0 Relationships

Several ServiceNow products, such as APM, have a critical dependency on the relationships listed above.
If these relationships are not utilized (ex. Business Application “consumes” Application Service) then
functionality such as the Technology Portfolio Management risk assessment will not function.
Additionally, the relationships commonly created as part of ITOM Service Mapping & ServiceNow
Discovery are considered the standard for infrastructure CI’s. When mapping these elements manually,
without ServiceNow Discovery, it is best to consider WWDD (what would discovery do?).

How do I apply CSDM in my world? CSDM is a CMDB framework for you to utilize in mapping out your
services. There are multiple scenarios for applying CMDB data into your operations. Common scenarios
include views related to service portfolio management, IT service management for incident & change,
and product management.

Service Portfolio Management (SPM)

For SPM, multiple data elements are populated that assist with the organization of services as well as
providing foundational data in support of ITSM and vendor performance management.

16
 CSDM 2.0 WHITE PAPER

Figure 11 CSDM 2.0 SPM view of data

The data model in figure 11 identifies data elements populated or related to SPM:
• Subscription – related lists on service offerings that identify “who” has access to the offering. An
incident or change can identify impact using the subscribed by tables. The related lists are as
follows:
o Service Subscriptions by Company – service_subscribe_company
o Service Subscriptions by Department – service_subscribe_department
o Service Subscriptions by Group – service_subscribe_sys_user_grp
o Service Subscriptions by Location – service_subscribe_location
o Service Subscriptions by User – service_subscribe_sys_user
• Service Level Agreement (SLA) – a commitment type for business service offerings, the SLA
becomes valuable for ITSM as well as vendor performance management.
• Version – the deployments of applications known as application services should be application
version specific. The version maps to the attribute version. Multiple versions of a business
application may be deployed.
• Environment – may be used by incident & change. Found on the technical service offering and
application service. Some service offerings may identify the environment of the offering such as
prod and no-prod (DEV, QA, UAT, etc.). The environment maps to the attribute used_for. Those
non-prod environment may be filtered out from incident and change if desired.
• Service Level Objective (SLO) – a commitment type for technical service offerings, the SLO
becomes valuable for ITSM as well as vendor performance management.
• Business Criticality – may be used by incident & change. Found on the business service offering.
The business criticality maps to the attribute business_criticality. The business criticality maps
to the attribute criticality. A business service may have multiple offerings, each with differing
criticalities.
• Design Criticality – found on a business application and used to identify how the application
should be deployed. The design criticality maps to the attribute business_criticality. The design
criticality as determined by the application owner should align with the commitments of the
related technology service offerings. Together, the design criticality and the technical service

17
 CSDM 2.0 WHITE PAPER

offering commitments that supports the deployed application service(s), should align with the
business criticality consuming the application service.
• Location/Geography – technical service offerings and application services should identify their
managing location when multinational environments exist. The location/geography maps to the
attribute location. For example, the offering/application service that resides in and services
Japan vs a separate offering/application service that resides in and serves the UK.

IT Service Management (ITSM)

For ITSM, specifically incident & change, there is tremendous value in knowing where to find critical data
to reduce mean time to resolution of incidents and eliminate outages caused by change.

Figure 12 CSDM 2.0 ITSM view of data

The data model in figure 12 identifies data elements available for use by ITSM:
• Subscription – related lists on service offerings that identify “who” has access to the offering and
thus may be impacted in an outage. An incident or change can identify impact using the
subscribed by tables. The related lists are as follows:
o Service Subscriptions by Company – service_subscribe_company
o Service Subscriptions by Department – service_subscribe_department
o Service Subscriptions by Group – service_subscribe_sys_user_grp
o Service Subscriptions by Location – service_subscribe_location
o Service Subscriptions by User – service_subscribe_sys_user
• Business Approver – may be used by change. Found on the business service offering. The
business approver maps to the attribute approval_group.
• Technical Approver – may be used by change. Found on the technical service offering. The
technical approver maps to the attribute approval_group.
• Environment – may be used by incident & change. Found on the technical service offering and
application service. Some service offerings may identify the environment of the offering such as
prod and no-prod (DEV, QA, UAT, etc.). The environment maps to the attribute used_for. Those
non-prod environment may be filtered out from incident and change if desired.

18
 CSDM 2.0 WHITE PAPER

• Business Criticality – may be used by incident & change. Found on the business service offering.
The business criticality maps to the attribute business_criticality. The business criticality maps
to the attribute criticality. A business service may have multiple offerings, each with differing
criticalities.
• Technical Assignment Group – may be used by change for routing of change and change tasks.
Found on the technical service offerings. The technical assignment group maps to the attribute
assignment_group. May be synchronized onto the CI’s that the offerings manage thus reducing
the manual overhead of maintaining manual data on thousands/millions of CI’s.
• Technical Support Group – may be used by incident for routing of incident purposes. Found on
the technical service offerings. The technical support group maps to the attribute
support_group (Note: organizations may be using the assignment_group attribute instead of
support_group which is acceptable if the data is the same used in routing of change and change
tasks). May be synchronized onto the CI’s that the offerings manage thus reducing the manual
overhead of maintaining manual data on thousands/millions of CI’s.

Product Management
Starting with the New York release of ServiceNow, the CSDM is referencing models to identify product
management functionality. APM has utilized software models in their technology portfolio management
risk calculations for several versions. In New York we introduce a new model type, the service model.
Future release will expand the capabilities of product models to that of the software model.

Figure 13 CSDM 2.0 Product view of data

The data model in figure 13 identifies data elements related to product management:
• Service Model – new in the New York release, the service model is a critical component of the
customer service management (CSM). The model attribute on service-related CI’s such as
business service, service offerings, and technical service, are populated with the related service
model. The service model object has a version, manufacturer, product owner, and more meta
data. The service model allows for the use of service as a product that can be sold by a service
offering.
• Software Model – the software model is utilized by APM. The software models found through
service mapping and make up a deployed application service are populated in a related list. That

19
 CSDM 2.0 WHITE PAPER

related list is utilized by TPM to identify lifecycle risk of deployed software’s that may not have
publisher support in the near future.
• Hardware Model – the hardware model is auto populated by ServiceNow discovery when auto
discovered.
• Product Model – base product model table utilized by business application.

What reporting comes with CSDM? Short answer – none. At this time, the CSDM is a CMDB framework
focused on identifying where to place data that our products depend upon. In the future more
visualization, reporting and analytics will be made available through the product teams that utilize the
CMDB.
In the short term, it can be helpful to leverage the CMDB query builder to build on demand reporting to
visualize the CMDB configuration Items and its dependencies. Most of the CSDM falls under the CMDB
data model. For example:

• Business capability
• Business application
• Information object
• Application service
• Service
• Service offering

You can build an on-demand query builder report to visualize infrastructure dependency with CSDM.

How do I migrate into the CSDM? Much of the CSDM tables have only been available OOB for 2 years or
less. Many ServiceNow customers may be utilizing necessary customizations or nonconforming tables
within the CMDB. But continued use of these customizations and nonconforming uses will result in
reduced value from the ServiceNow products that increasingly depend on data found in the CMDB
framework outlined by the CSDM. So, how do we migrate into the CSDM – very very carefully…

Figure 14 Migrating into the CSDM 2.0

Since the Business Application table was made OOB in Kingston, we have spent a lot of time helping
customers migrate their data from one table/class to another. That time and experience is what we are
using to provide you guidance in migrating into the CSDM. There are 5 steps to such a migration from
table to table as seen in figure 14 above. These steps are:

• Step 1: Back up your data – ServiceNow takes data loss very seriously. Though you won’t need
this data immediately, it is always a best practice to back up your data prior to embarking on a

20
 CSDM 2.0 WHITE PAPER

data migration effort. Export your table data with all attributes to excel and place in a safe spot.

• Step 2: Attribute mapping – Identify what tables your data will migrate to and if the destination
table has your required attributes available OOB. This is an opportunity to rationalize your
custom attributes. Do you really need those customizations that were only used once 5 years
ago or have only been populated on less than 10% of your CI’s?

In most cases, less is more. Use this opportunity to eliminate low use / no use attributes or
those attributes with more effective methods of fulfilling their use case. Categorize your custom
attributes as follows
o Best Practice – no related OOB attribute but is recommended by ServiceNow or a
Partner.
o Keep – no related OOB attribute but a unique use case requires the attribute be
retained.
o Refactor – there is an OOB attribute or capability that can be migrated to
o Do Not Need (DNN) – this customization is no longer needed

• Step 3: The most important step!!! – In all honesty, it is relatively simple to move a CI from one
class to another. But such effort may neglect an extremely important element of your
environment – dependency on your non-conforming table. You may not be aware of potentially
hundreds of reports, business rules, scripts, table references and more that look for data
specifically in your non-conforming table. Moving the CI’s to a new table does not automatically
move the reports, business rules, and etc. Thus, we need to identify table dependencies.

We accomplish this effort using a fix script developed by Austin Buono of ServiceNow Customer
Outcomes. The script has a place to enter the name of the table you desire dependency details
on. The result is a list of specific dependencies.

ServiceNow makes this fix script freely available through our ServiceNow Community here.
Please take the time to subscribe to our community forum for updates to the CSDM.

After running the dependency script and evaluating the data, you will have a level of effort
understanding for your dependency migration efforts. Use this time to validate the referenced
reports – are they still needed? Validate the rules & scripts – are they still needed? Identify what
should stay and make a plan for migrating these to the new table(s) as needed.

Note: this script does not move your data or dependencies. This script identifies where you
have dependencies that you will need to refactor in step 5.

• Step 4: Refactor attributes – Now is the time to get the data model solidified and ready for data
migration.

Using the attribute mapping effort of Step 2, create the necessary best practice and keep
attributes on the necessary CMDB tables as you or a partner have documented. This is also the
time to perform the documented refactor efforts as needed.

• Step 5: Data Migration – With the attributes refactored and dependencies ready to migrate we
can begin our data migration:

21
 CSDM 2.0 WHITE PAPER

o Validate the data backup in step 1 is still useful. Perform another data backup if
necessary.
o Migrate your CI’s –modify the class to the new class name. This will move the CI and all
its related objects, incidents, changes, and so on to the new table. Perform a handful at
first and increase as needed/comfortable.
o Custom attributes or OOB attributes not in the same table hierarchy will result in data
loss. This is why we made a backup.
o Remediate your table dependencies:
§ Modify reports to use new table
§ Migrate business rules & scripts if needed
§ Update table references as needed
o Reload data into new attributes using your data backup.
o Validate all data and dependencies.

ServiceNow does not expect you to perform such table migrations alone. ServiceNow’s Customer
Outcomes organization and partners are available to assist in this effort.

Note: there is always risk when migrating data. Make sure you backup your data and provide
contingency plans in case issues arise.

What are some use cases (examples) of the CSDM? The updated CSDM 2.0 conceptual model helps
identify a more prescriptive view of what the CSDM is which reduces the need for explicit examples
within this white paper.

That said, ServiceNow intends to provide use cases as unique examples for implementing the CSDM 2.0
in separate documentation and eLearning. Such a separation will make management of this document
easier while providing increased velocity for sharing real-world use cases as examples.

Your foundation for digital transformation

The Common Services Data Model 2.0 (CSDM) should be used as a reference for mapping your IT
services into ServiceNow. Additionally, we will be using CSDM to drive standardization and further
strengthen the value proposition of using ServiceNow products and services.

ServiceNow brings enormous value for enterprise customers that want to run IT as a business. CSDM,
combined with the Now Platform, creates a standard blueprint for automated and integrated IT services.
With streamlined supporting activities and value streams fully integrated on the Now Platform, you can
realize full-value chain alignment, improved quality, transparency, better insights, automation, and
lower costs. Ultimately, the combination of CSDM and ServiceNow serves as the foundation for digital
transformation.

© 2019 ServiceNow, Inc. ServiceNow, the ServiceNow logo, Now, Now Platform, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc. in the United
States and/or other countries. Other company and product names may be trademarks of the respective companies with which they are associated.

servicenow.com

22