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”.
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.
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.
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.