ServiceNow has published an update to the Common Service Data Model whitepaper couple of weeks ago.
Updates are quite minor. Some additions to class descriptions and some more examples like a model for “products that are sold to external customers”.
The “actual data model” is still on a quite high level. And as a guideline for applying the CSDM, whitepaper states the following:
Applying CSDM to customer environments requires a little bit of planning since each customer environment is slightly different and the degree of management can vary from organization to organization.
I fully agree. Each customer environment is different and therefore data models for different areas are usually different as well. But we could try to come up with a more detailed class level data model for the “common parts” like a Service Portfolio. And in general, I do feel that even though customer environments are different, data models for CMDB are (or should be) 80% the same.
The Figure 1 below shows the actual tables in ServiceNow against the conceptual model described as the CSDM. This picture is taken directly from the whitepaper.
Figure 1 – CSDM – From Conceptual to Physical model
The following picture illustrates one interpretation of the Common Service Data Model on a more detailed class level. Red classes are “planned”, since those were not available in the instance where a drew this diagram. But should be available in later ServiceNow releases (Madrid or New York).
I have used Data Content Manager to visually design these data models.
Figure 2 – More detailed data model for Service Portfolio
This data model has been drawn from the Service Offering’s point-of-view. And the “Service Configuration” (bottom left part of the model) is from the Application Management area. That can be generalized simply by removing the Business Application and Application Service classes and connecting Service Offerings directly to the more generic Configuration Item class.
There are some differences compared to the examples available in the whitepaper. For example, placement of the Business Application class is different and Service Offering is used twice.
The Service Offering class is used twice to differentiate between “Customer or Business Facing Service Offerings” and “Supporting Service Offerings”. This is not mandatory, but recommended for may organizations who would like to manage their internal and external service providers as “supporting services” while keeping the upper level services tightly connected to business requirements. Kind of similar what ServiceNow is pointing out with different Service types, but slightly different approach. Did someone just mention SIAM?
The main point with two different levels of Service Offerings is that many of the Business Facing Service Offerings (BFSO) are actually using same “resources” or services underneath. For example Business Application related BSFOs may use same kind of Infrastructure Services which are provided by an external vendor having a separate contract with IT organization regarding capacity services while the business has made contracts with IT about the Application Management as a whole.
All in all, the data model presented above is quite demanding and can be used as an example of a rather mature service portfolio model. Therefore I created another, more simple, version of the same that could be used by many organizations who are just starting their Service Portfolio Management journey.
Figure 3 – Simpler version of the Service Portfolio data model
Have you already started using Service Portfolio in ServiceNow?
What are your thoughts on the models above and have you planned or even implemented something different?
I’d like to hear your thoughts in the comments below. Or you can also contact me directly to discuss more on the topic.
The data model diagrams above are drawn with a Blueprint Designer which is part of our Data Content Manager – ServiceNow application.