16 Jul The Common Service Data Model, and why it matters
Unless you are a true data-geek, I doubt you spend much time thinking about data models and how they can help you get value from existing tools, but if you are using ServiceNow, the Common Service Data Model (CSDM) might well change your thinking – especially if you’re looking to get the most out of your ServiceNow platform, implementing multiple components of the product. This might not seem like such a big deal until you start to realize just how vastly capable and broad the platform has become, and how many modules interrelate in value-adding ways. (Click on Figure 1 for more.)
Since ServiceNow’s launch, a key selling point of the platform has been how easy it is to tailor it to suit your needs – it’s predominantly a workflow platform, after all! While this has been great for many people, giving them exactly the configuration and flexibility they were looking for, it has also led to some problems as the platform has grown. As Peter Parker would say, “With great power comes great responsibility”. Because ServiceNow made it easy to do pretty much anything, yet provided relatively little guidance on what you SHOULD do, many ServiceNow environments ended up heavily customized, and overburdened with “tech debt” (i.e. things that will need to be reworked properly at a later point).
This tech debt burden has consistently gotten in the way of implementing new features and capabilities, increasing the time-to-value of adoption new ServiceNow capabilities, or creating lots of busy work trying to get your environment ready to upgrade to the current release. It’s even led to the phenomenon of the zBoot (link) – basically a complete reimplementation of ServiceNow from a clean instance to eliminate the customizations.
What has all this to do with the CSDM? I’m glad you asked!
The CSMD represents ServiceNow’s first serious attempt to describe how the underlying core data structures across the platform are supposed to be used, and how they relate to each other. It provides a roadmap for how to design and implement key elements of your CMDB, Service Portfolio, and Application Portfolio landscape, leaving the guesswork aside for a change, and I expect this to spread further through other data structures as the model matures.
On the face of it, the model is deceptively simple (see Figure 2), showing clear and simple linkages between a service and constituent parts, but the complexity and sophistication is in how these elements come together to form a whole that is greater than the sum of its parts. Simply put, a Service (e.g. “Email Service”) has Service Offerings that describe the different Offerings (bundles) available (e.g. “standard mailbox 100GB, 99% SLA” or “VIP mailbox 1TB 99.9% SLA”), and makes the orderable components of that service (e.g. “Order new Mailbox”, “Restore Mailbox”) available through Service Catalog items.
The Service also has a linkage to the application(s) supporting it (e.g. Microsoft Exchange – Production Deployment), which are in turn linked to the supporting infrastructure. Note that this bottom left box represents almost the entire Configuration Management Database, which is a highly complex subject in itself.
While the lower elements of the model focus more on operational elements, the upper linkages relate more to architecture and rationalization. For example, the business applications component (e.g. Microsoft Exchange Server, SAP, etc.) provides a way to recognize that, while you may have multiple instances of an application deployed, they are fundamentally the same actual Business Application. This can help with planning application lifecycles and understanding upstream/downstream end-of-life issues.
Business Capabilities describe the activities that a business performs, and links to the business applications that support them. For example, a business capability could be “Manage accounts receivable”, and one of the business applications supporting that activity might be SAP.
Taking this one step further and looking at it from a service-owner viewpoint (see Figure 3), you can see how the different components and roles responsible for delivering services are interrelated.
This data model supports the entirety of the IT Service Management, IT Operations Management, Customer Service Management, and SecOps & GRC modules, and even bleeds into the IT Business Management capabilities. What may not be immediately apparent from this over-simplistic view is the depth of capability that this brings, for example:
- The ability to get a consolidated view of Service Performance from a Service Owner view’s perspective, as shown in the images below
- Being able to understand the cost & complexity of your environment, in order to start driving rationalization
- Gaining an end-to-end perspective of the application and its dependencies when trying to resolve a service disruption
- Tracking and managing risks and security issues within a service context
- Being confident in your ability to stay current with ServiceNow releases and adopt the latest features with minimal issues
The following images illustrate ServiceNow components actively using data from the Common Service Data Model, which shows how many parts of ServiceNow CSDM touches.
ServiceNow Screenshots relevant to CSDM
To summarize, if you are using ServiceNow in any serious fashion, and have not yet read the CSDM whitepaper or put plans in place to migrate your data to this structure, this needs to be at the top of your TODO list – this is the equivalent of laying a robust foundation for deriving significant value from a long term ServiceNow investment.