With the release of Tokyo, ServiceNow published a new version of the CSDM framework. Many of you might wonder what the key differences are to the previous version. In this article, we cover what has changed, what is new, and what DevOps have to do with all of this.
The previous version of the Common Service Data Model was published along with the Paris release in September 2020, and a lot has changed since. Before we dive deep into the differences between the two versions, let's recap what CSDM is all about.
What is “Common Service Data Model”?
The Common Service Data Model (CSDM) is a framework and common model that gives a standard and shared set of service-related terms and definitions which are leveraged by all ServiceNow products and the platform that will enable and support true service level reporting. It works as a connection between business and technical perspectives. CSDM helps you understand what data belongs in which tables and provides recommended relationships to be used between the Configuration Items (CIs) in Configuration Management Database (CMDB).
|
Common Service |
Data Model |
CSDM provides visibility into application and service data from different domains. CMDB with high-quality CSDM, gives you full visibility and understanding how your infrastructure is consumed by the business and who is managing what parts of infrastructure. Knowing this gives you multiple benefits like faster incident resolution time, better understanding of the impact of changes to your infrastructure and better security.
By following this standardized data model, ServiceNow products can utilize the CMDB in its intended way and you can take better advantage of ServiceNow product portfolio.
Read our blog: Top features from the ServiceNow Tokyo release
CSDM Conceptual Model
The CSDM Conceptual Model illustrates how different domains interact and work together to manage your services and applications in the ServiceNow platform and how different roles consume this data model. In the middle of this model, there is the Manage Portfolio -domain, which encompasses parts of all the other domains and is a layer on the top of the CSDM Conceptual Model.
- Build* – Represents tables to give visibility in the built effort and logical development details of enterprise application
- Design – Includes tables used by the Application Portfolio Management (APM). Typical users of data in this domain are IT application owners and enterprise architects
- Manage Technical Services – Represents the tables used by IT Operations Management (ITOM), such as Service Mapping and Discovery, and the portfolio of Technical Services and related Service Offerings
- Sell/Consume – Represent the portfolio of Business Services and related Service Offerings which may consume elements from the Manage Technical Services -domain. This domain is commonly utilized by Service Portfolio Management (SPM) and Customer Service Management (CSM) applications
- Foundation – This domain includes the tables where critical reference data from or to other domains are stored
*New domain introduced in CSDM 4.0
Key changes between CSDM 3.0 & CSDM 4.0
1 | New domain – Build
Build domain is the latest addition to the CSDM Conceptual Model. For the time being, there is only one table in this domain called Software Development Lifecycle (SDLC) Component. Build Domain bridges the gap between Design & Manage Technical Services domains. This domain gives visibility to logical development details of applications utilized by the business.
While ServiceNow DevOps product is not required to use this table, it brings added value by providing capability to visualize and manage your application development pipeline. The Configuration Items in tables in this domain are not operational, hence they can not be referenced by ITSM processes such as Incident, Problem and Change Management.
2 | New CMDB class – SDLC Component
Software Development Lifecycle Component is a new class in Build domain which is referenced by the DevOps. Configuration Items in this class represent a unique development effort of code. The idea behind this class is to chop larger Business Application / Digital Product into individually developed components.
There are two types of SDLC Components:
- Application related – for example Microservices, APIs
- Technology related – for example Database Configurations, Security Configurations
When we take a look at the Conceptual Model of CSDM 3.0, we can see that Business Applications were directly related to Application Services. In the new model, we have SDLC Component between these two classes to track different Microservices and APIs a Business Application might have.
The value added by the SDLC Component class can be demonstrated by following scenario:
Let’s imagine we have a Business Application which is used to manage online sales. This Business Application has different microservices such as Taxation calculator & Currency converter. There has been major development update to Currency converter microservice and hence the SDLC Component “Currency converter” was updated by the DevOps team. Users of a Business Application start to report that currencies are not converted correctly.
Thanks to SDLC Component, we now have visibility of what has been changed and when in the configuration of Business Application, and we can immediately pinpoint that most likely reason for the issue is the development update to Currency converter microservice.
SDLC Component [cmdb_ci_sdlc_component] class can be activated by installing plugin CMDB CI Class Models [sn_cmdb_ci_class], version 1.33.0 or newer. This class is considered as optional for the CSDM; hence you should first assess whether using this class will bring any added value for your organization as it is heavily DevOps focused class.
3 | Dedicated class for Business Services
When we take a look into the hierarchy of Service -table, we can see that something has changed. Business Service [cmdb_ci_service_business] -class has now its own table and no longer resides in general Service [cmdb_ci_service] -table. Please note, that there is no yet mechanism in place to move your Business Services from old table to new table, hence there is no rush to migrate to the new model.
4 | Location Management – Data Model extension
Anybody who has been working with location data, knows how hard it is to keep your Locations data in clean state. Having data sources integrated to Location -table can result including, but not limited to stale entries, misspellings, duplicates and unmanageable amount of Location records. Deleting these incorrect entries in table does not really help as all it takes is to integration run and you are again at the starting point.
How about the different types of Locations? Depending on the organization needs, there might be use cases to track locations in level of Building, Floor or Room.
To solve these problems, ServiceNow has introduced new attributes to the Location data model:
Source ID – What is the source of Location data for a particular record?
- Location Type – Where does this Location fit in the hierarchy of locations?
- Managed by Group – Who is governing this location record?
- Validation – Is this location record duplicate or primary record?
- Life Cycle Stage & Life Cycle Status – What stage is the location on in its lifecycle?
5 | Life Cycle Management – Consistency in the life cycle process
Did you know that over 50% of ServiceNow clients customize the choice lists for one or more out-of-the-box status/state fields across ITAM & CMDB, and there are 9 of such fields. While there is nothing wrong in customizing these choices to better fit your needs, it makes it hard for ServiceNow to build any added functionality around these fields. To solve this problem, ServiceNow is introducing the Life Cycle capability to Foundation -domain.
There are two new attributes added to the data model:
- Life Cycle Stage – Stage or phase of an overall life cycle process
- Life Cycle Status – Status or step within a Life Cycle Stage
Together, these two attributes provide an overall place within a life cycle process.
Life cycle processes utilizing the new Life Cycle attributes are:
- Product Life Cycle Process – Used by Product Models in the Product Catalog
- Hardware Life Cycle Process – Used by Hardware Assets and CIs in the AMDB and CMDB
- Logical Life Cycle Process – Used by Logical Assets and CIs, such as Software Assets, Services and Applications
- Document Life Cycle Process – Used by Contracts and Business Processes
- Location Life Cycle Process – Used by Location records in the Location -table
While there is no rush to start to use new Life Cycle Stages and Statuses, some currently available ServiceNow product features such as the CMDB Data Manager require that mapping capability from the legacy statuses and states is enabled. When migrating to the new Life Cycle capability, it is recommended to evaluate your dependencies to the legacy statuses and states, such as integrations, business rules, scripts etc.
6 | Service Portfolio now references Technical Service -table
When we take a look at the CSDM Conceptual Model, we can see that the Service Portfolio now has a reference to Technical Services. Previously, there was a technical limitation within the Service Portfolio, and it was not possible to relate the Technical Services to the Service Portfolio and grant access to hierarchical categorizations of the Services in there. This was already changed in the Rome release, but now it is officially part of the CSDM model and documentation.
Business & Technical Services in the Service Portfolio can be visualized and managed by the Digital Portfolio Management application, which was enhanced and updated in the latest Tokyo release.
7| Business Process class in Foundation domain
Business Process class is now part of the Foundation domain. While Business Process is a class in CMDB, it is not part of any other domain in CSDM as the vision and use cases for Business Process class move beyond the CMDB. Additional functionality to the Business Process class is introduced by the Governance, Risk and Compliance (GRC) & Business Continuity Management (BCM) applications
Final thoughts
The Common Service Data Model is constantly being developed further by ServiceNow and there have been and will be changes to it. Keeping up with all the changes is a big and time-consuming task to ask. You should not rush to implement all the elements introduced in CSDM 4.0. It usually takes a couple platform releases for ServiceNow to build capabilities on top of new elements and utilize them to their full intended extent.
Instead, we recommend you to take a look at the CSDM implementation approach and assess on which stage your organization currently resides and what you need to have in place to move to the next stage.
If you are new to CSDM, it is not recommended to try to implement all elements at once. We recommend approaching CSDM in a staged manner. You first need to learn how to walk before you can run.
Remember, that while CSDM is a powerful framework for CMDB data modeling, providing you with guidance and visibility, it is not definitive. It is fine to implement elements in order which suit the goals of your organization and focus on elements which give you the most value.
Discover the power of CMDB in IT service management with ServiceNow; read our article about unleashing the power of CMDB-integration with ServiceNow