7 min read · Jan 7, 2022
--
Back in 2014, I’ve been assigned to maintain and administer an ITSM ticketing tool providing enterprise global support for a large shipping services company.
Back then I’ve just started taking my first steps around the corporate IT landscape, coming from a small startup company my mind was wired to constantly look for improvement.
Soon enough, taking a closer look at their deployed setup, it provided plenty of opportunities.
One such area of improvement was around the categorization of services.
Categorization is an important topic, in a healthy, well-maintained system it provides the opportunity to automate essential parts of the process like prioritization of tickets in support queues along with assignment for initial assessment and triage.
Well-maintained supporting data will provide an efficient overview to business stakeholders on how well their services are performing along with providing an opportunity to continuously reviewing the portfolio and continuously improving the process.
In a future post, I’ll detail the steps CIO’s and Platform Owners should consider while reviewing the health of their support portfolio relying on best practices and modern strategies like leveraging AI models to cut some tedious unnecessary manual work.
Coming back to 2014.
Situation
Reviewing the service catalog, I found a distributed variety of services, resolving in a disconnected set of categorization data, multiple duplications of data without a clear strategy for creation, maintenance, deprecation.
Furthermore, that setup required two (!) sets of categorization data, the first provided by the end-users, used for initial classification.
In addition, similar but not always the same sets of data are used for ticket resolution. Agents working on tickets would normally take the initial classification data and duplicate over resolution categorization.
More importantly, there was absolutely no consistency between different ITSM processes. For example, an incident on a faulty or slow virtual server would be categorized, prioritized, and assigned entirely differently while related/ created as a change request.
Mayhem.
Resolution steps
I’ve set two main goals, the first was to define the required services and their supporting sets of data. The second was to establish a clear set of guidelines to maintain this data.
It took some time and effort but eventually 600+ services catalog, reduced to around 120 services. Clear rules of ownership and maintenance were defined and service lifecycle management was automated as much as it was possible back then.
Even with all the controls in place, the approach was still lacking a much-needed centralized data model.
Fast forward to 2018, I’m no longer working with that project and customer, no longer using the same platform but still facing similar challenges with other customers.
This is where ServiceNow CSDM (Common Service Data Model) comes in.
As an architect, the concept of a proper data model is extremely important.
Thinking about the customer needs, we need to consider both the current set of requirements along with the overall support model, considering future expansion to additional business domains.
What is CSDM?
The Common Service Data Model (CSDM) is a standard and consistent set of terms and definitions that span and can be used with all ServiceNow® products on the Now Platform®. These terms and definitions form the basis for the CSDM framework.
Why should we consider using CSDM?
The CSDM terms and definitions enable service reporting and provide prescriptive guidelines for service modeling within the ServiceNow® Configuration Management Database (CMDB).
The CSDM data model is a CMDB framework that supports multiple configuration strategies. The data model includes guidelines for using base system tables and relationships. Many ServiceNow products depend on data within this data model.
We can use the CSDM as a blueprint to map your IT services to the ServiceNow platform. The CSDM is a CMDB-based framework that identifies where to place data for the products that you’re using. Also, the CSDM is the standard for all ServiceNow products that use the CMDB. Following the CSDM framework ensures that the data your ServiceNow application requires maps correctly to the appropriate CMDB tables.
CSDM 4.0 release
At the time of writing, CSDM 4.0 white paper was yet to be released and ServiceNow official documentation (Rome release) still refers to CSDM 3.0.
An unofficial release details found on the Now Community YouTube page.
What we can expect in CSDM 4.0
The main feature we can expect to see in CSDM 4.0 will be a new Build domain. The purpose of the Build domain is to bridge the gap between the Design domain (this is where we’ll normally find our business applications, business capabilities, and information objects) to Run domain — our managed technical services. This will be achieved by introducing a new class — SDLC Component, CI’s from this class is intended to describe the development of your digital products and shouldn’t be operational, they shouldn’t be used in the context of support tickets like incidents.
Instead, the intention is to relate those CI’s to change records, as a bridge to DevOps & CDM (Sweagle acquisition).
ServiceNow gives an example of an application service configuration change, deployed using DevOps, related to the SDLC component. In case of a deployment issue, it gives support the option to compare between current and previous configurations and find the faulty component which caused the issue.
SDLC Component CI is expected to have two types, application, and technology, tied to the application model and technology service model respectively. A few examples are found in the slide below.
A real-world example illustrates how we might use this class, please note how each SDLC Component CI describes an effort and relates to a specific application service.
Additional changes in CSDM 4.0
Service Portfolio is expected to get a new workspace (Digital Portfolio Management) to be released in 2022.
Note, this won’t be part of the existing Service Owner Workspace.
The next change is about how we create Business Services. To me personally, this change is very welcome as it caused confusion with many customers. Now instead of using the legacy classification attribute, we have a new dedicated table (cmdb_ci_service_business).
Great stuff.
Migration tool and strategy isn’t part of the Rome release so no rush to make changes in your existing data model but if you’re just joining the party, Business Service table should be your target.
Interesting discussion around the usage of Business Process (Foundation domain) and its wide impact beyond just CMDB Cis. ServiceNow envisions it to be part of GRC and business continuity, it will be very interesting to see a real example how this data can enrich and support the overall data model.
Lastly for this article, Locations table gets addressed with its core issues that surface every time in customers' environments.
The first issue is to address the multiple data sources feeding this table and potential duplicates that need to be cleaned. ServiceNow adds Source ID and Validation fields to specify the source system of each data record and the option to specify if it's primary or duplicate. Personally, I wouldn’t necessarily solve it like this as duplicated records will still exist and will need to be addressed using reference qualifiers, but we’ll see how customers will adopt and use this solution.
The other, more significant change is about having a hierarchy of locations.
Up till this point, we had the data stored flat in locations table but, for many customers, flat data isn’t sufficient and we would find records for regions, countries, cities, sites, buildings, and more. Furthermore, it’s expected to filter this data and represent only subsets of the data when needed throw business logic. Along with functional validations (for example can we have a record for Floor without relation to Building?) In the past, this was achieved via customizations, and it's very nice to see adopted and structured OOB.
That’s just part of the changes and it’s very exciting to see ServiceNow invest in frameworks and practices to support business application and platform products. There are many other changes we’ll cover in part 2, along with some best practices and implementation tips. Stay tuned.
For more details, don’t hesitate to reach out.
