ServiceNow Community MVP John Zhang helps to clarify the complexities of CSDM and answers questions from the Ask the Experts Getting Started with CSDM webinar.
The ServiceNow CSDM standardizes how your life sciences organization manages information related to technology services. It provides guidelines for service modeling in the Configuration Management Database (CMDB) and aligns configuration items (CIs) and services with your business strategy.
Picturing the Common Service Data Model
This data model illustrates the CSDM conceptual model, which is shared by domains, and serves as a blueprint to map your services to the ServiceNow platform.
This figure also shows the Manage Portfolio domain that encompasses portions of all five domains and how different roles and user personas can use this data model.
Note: This diagram shows a 4.0 data model populated by ServiceNow. See the Q&A at the end of this blog to learn how CSDM aligns with Digital Portfolio Management (DPM), Service Portfolio Management (SPM), and Application Portfolio Management (APM).
The color-coded domains loosely represent one or more ServiceNow products and show how each domain works together to manage your ServiceNow applications and services.
The boxes represent tables in the ServiceNow CMDB. The foundation data in gray at the bottom represents data referenced on the records that contain CSDM data points. The lines are relationships between data tables that span the entire platform.
CSDM is the standard for all ServiceNow products that use the CMDB. By following the CSDM data model, you ensure that foundational data required by your ServiceNow application is correctly mapped to the appropriate CMDB tables.
But how does ServiceNow map this conceptual model into the physical model? It becomes part of the CMDB.
CSDM and CMDB Tables and Relationships
The big question is, “Why do I need CSDM and CMDB?”
The short answer is that CSDM is all about doing CMDB right.
The detailed answer includes ServiceNow using the conceptual data model to map objects to the physical model of the ServiceNow platform. After you map a CSDM object into a physical CMDB table, it becomes a logical CI.
After the structural mapping is done, you populate the data from the network and different data sources into the CMDB, then connect user relationships so it can be referenced cross-platform. ServiceNow predefines the CSDM relationship for you.
There are two ways to populate CMDB data: 1) automatically using Discovery, Agent Client Collector, or Service Graph Connectors marked “Discoverable” for application or infrastructure CIs, and 2) manually for most CSDM logical CIs like business applications marked “Non-Discoverable.”
Not all objects in the CSDM conceptual model are CMDB tables (e.g., the service portfolio table and the request catalog). You may need to create the required relationships between the service offerings and the application service in the CSDM navigator using the application service wizard.
The Optional SDLC Component
The SDLC component represents software or an element of a larger whole for applications and infrastructure, like “config files.” Related material can be representative of developmental details and could identify the stratification of a business application or digital product. Note: This is not an operational CI and cannot be used in incident, problem, and change.
Not every business application will have an SDLC component; therefore, it will not need to be populated.
Foundation Data and CIs for Larger Digital Products and Services
You know that the CSDM conceptual model is mapped to the physical model in the ServiceNow platform. Now we’ll see how the relationships you set up in the CSDM help your organization build digital products and services in the ServiceNow platform.
Foundation data is like a user group and the location information can be referenced from infrastructure CIs. Logical CIs are used cross-platform to support individual applications. This is a fairly mature stage after using CSDM to define your own product and it becomes a ServiceNow product.
Understanding Terminology and Relationships
What is a business application?
A business application is the design view of an application service in the consumer layer. It’s similar to an application you would use outside of ServiceNow. For example, ServiceNow is a business application; so is Workday, SAP, Oracle, and Microsoft Teams. It lines up with business objectives to support your organizational needs.
What is an application service?
An application service is the operational view of a business application, which is the logical view of the deployed application, system, or microsystem. It represents the IT services and components that support and enable the functionality of an application in the highest logic tier. An application service encompasses the technical CIs required to host, operate, and maintain the application.
See the ServiceNow Community article Application Service vs. Application.
How do application services depend on each other?
Application services have dependency on the ServiceNow development application service, ServiceNow test, ServiceNow QA, and ServiceNow production. We call them different instances in different environments. That’s how you connect from a business application to consume an application service.
What is a service offering?
A service offering consists of one or more service commitments that define the level of service in terms of availability, scope, pricing, and packaging options. A service can have multiple service offerings—each available as a separate catalog item—with different service level agreements (SLAs).
What is a technical service?
A technical service has high-level technical functionalities that focus on IT components that support business applications and application services. But sometimes it has a technical customer focus and not a business focus.
As described in “what is a service offering,” a technical service offering has an SLA or an operational level agreement (OLA), which is a commitment to support high availability for your customers. For example, a virtual machine hosting service can provide computer resources in order to run applications and servers with different configurations in different environments (i.e., development, testing, and production).
A technical service can have multiple technical service offerings in a one-to-many relationship.
Defining Business Applications and Business Service Offerings
After aligning IT functionality with technical service offerings, you need to define business applications and provide business service offerings.
Business services are published in the ServiceNow catalog and typically support one or more business capabilities. A business service offering is the commitment of service between you, the services, and your consumers.
CSDM Relationships
How do we link this information based on relationships? We build connections from business applications, logical CIs, infrastructure CIs, and foundation data using CSDM relationships pre-described by ServiceNow.
For example, the business application consumes information from the application service. The application service can be consumed by a business application. A business service offering depends on the application service, then the application service can be used by the business service application. Then from the application service, you can connect to each other (depending on the application) and run on the server.
It’s important to connect data through relationships from the application service to physical CIs. When there’s a server outage, you can automatically detect the impact to the business service offering and take action.
CSDM for Asset Management
CSDM is not only for CMDB; it’s for asset management as well. Using a taxonomy approach, you connect a product model between the asset and CMDB. You can map to an application service in a many-to-many relationship and the CIs from the CMDB, CSDM, and asset connect by their life cycle status.
In the Washington version, the connection automatically synchronizes the life cycle between the CMDB, asset, and CSDM. In the next version, when the one-time data sync operation finishes, CSDM lifecycle values for each product instance represented in the asset and CI tables will be identical. Read Understand Xanadu CSDM new feature in the ServiceNow Community for more information.
CSDM applications always start from a conceptual data model, which is the blueprint to map your service. From the conceptual data model, you map to the ServiceNow CSDM logic table. Populate data in each table relationship, then it’s automatically connected in the application service.
Business application, technical service, business service offering, and technical service offering will use the automated approach in ServiceNow.
Obstacles: Data Quality
You always have to start from the CMDB, the basic data. You can use on-premises and a cloud configure schedule and use your pattern to discover and populate data in each CMDB table.
There is an out-of-the-box identification rule that is fully defined for CMDB tables to identify CIs. An identification rule applies to a CI class and consists of a single CI identifier and one or more identifier entries and related entries, each with a different priority.
For the reconciliation rule, there are multiple data sources, so it’s a challenge to eliminate duplicated entries. Reconciliation rules determine which discovery sources can update CI attributes. Without reconciliation rules, discovery sources can overwrite each other’s updates to attribute values.
Additionally, there are connection issues like how to populate the correct attribute, how to define a required field, and how to scan an attribute that’s not part of the network. You can use data certification on a scheduled job to find information to maintain data quality. Data Certification manages scheduled and on-demand validations of data in CMDB and non-CMDB tables.
Using CMDB Health Dashboards
Before you start with CSDM, the first step is always CMDB remediation to address health issues and improve CMDB health. It’s important to keep your data clean; otherwise, when you connect to infrastructure CI data, you will face a lot of challenges.
ServiceNow CMDB Health dashboards use three key performance indicators (KPIs) to monitor the health of your CMDB: completeness, compliance, and correctness. Each KPI matrix identifies errors (e.g., duplicate records) and with a click, you’re able to go to the record and fix the issue.
When each KPI is at 97%, it’s considered a healthy CMDB. The other 3% you can fix through operational support. When it’s ready to go, then you can start your CSDM data modeling.
Governance and Process Standardization
For CI owners, the support group, the approval group, and the change group, governance and process standardization must be defined to ensure data integrity, accountability, and transparency.
Building your CMDB, establishing governance, populating the CSDM, and data mapping
requires change in your organization. There are role and stewardship responsibilities that can be challenging in organizations with many business units and locations. Effective change management strategies are necessary to address concerns and drive adoption. Communicate the benefits and impact of CSDM implementation to get buy-in from stakeholders.
Benefits include:
- Rationalization. The model aligns IT services with business goals to ensure that IT investments and activities directly support organizational objectives.
- Operational efficiency. Organizations reduce redundancy, avoid duplicated efforts, and streamline processes by adopting a consistent model. This leads to accurately identifying the impact of incidents and changes on services, improving response times, and minimizing disruptions for more efficient service delivery and management.
- Facilitated compliance and reporting. A standardized data model simplifies regulatory compliance and enhances reporting capabilities by providing accurate and consistent data.
- Scalability and flexibility. CSDM supports scalability and flexibility in managing services and makes it easier to adapt to changing business needs and technological advancements.
- Integration and interoperability. The model enhances the integration and interoperability of various IT systems and tools for a more cohesive and efficient IT ecosystem.
CSDM Service Migration Approach
CSDM is divided into five stages: foundation, crawl, walk, run, and fly. Note: The following content in this blog is only a mention of each stage. For detailed steps, read the CMDB Service Migration Playbook and Use Case Examples article in the ServiceNow Community. It has a lot more information about each stage, what you need to do, and how to build your data model as a use case.
In the foundation stage, you populate all the foundation data in a table and build technical services and business services.
In the crawl stage, you focus on application tables to build out the minimum data or information required for incident, problem, and change management. You build a business application that relates to the application service and application. Even if you’re not at a mature stage in your organization, you can understand which applications have an impact.
In the walk stage, you get a mature connection from a technical perspective and IT functionalities, then you define technical services through a dynamic CI group.
In the run stage, you incorporate business services to understand the impact technology can have on a business. You need to define your business and how it relates to technical service through application service.
When you have your services defined, create a request catalog item to populate your service to the business users.
Questions and Answers
Q. What is the difference between a service and a capability?
A. After you have services mapped in the CSDM model, you define the business capabilities that belong to them; it’s the last stage you input into CSDM.
Q. If relationships are not predefined in the CSDM and we don’t have the relationship we want, can we add a new one? How do we know we’re adding the correct one?
A. Go to the relationship table (cmdb_rel_ci)—which has all of the relationships you can choose from—and map a relationship that’s not predefined.
Q. What are the strategies to align to the CSDM through crawl, walk, run, fly that can be done in parallel to where we are today? How do we continue working on our data as-is while we try to undo and realign the data?
A. CSDM is so big that we don’t recommend starting with all business units and all services. Start from one department as a basic unit and map to one application.
If CI data is not clean, you have to go back to change it. However, that impact is big. When you start CSDM, make sure you have a clean and healthy CMDB dashboard for limited impact in future CSDM project implementation.
Start small, then increase to two business units, then multiple departments. This is not a one-year project, it’s an ongoing effort.
Q. On slide nine, you showed the relationships that must be mapped. Does completing all the mappings mean the completion of the CSDM implementation?
A. On the map, you have two sections to consider. One is the infrastructure table and the device is discoverable from different data sources. These relationships automatically map themselves when you populate the CIs. But when you populate data for CSDM logical CIs, you go to the record and select the business application and service offering. When you select the relationship, it is automatically mapped by ServiceNow.
Q. What is the granularity of components that you recommend?
A. When you start a CSDM project, start with one business service and build your data model. You need to understand application services, CSDM objects, and how they support each other.
We have two types of services: technical services and business services. Always start from the technical perspective because of the support by infrastructure CIs, then gradually extend to business services.
Q. Can you explain how CSDM aligns with DPM?
A. Digital portfolio management (DPM) enables you to manage and maintain all your solutions (business services, technical services, service offerings, business applications, and application services) from the DPM workspace.
Here’s a webinar that discusses DPM and CSDM.
Q. If we create our own relationship, will it adhere to the CSDM model?
A. CSDM has pre-defined relationships. When you add a business application or service offering to the application service record, each relationship is automatically created. Note that creating your own relationship may work for the CSDM model, but it may impact outage automation.
Q. Is it good practice to use out-of-the-box features to create new relationships?
A. Yes.
Q. Which license subscription is required for getting CSDM? Does it come as a separate payable plugin?
A. A license is not required to use CSDM. ServiceNow provides all CSDM objectives and CMDB core tables as part of the out-of-the-box CMDB product, regardless of licensing.
Activate the com.snc.cmdb.csdm.activation plugin to begin implementing the framework.
Q. Can you provide example use cases for full implementation? I have CSDM 4.0 draft but couldn’t find examples on all data types.
A. Yes. Read this article in the ServiceNow Community: CSDM Service Migration Playbook and Use Case Examples.
