Why not incidents on Business Application 'level'?

Toby2 · ‎02-17-2021

Hi all

I'm in a fairly small organisation (in relation to ServiceNow typical customers) where we have recently rolled out incident and change. We are now looking into the CSDM 'crawl' stage regarding CMDB.

We get a lot of incidents from users through our service portal.

Our service desk/1st line is not necessarily able to determine the exact CI the incident is regarding.

We are inclined to have the user/ 1st line relate incidents to the 'business application' - even though this is not recommended in the CSDM whitepaper(s), because 'business application' isn't a "operational CI".

Can anyone elaborate on why we should NOT do this?

Thanks

/Tobias

CasperJT · ‎02-17-2021

Hi Toby,

The straight reasoning from ServiceNow can be found in the Common Service Data Model product view: Incident Management (servicenow.com) (under FAQ)

Business applications are portfolio objects used for designing and planning your enterprise architecture. Business applications don't contain attribute-level details such as version, environment, and localization (for any deployments using one or more applications).,

As I understand it. The Business Application simply doesn't have valuable information for the teams resolving incidents, since it will basically only provide the over arching name of the Application Service that they are working with.

I understand your inclination to use the Business Application to populate the Configuration Item field. However, since you could also write in the description, what business application is affected and achieve the same level of information, maybe you are better off doing that and then populating the Configuration Item, once it is clear which Application Service is affected.

Additionally your Services are not linked with the Business Application, so your structure will fail to help you with managing your incidents, when you move in to the walk/run stages.

Best regards,

Casper

View solution in original post

mcconnellsj · ‎02-17-2021

Hi John

This is what I assumed but I found this O365 example which is specific about the technology, is this also okay do you think?

I know that our users will report issues with "Outlook" rather than "mail"

johnhardesty_wo · ‎02-17-2021

Yes

I used the general example as a company may offer mail service through multiple technical services - Notes, Exchange, etc

If you use o365 AND Outlook then tuser Outlook vice mail

And the CSDM Model is good start

KN8 · ‎07-13-2021

Interestingly, there is the K21 Align Business and Drive Decision Making with Application Portfolio lab, in which there is an intro segment on CSDM.

In that (lecture 1.1.5 of the lab on Now Learning) the narrator suggests to have some 'flexibility' (as opposed to the CSDM) and indeed to permit recording incidents (and requests and other service portal-triggered objects) against Business Application CI records to ensure better visibility across the application portfolio, and convenience to the users.

Don't know if that helps.

KN8 · ‎07-14-2021

Also, the APM application seems to create a 'Business Application' reference field on the Incident form.

There is an APM indicator 'Application's Incident Count' which counts incidents with values in that field.

There is also an APM indicator 'Application's Instance- Incident Count' which looks for Services that are children to Business Applications.

It seems that the latter indicator is CSDM-aligned, while the former is not. The docs (Preconfigured indicators and their source applications | ServiceNow Docs) speak of 'application instances' instead of application services.

RussLaPlante · ‎08-12-2022

I'm ok with not using the Business Application as identifying the "What" of an INC, PRB or CHG.

But why isn't there a rule in those modules to prevent the Business App from being added in the first place? The design of these apps should follow the guidelines of the CSDM.

Thoughts?

I'm going to add this rule myself. What are you all doing about it?

Thanks, Russ