Interfacing CSDM to Incident/Problem/Change

johnathanr · ‎05-24-2019

I am wondering what the thoughts are for interfacing the CSDM to incident/problem/change. I might be over thinking this situation but am looking for guidance. I will use the ServiceNow CSDM as an example:

I want to know what incidents are related to my specific 'modules' in an application, in this case the ServiceNow Incident Management module. Using the CSDM example it says the Incident Management module in ServiceNow is a 'Business Application in the 'cmdb_ci_business_appl' table. But the documentation also says this class is NOT an operational CI, and is not used in Incident/Problem/Change (IPC).

It appears I can only really related incidents to the 'Application Service' or 'Application' classes -- but none of these would contain the detail of the fact that I am experiencing an issue with the Incident Management module within ServiceNow. The ServiceNow Incident Management Module wouldn't fit into the other two classes (Application, Application Service) becuase it is not 'discoverable' or able to be mapped with service mapping?

Thoughts?

scott_lemm · ‎05-24-2019

Jonathan,

You have hit on a use case that we have not made public yet. That use case is for "Platform" or similar applications. In a Platform use case you have the Platform Host and Platform Apps. Each of those are Business Applications AND related Application Services.

The use case we began with ServiceNow did not reflect the Platform in a manner that ALSO reflects the individual Application Services for each Platform App.

You can, and in most instances should, have an Application Service for each "module" that is then related to the Platform Host. In the example you are using you could have an Application Service (one for each environment/instance) for the module that is related to its Platform Host.

Below is a draft of our ServiceNow as a Platform use case that aligns to this thinking:

In summary, we shouldn't put IPC against the Business Application. If a module/platform_app exists then we should model those elements out as Application Services so an effective IPC effort can utilize them.

Hope this helped.

View solution in original post

Katherine Lewis · ‎08-14-2019

Hi Scott

Hopefully I'm not reading anything special into this, but can you please explain the "No Direct Infrastructure" comment in your diagram above?

Many thanks

Kristoffer Pari · ‎09-21-2020

Hi,

thank you for this great example. I just wanted to ask that is this example still valid or has it changed in any ways?

Another question that i have is that is there any real life benefit of having the different ServiceNow modules as Application Services? Could you just have the different modules as Offerings? Or the other way around, if you have the same support organization for the whole platform, would it be ok to just have one offering for ServiceNow Prod, QA and Dev?

Thanks

Robert80 · ‎06-30-2019

Thank you for showing the working model for the platform use case. I have a question about type and category attributes, and about non-production offerings:

The services table [cmdb_ci_service] includes type and category as attributes. The CSDM says we can extend the OOB service types to meet our business needs which, I assume, is how we could apply the TBM Taxonomy to the CSDM. The TBM Taxonomy has, for example, a service type for End User Services which in turn has a category for Client Computing. Are there any consequences to using type and category like this? I notice category is discussed in the CSDM.

Regarding non-production offerings - we have different service levels for production and non-production environments. If we use Application Service to represent application environments, we can't use outage records to measure availability because they only calculate against offerings. Using offering however could lead to a lot of duplication between offering and application services. Do you have any guidance for this use case?

Thanks.

Sunniva · ‎11-13-2020

Hi Robert,

We have a similar case where Application Services represent different application environments where I don't really see the necessity for an offering (because it would basically mean copying information from the application service) besides the fact that SLA's, availability etc are controlled by the offering. How did you solve this? Did you create an offering basically mirroring the service?

Thanks.

jason45 · ‎09-09-2020

Hi there, confusingly, the Platform Apps are shown with both 'Depends on' and 'Provided by' relationships here.

It should be 'Provided by' ?

Thanks.