Why not incidents on Business Application 'level'?

[Toby2]

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

[mcconnellsj]

A Business Application is a design tool and mainly for Enterprise Architects who map capabilities to it.  A Business Application could have no relationship to anything when in the design phase.

Best to start with the Application Services.  Their creation is daunting particularly around the CIs it is made up of, and I can understand the temptation of using something simpler.

[CasperJT · Accepted solution]

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

[Richard Nelson1]

Hi Toby,

At your organisations maturity state the implications may not be noticed as first and theortically you could proceed to raise incidents at the Business Application class level.

However I would not advise it as the real benifits will not be realised and the chances are you will need to reorganise at a future point.

If you think of the Business Application as the overarching parent of the environmental Application service records (or instances) such as 'Production/UAT/Development' then typically this knowledge is important to the service desk as it can change the priority of an incient response.

i.e. a number of incidents on the UAT enviroment of application may just be an inconvenience and temporary setback for a project team however a stream of incidents on the Production instance of the same application may be much more be serious.

Thus using the Application Service classes as suggested in CSDM will allow greater insight and make your next stage of maturity easier to achieve. 

Ensure that for each Business Application you have at least one related Application Instance (Production) or more if required. 

Then overall service reporting can be agregated at the Business Application level and it will allow the 'Design and Planning' processes to use that data at Application Portfolio level.

Doing this early will save a lot of trouble in the long run.

Hope this helps

Regards

Richard

[johnhardesty_wo]

Tobias,

If you remove ServiceNow or any ticket system from the picture, the User is reporting a fault with an IT Service that they are using.

The user would be expected to know - infer - the Service that is being impacted.

So if we look at ITIL - IT Service Management Better Practice; the Service is what is delivered to the customer - internal or external - and who pays for the service whilst the user uses it - hence the name - user -VBEG.

So if we look at a ticket system - the user should be able to say - the service - Mail or Chat - is NOT working as it should.

So the ticket system - ServiceNow - should have a Service Offering / Business Service for Mail Service. the Service Offering / Business Service would not say what application - MS Exchange, Google gMail, Yahoo, AoL, Lotus Notes - is used to provide that service - directly. 

The CSDM Model provides the guidance on the Mapping from the non techno-babble to the techno babble.

So the Mail Service offering / Business Service would eventually link to the MS Exchange Application Server which would have linked to IP Networks / IP Addresses.

This way if there are a lot of Incidents on Mail; the customer can be told that - regardless of whether the Mail service is delivered by LN, MS X etc, If there are multiple providers that deliver Mail to the customer, the Service Mapping will be able to highlight that