In mid December in 2018 ServiceNow released a whitepaper introducing their first version of the Common Services Data Model.
In this article I will go through the “ITSM / ServiceNow example” from that whitepaper and introduce an alternative version. And discuss about the common data model drawn from three different perspectives.
ServiceNow ITSM example
The whitepaper from ServiceNow included an example where ServiceNow system was used as an example of using the “Common Services Data Model”.
ServiceNow CSDM – ITSM example
This example has the same “issue” that I described in my previous post. It’s not applicable to all types of services. Therefore it’s not common. It is a model that is specifically designed for Business Applications. But it can be turned into a more generic example.
Alternative ITSM example
In this alternative example we have again moved Business Applications under the Service Offerings. And made Business Capabilities “dependent on” services instead of applications. In real life, services are the ones creating value and enabling/providing business capabilities while applications are “just tools” used by the services.
In addition, I would not consider “SN Mid Server” as a Business Application nor Application service. Instead, I would include that as an Application (+Server) under the “technical CMDB”. So, in the example below both Business Applications and Application Services are part of the “CMDB” and therefore presented as orange boxes.
Alternative ITSM Example
Alternative ITSM example
By using example we can also draw a more generic service model which includes “Business Capabilities”, “Service Portfolio” and “CMDB” as three different, but connected, data models.
Generalized ITSM Example
For a “common services data model” I would argue that model for defining the Business Capabilities part and Service Portfolio can be rather common, regardless of service. Especially the Service Portfolio should have common model, how services are modeled on the portfolio level. And how they are connected to Business Processes and Capabilities and CMDB. But each service can have their own “Blueprint”, since different services are dependent on different technology, processes, people and other assets.
Generalized Example
So, these three perspectives together would create a “common services data model”:
- Business Capabilities – Enterprise Architecture perspective
- Service Portfolio – Service Management perspective
- CMDB – Service Configuration perspective
For the CMDB, each service would define it’s own “Service data blueprint”. And all these blueprints together would make a CMDB data model. Each blueprint would need to follow an agreed way to connect to Service Porfolio (and Business Capabilities).
What do you think?
How have you combined Enterprise Architecture, Business Capabilities, Business Processes, Service Portfolio(s), Application Portfolio(s) and rest of the CMDB together in a holistic model?
I would like to hear your thoughts as comments below. And of course you can also contact me directly to discuss more on the topic.
ServiceNow CSDM Overview
Read the first part also related to this ServiceNow whitepaper.
Mikko Juola
Mikko is the Product Manager for Data Content Manager, a NowCertified ServiceNow application.
Get Started with Data Content Manager!
We are confident that after the Free Trial you will want to continue with DCM. However, if, for whatever reason, you are not convinced DCM will by far bring more value than it costs, you simply stop using it when the Free Trial ends. There are no strings attached!
Hi Mikko
Thanks for the great information. I find the site very informative. I wondered if you could elaborate a little on (each service would define it’s own “Service data blueprint”) I’m not clear with this and further explanation would be helpful. I’m a novice and trying to get my head around the CSDM.
Thanks Boomer
Hi John,
By “each service would define it’s own Service data blueprint” I mean that the techical details for each service varies. Some services are related to Business application, others to facilities and some for end user devices. Each of these services or service areas should define what data is needed to manage and run the services. And these requirements can be quite different for workstation lifecycle management, business application management or onsite support for example.
But, all these blueprints should be compatible with each other. So, there has be to a big picture about the “common data model” that is then getting into more details for each service or data domain within the CMDB.
–Mikko