Mark, Kudos to you! I have been trying to piece-meal information to clearly understand CSDM components. This is the best reference (video & articles) that I have gone through. It clearly provides the right level of purpose, clarity and specificity!!
These conceptual examples are useful. Can you also demonstrate how all of these elements are created in the platform so we can see all of this in action?
There are various ways they are created on our platform. For a fairly good walk through, look for our CSDM lab in K21. There is an older lab on our Now Learning portal as well, the K21 lab will replace it shortly.
Ron I agree so much. This was great, but I think the final piece would be - ok, now let's show how they are added to the platfrom. As in where, and how. How meaning manual, discovery, service mapping etc.
Thanks for your video. That helps a lot. In our organization, we do not offer Business Services Offerings to customers that include all applications, but for the most part separately the individual applications by name. Do I then do this via the Technical Service Offering?
Really useful to see some concrete examples of how to implement CSDM. With regards to the Application Service for a Platform app. I do not see anything in the White Paper or the documentation that differentiates between the module and the host Application Service. Do you have any plans of introducing an attribute or a dedicated table to distinguish between these, when looking at the form?
In all of the CSDM examples I've seen, a Technical Service Offering is being used to represent an Infrastructure Service. Infrastructure Services are operational services(ITOM Services) with a severity that is the result of impact propagation from all of the downstream Infrastructure CIs it depends on. ITOM services are modeled in the CMDB using the Application Service and Application Service Group classes. In the Operator Workspace(and legacy Event Dashboard) they are color coded to represent their current severity (which is calculated based on the severity of all downstream CIs) The colors help operations and support teams to identify the root cause of an incident (They drill down through the service hierarchy using the colors to guide them to the root cause). An Application Service Group called "Windows Servers" might have a child Application Services for each environment(e.g. "Windows Servers(Prod)"...). The "Windows Servers(Prod)" Applications Service might also be a member of another upstream Application Service Group (e.g. "Platform Services (Prod)") which belongs to a higher level Application Service Group (e.g. "Infrastructure Services (Prod)) which may belong to an upstream Application Service Group (e.g. IT Services (Prod)). I don't feel that Technical Service Offerings should have a "contains" relationship to operational CIs below the Service level in the operational hierarchy. Service Mapping already maintains the Service to Hardware, and Application CI relationships. Adding redundant relationships from Discovered CIs to Service offerings adds no value. They could all eventually become stale and will require manual cleanup. Instead I would suggest relating the Technical Service Offering's RITM tasks to the CIs they create and leave the rest up to ITOM to manage. Are SPM "Services" really Services? I believe the answer is a resounding No. It is a best practice within the Configuration Item class hierarchy to not create instances of a class that has subclasses unless discovery classification fails and you can determine the subclass. This best practice was violated when the Computer class was used to model all handheld devices, Tablets, PCs and Desktop computers that are not running a "server" OS. This has led to many issues that developers are familiar with. I hope this will eventually be fixed by creating a subclass of computer for each of the different types of devices and having the SCCM integration and ITAM applications put them in their proper classes when they are created. We have a similar issue with the Service(cmdb_ci_service) class that needs to be resolved. The Service (cmdb_ci_service) class (formerly labeled as Business Service in previous releases) is still referred to in CSDM literature as Business Service. The Service base class has never been used to hold ITOM Service CIs. (ITOM followed best practices). The Service class is the parent class for all ITOM Application Services and Application Service Groups It is also the parent class for the recently added SPM Technical Service and the SPM Service Offering classes. I don't know when this situation was created because I had never seen any instances of the Service base class until SPM Services became part of the CSDM and demo data with Business Services appeared in new instances. It was explained to me that SPM services were only used by customers who did not purchase ITOM applications. Eventually all SPM services would be migrated to Application Service subclasses along with the Hardware CIs they depended on. I thought this was just a transitional issue that would go away with time. What CSDM is currently calling a Technical Service or a Business Service in the CSDM model is actually a specific type of Service Offering (a selectable offering in Service Catalogs). This has been bothering me for years and I feel it needs to be corrected as soon as possible. Service Offerings are grouped and organized into a hierarchy within a Service Catalog. SPM Business Services, SPM Technical Services and SPM Service Offerings do not look or act like Services. They don't run on servers and don't have an operational state so they should never appear in a list of Impacted/Related CIs or Services for an incident or change. I feel strongly that they should be be moved out of the CI class hierarchy and be modeled like tasks and requests. I think of Service Offerings as Request definitions that are used to construct different types of service catalog requests. That would solve a number issues caused by the current model which has the Business Service class as the parent class for Application Services. Service Offerings and Application Services are distinctly different concepts that should each have their own independent tables instead of sharing the Service table. Today, Application Services are forced to inherit attributes, and suggested relationships from the Business Service classes that make no sense. The fact that the status field Choice values are so different is a red flag indicating that they need to be separated into different branches of the table herarchy. On ITSM forms where the form as asking for a Service (e.g. an operational Service that could be impacted by the incident or change), the reference qualifier returns both ITOM operational services and SPM "Services" because the field is a reference to a Service (and they all share the same parent class (cmdb_ci service). As a result, every customer has to filter out the SPM "Services" to prevent users from selecting them whenever the field is modeled as a reference to the Service table. Sorry for the long post. Maybe I should move this to the Community forum where we can have some good discussions.
I'm really pleased to see this example, however I'm not convinced that adding the release name "Paris" to the CI names is helpful. Wouldn't that be better being an attribute within the CIs? If not do you update the CI names per release or do you create new CIs with each new release?
Very Nice stuff, we need more of these examples. @Mark I dont get the linking of one Application Service to another, Is it not easier to link them to the Business Application Platform Host?. Secondly in the SAP example, is there any guidance to explain to the "Customer Service Manager " in sell/consume side when and how they should design Business Service Offerings? For instance you used 2 offerings (inventory mgmt & Product Line Status), It could also have been one offering (Manufacturing), Is there any guidance to advise such owners ?
The design of offerings in relation to the application services I’ll cover in the near future. This is a topic on its own that takes into account many variables. There is more “rules of thumb” approach that we will characterize when creating the model.
@@layioye1 thanks a lot. Please here is my email anse4astroo@yahoo.com, send me a message or still you can share your details if you feel it's more convenient for you
Thanks Mark, this is very useful. Can you say why the ‘service’ product model is not used to capture the product specification for SaaS products like ServiceNow? It would be a simpler solution than adding the extra ‘application’ CI in the case of the ServiceNow example. Or does that approach miss something? Thanks.
@@ServiceNowCommunity Sorry, but that’s doesn’t seem correct unless I misunderstood your SN documentation. Service product models OOTB are mapped to Application Services via the Model Category, because they represent SaaS products, like SN. Please check?
It's a possible option, but in general Service Product models describe aspects of the service design and Offering. Things like Commitment, SLA's etc. Given the overloading of Service, a bit of a slippery slope to define Service Models that equate to product models that provides provide that are based on code. We will provide a bit more guidance on the Product Model tables and use in the next year, our product-centricity will evolve, so stay tuned...
@@cuspate If you are referencing the Asset Management interface, there is a Service Model aspect there, but that's not typically tied to or changed when the code on the service changes. Our platform version is changed independent of the service model in a catalog today, there is no real direct correlation there.
@@markbodman Yep. The SN docs describe it as “A service model is a class of product models to define Software as a Service (SaaS) products. It defines the service and contains the different attributes, choices, and components that can be configured to a customer’s specifications. Service models have a specific model category called Application Service, which links a service model to the Application Service CI class.”
@@cuspate Yea, I’m aware and it’s a possible option. In practice I haven’t seen it versioned there. In fact most folks don’t know the versions of their SaaS software, as it’s changed / updated automatically. Office 365 for example.
Examples are one of the best ways to understand CSDM. Thanks for sharing.
Mark, Kudos to you! I have been trying to piece-meal information to clearly understand CSDM components. This is the best reference (video & articles) that I have gone through. It clearly provides the right level of purpose, clarity and specificity!!
Thanks Mark. Your examples have helped me to start piecing the CSDM together
Amazing examples . thank you for making this video. Now I am able to connect theoretical definitions into practical examples.
Very useful information and well illustrated. Thanks @Mark. 👍🙂
Great video Mark. This was very helpful for me!
These conceptual examples are useful. Can you also demonstrate how all of these elements are created in the platform so we can see all of this in action?
There are various ways they are created on our platform. For a fairly good walk through, look for our CSDM lab in K21. There is an older lab on our Now Learning portal as well, the K21 lab will replace it shortly.
Ron I agree so much. This was great, but I think the final piece would be - ok, now let's show how they are added to the platfrom. As in where, and how. How meaning manual, discovery, service mapping etc.
Awesome explanation
Thanks for your video. That helps a lot. In our organization, we do not offer Business Services Offerings to customers that include all applications, but for the most part separately the individual applications by name. Do I then do this via the Technical Service Offering?
Really useful to see some concrete examples of how to implement CSDM. With regards to the Application Service for a Platform app. I do not see anything in the White Paper or the documentation that differentiates between the module and the host Application Service. Do you have any plans of introducing an attribute or a dedicated table to distinguish between these, when looking at the form?
Great video. I'm just a question: is a manual approach to define application services and business services?
In all of the CSDM examples I've seen, a Technical Service Offering is being used to represent an Infrastructure Service.
Infrastructure Services are operational services(ITOM Services) with a severity that is the result of impact propagation from all of the downstream Infrastructure CIs it depends on.
ITOM services are modeled in the CMDB using the Application Service and Application Service Group classes.
In the Operator Workspace(and legacy Event Dashboard) they are color coded to represent their current severity (which is calculated based on the severity of all downstream CIs)
The colors help operations and support teams to identify the root cause of an incident (They drill down through the service hierarchy using the colors to guide them to the root cause).
An Application Service Group called "Windows Servers" might have a child Application Services for each environment(e.g. "Windows Servers(Prod)"...).
The "Windows Servers(Prod)" Applications Service might also be a member of another upstream Application Service Group (e.g. "Platform Services (Prod)") which belongs to a higher level Application Service Group (e.g. "Infrastructure Services (Prod)) which may belong to an upstream Application Service Group (e.g. IT Services (Prod)).
I don't feel that Technical Service Offerings should have a "contains" relationship to operational CIs below the Service level in the operational hierarchy.
Service Mapping already maintains the Service to Hardware, and Application CI relationships.
Adding redundant relationships from Discovered CIs to Service offerings adds no value. They could all eventually become stale and will require manual cleanup.
Instead I would suggest relating the Technical Service Offering's RITM tasks to the CIs they create and leave the rest up to ITOM to manage.
Are SPM "Services" really Services?
I believe the answer is a resounding No.
It is a best practice within the Configuration Item class hierarchy to not create instances of a class that has subclasses unless discovery classification fails and you can determine the subclass. This best practice was violated when the Computer class was used to model all handheld devices, Tablets, PCs and Desktop computers that are not running a "server" OS. This has led to many issues that developers are familiar with. I hope this will eventually be fixed by creating a subclass of computer for each of the different types of devices and having the SCCM integration and ITAM applications put them in their proper classes when they are created.
We have a similar issue with the Service(cmdb_ci_service) class that needs to be resolved.
The Service (cmdb_ci_service) class (formerly labeled as Business Service in previous releases) is still referred to in CSDM literature as Business Service.
The Service base class has never been used to hold ITOM Service CIs. (ITOM followed best practices).
The Service class is the parent class for all ITOM Application Services and Application Service Groups
It is also the parent class for the recently added SPM Technical Service and the SPM Service Offering classes.
I don't know when this situation was created because I had never seen any instances of the Service base class until SPM Services became part of the CSDM and demo data with Business Services appeared in new instances. It was explained to me that SPM services were only used by customers who did not purchase ITOM applications. Eventually all SPM services would be migrated to Application Service subclasses along with the Hardware CIs they depended on. I thought this was just a transitional issue that would go away with time.
What CSDM is currently calling a Technical Service or a Business Service in the CSDM model is actually a specific type of Service Offering (a selectable offering in Service Catalogs).
This has been bothering me for years and I feel it needs to be corrected as soon as possible.
Service Offerings are grouped and organized into a hierarchy within a Service Catalog.
SPM Business Services, SPM Technical Services and SPM Service Offerings do not look or act like Services. They don't run on servers and don't have an operational state so they should never appear in a list of Impacted/Related CIs or Services for an incident or change. I feel strongly that they should be be moved out of the CI class hierarchy and be modeled like tasks and requests.
I think of Service Offerings as Request definitions that are used to construct different types of service catalog requests. That would solve a number issues caused by the current model which has the Business Service class as the parent class for Application Services. Service Offerings and Application Services are distinctly different concepts that should each have their own independent tables instead of sharing the Service table. Today, Application Services are forced to inherit attributes, and suggested relationships from the Business Service classes that make no sense. The fact that the status field Choice values are so different is a red flag indicating that they need to be separated into different branches of the table herarchy. On ITSM forms where the form as asking for a Service (e.g. an operational Service that could be impacted by the incident or change), the reference qualifier returns both ITOM operational services and SPM "Services" because the field is a reference to a Service (and they all share the same parent class (cmdb_ci service). As a result, every customer has to filter out the SPM "Services" to prevent users from selecting them whenever the field is modeled as a reference to the Service table.
Sorry for the long post. Maybe I should move this to the Community forum where we can have some good discussions.
Very useful, thx!
Good stuff!
I'm really pleased to see this example, however I'm not convinced that adding the release name "Paris" to the CI names is helpful. Wouldn't that be better being an attribute within the CIs? If not do you update the CI names per release or do you create new CIs with each new release?
Very Nice stuff, we need more of these examples. @Mark I dont get the linking of one Application Service to another, Is it not easier to link them to the Business Application Platform Host?. Secondly in the SAP example, is there any guidance to explain to the "Customer Service Manager " in sell/consume side when and how they should design Business Service Offerings? For instance you used 2 offerings (inventory mgmt & Product Line Status), It could also have been one offering (Manufacturing), Is there any guidance to advise such owners ?
Hello @Dele Layioye, trust you are well. I work as a ServiceNow administrator. Please do you mind if we connect?
The design of offerings in relation to the application services I’ll cover in the near future. This is a topic on its own that takes into account many variables. There is more “rules of thumb” approach that we will characterize when creating the model.
@@anselemokeke8315 nope, don’t mind 😀
@@layioye1 thanks a lot. Please here is my email anse4astroo@yahoo.com, send me a message or still you can share your details if you feel it's more convenient for you
@@markbodman can you (or anyone else ☺) point out which video that came to cover "design of offerings in relation to the application services"?
Thanks Mark, this is very useful. Can you say why the ‘service’ product model is not used to capture the product specification for SaaS products like ServiceNow? It would be a simpler solution than adding the extra ‘application’ CI in the case of the ServiceNow example. Or does that approach miss something? Thanks.
@@ServiceNowCommunity Sorry, but that’s doesn’t seem correct unless I misunderstood your SN documentation. Service product models OOTB are mapped to Application Services via the Model Category, because they represent SaaS products, like SN. Please check?
It's a possible option, but in general Service Product models describe aspects of the service design and Offering. Things like Commitment, SLA's etc. Given the overloading of Service, a bit of a slippery slope to define Service Models that equate to product models that provides provide that are based on code.
We will provide a bit more guidance on the Product Model tables and use in the next year, our product-centricity will evolve, so stay tuned...
@@cuspate If you are referencing the Asset Management interface, there is a Service Model aspect there, but that's not typically tied to or changed when the code on the service changes. Our platform version is changed independent of the service model in a catalog today, there is no real direct correlation there.
@@markbodman Yep. The SN docs describe it as “A service model is a class of product models to define Software as a Service (SaaS) products. It defines the service and contains the different attributes, choices, and components that can be configured to a customer’s specifications.
Service models have a specific model category called Application Service, which links a service model to the Application Service CI class.”
@@cuspate Yea, I’m aware and it’s a possible option. In practice I haven’t seen it versioned there. In fact most folks don’t know the versions of their SaaS software, as it’s changed / updated automatically. Office 365 for example.