Interfacing CSDM to Incident/Problem/Change

[johnathanr]

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 · Accepted solution]

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.

[melissahill]

This helps a LOT.  I also like how the application service modules are dependent on one application service for the ServiceNow Production instance.  If we had to track each module for each environment, that would get quite cumbersome.  

One question - how do you recommend we manually create our application services?  When you filter by entering "Application Service" and then click NEW, you are directed to enter an end point first.  This doesn't seem to make sense for the module related Application Services, only for the host.  How would you populate this and move forward through creating the Application Service?  Should we ignore this OOB functionality and create our own module that points to a different form?  If so, what fields do you consider essential for the application service?

[scott_lemm]

Hey Mel,

First, thank you for posting these questions in the Community so others can gain value from your insights!

Yes, there could be lots of Application Services created when we begin thinking of modules per environment. We are working on how to make this easier through process and workflows. Stay tuned as we develop a solution to help reduce the manual monotony.

As for the form view of Application Service, at this time, that form is focused on Service Mapping. Until we add a new view in Orlando, you will want to create a view that is more Operational and considers the following:

• NOTE: you may still need to populate an Entry Point. There is a current rule that requires an entry point populated in order to make the Operational Status = Operational. I believe a fix is in the works on that. 

Hope this helped!

[khadija3]

Thank you for the explanation, so our servicenow instances (DEV, UAT, PROD) are application services in your CMDB ?