Where do we get the Application Service in an Incident form?

[EricDevismes]

Hi there!

I'm working for a large customer introducing the concepts of Application Services as part of its adoption of the CSDM framework.

The general modelization principles are the following:

• Business Service: Very often, it is an Application name as the business knows it. 1 BS per App.
• Service Offering: There is often 1 SO for PROD, and 1 SO for NON-PROD because commitments are different
• Application service: There are as many AS as there are environments for the Application

My question relates to the Incident where we have 3 fields to identify the impacted component:

• Service
• Service Offering
• Configuration item

Per CSDM there can only be Service Offerings for Business Services and Technical Services, NOT for Application services.

In my customer Incident form:

• the Business Service and Service Offering are mandatory fields
• the Service offering is derived from the Business service (default PROD, can be changed to Non-PROD)
• the CI can be anything.

As a result, the Application Service cannot be logged in the Business service field, because there is no Service offering for Application service. That only leaves the Configuration Item to store the Application Service.

My questions

1. Could you confirm my understanding that Application service should only be found in the CI field (or affected CIs) of an incident

2. In case of alert related incident, would you also expect the Application service to be in the Configuration Item field?

1. If yes, would you set up some rules to discover the parent Business Service and Service Offering (mandatory)
2. If yes, then I'd almost fell that we are missing a field, as having the Application service at the lowest level (CI) that doesn't leave a field to identify the underlying component (server, DB) as actual CI impacted.

I hope my question is not confusing.

Happy to have a chat with anyone of you who had similar use case to manage.

Cheers!

[Florian Spisla]

Just a quick reply on how we handle it... On the incident form, we only have two fields instead of three:

Service and CI, where as only CI is mandatory. The Servicedesk (1st Level) should fill in CI to the best of their knowledge, which often means, they will use the Application Service here. A user will call them and tell them, that our ERP is not working, so they put that in the CI field. 2nd or 3rd Level should now change the CI field to the correct one (Application, Server, DB, etc...) as they are the experts.

[Barry Kant]

Good day Eric,

My questions

1. Could you confirm my understanding that Application service should only be found in the CI field (or affected CIs) of an incident

Yes, that is correct, as in the CSDM model it is a downstream relation from the Business Service Offering. This is actually the realization of a Business Application (eg:

For company ACME

Business Application:

• ServiceNow

Application Services:

• ServiceNow - DEV  --> Business Service Offering: ACMENow - PROD
• ServiceNow - TEST  --> Business Service Offering: ACMENow - nonPROD
• ServiceNow - ACC  --> Business Service Offering: ACMENow - nonPROD
• ServiceNow - PROD  --> Business Service Offering: ACMENow - nonPROD

rather than default PROD and can change to nonPROD you could manage this with Subscriptions. 

2. In case of alert related incident, would you also expect the Application service to be in the Configuration Item field?

1. If yes, would you set up some rules to discover the parent Business Service and Service Offering (mandatory) - Yes I would limit the CIs based on the downstream relations from the offering field. 
2. If yes, then I'd almost fell that we are missing a field, as having the Application service at the lowest level (CI) that doesn't leave a field to identify the underlying component (server, DB) as actual CI impacted. - From an intake point of view in incident mgmt it is in most cases the known level by end users (in case of applications). While in troubleshooting mode the incident agent might indicate it is a downstream infrastructure CI and can change the field. In case it is not an Application it can be an Owned device, still the product level known by the end user is the 'application service' level. (maybe more a digital product). If the incident is initiated via 2nd line, supplies or event mgmt, than the CI is probably on a downstream CI level (infra). The build-in Impact Analysis can lookup the relations to list the impacted Services. 

Cheers,

Barry

[Stig Brandt]

Hi Eric, 

The understanding is correct: affected CI or Configuration Item on any of the forms, should contain Application - Service or and CI Component, that is the cause of the incident, the CI here is filter from Service / Service Offering.

Your challenge is, as I have tried to address a number of times and really not seen in CSDM is, that you normally have two - service offerings - that you need to capture

• Technical service offering (supporting service)
• Business Service offering (end user service)

Ex. end user is raising a ticket on Outlook is not working, you have Outlook as a

• business service offering for the end users - drives SLA and commitment to the end user
• you have an application service 
• you have technical service offering for outlook - drives SLA and commitments from the support

2. From the alert you are putting the affected CI - not the application service, it is the offering(impacted service, automatically identified by predictive intelligence) that is important here, to identify the impacted users.

Best regards

Stig

[EricDevismes]

Thanks all, that makes sense, and relieves me that we are on the right tracks.

@Stig Brandt your comment makes me reconsider that it's actually the impacted CI found in the alert that should be in the Configuration item field of the Incident

If the Application service needs to be logged somewhere, it can very well be as impacted service.

And the most important indeed is to infer (automatically or by an agent) the Offering and the business/technical service.

To your point that we should actually have:

- 1 TS SO for internal commitment

- 1 BS SO for business commitment

I never thought of it that way, but that quite true.

I believe many customer may be end up to be tempted to create 2 incidents like parent child, which is not great.

Cheers!