APM Indicators for Incident, Problem and Change: Business Application Breakdown

[Mathew Hillyard]

I have an issue with setting up APM Indicators and collecting data around ITSM records. The APM Indicators related to Incident, Problem and Change (IPC) collect data from existing PA Indicators, for example, 

Application Portfolio Management > Application Indicators > Number of Incidents

The Indicator is Number of New Incidents, an existing PA Indicator. When activating APM, a new Breakdown is added to this, based on Business Application (an APM table). So for Incident, for example, the Facts table is incident and the field is cmdb_ci_business_app.

However, This field is neither on any of the IPC forms OOTB, nor does any functionality in the platform appear to populate the Business application field on an IPC record. This means that the Application 360 > Workload tab will display no results. 

The APM Implementation NowLearning course states in the section on APM and ITSM integration (I quote)

"In order for base system indicators to work, you should use the application service records when making these associations, NOT the business application records".

I have tried this in a PDI - OOTB nothing on an IPC record will populate the Business application field and the PA collection jobs return no results. If I add the field to the form and enter a Business application manually, then run the PA collection jobs, scores are calculated 

I can also find no information about this specific issue within NowLearning, the Community, Developer, Docs or any of the relevant YouTube videos. Am I missing something vital here?

[Mathew Hillyard]

Thank you Doron.

Addressing the other comments above - in the interim, we can consider different approaches to addressing what happens on Incidents, Problems, and Change Requests, but do keep in mind for it to "count" with APM the end result must populate the Business Application field on the relevant record, as this is what is used (specifically the Business Application breakdown in the relevant Indicator - Incidents.New, Problems.New, Changes.New.)

It is an interesting challenge considering how Business Applications fit into CSDM as a whole - every Application Service should reference one and only one Business Application, so therefore a Business Application could and should be referenced by multiple Application Services. But if they're Dev/Test/QA/Prod (so environment-specific) then you should really only be considering the production service as it's likely to be the only environment relevant to generating an Application Score - which is the ultimate aim.

Then there are the underlying hardware and software CIs - a Server could in theory be running multiple application services, even though this is typically not good practice. For a given Incident or a Change with multiple impacted CIs/Services it may not be possible to tie this all back consistently to a single Business Application to satisfy the APM Indicator. I suspect the best course of action here is that we drive this off the Configuration Item Fields (or Business Service if being used and CSDM has the relationships in place) and if we discover one and only one Business Application in the chain, we populate the Business Application field and increment the relevant "<IPC Indicator>.New" Indicator.

[Doron Orbach]

Thanks a lot for the inputs!

[Adithya6]

This is helpful.

So in essence, for application indicators, ideally, we should look to map to application services but if we aren't there yet in terms of maturity, we can look to map to business applications to derive some value in the interim.

Am I getting it right?

[Mathew Hillyard]

I don't think this is an "ideal" situation, it's the only sensible solution. If you don't have CSDM service maps built linking App Services to all their related objects in CSDM, and you're not yet using this within Incident and Change operationally, then you're not ready to start using APM Indicators as there will be no data in the source table (Impacted Business Application). There is no interim solution for generating volumes of operational incidents and changes for application scoring. If you are at a less mature point then I would concentrate more on the initial maturity phase of building out a inventory of business applications with categorisation, then linking them to application services (as per CSDM "crawl" phase).

[Jon Miller1]

I'm following this thread with great interest because:

a) We're reimplementing our CMDB as we speak,

b) We're looking to revert our entire ServiceNow platform to out-of-box (prior customization has limited the value of the CMDB to Incident, Problem and Change), and

c) We're evaluating APM for implementation next year.

The thread raises a fundamental question about what is the "right" CI for population on Incident, Problem and Change. That's my first thought before considering the roll-up to the Business Application level. As @Mathew Hillyard mentioned, maybe non-prod tasks should never roll-up (though I think ITSM preaches that incidents and change only relate to the Production environment). But I can see pros and cons with the example of rolling up a server-based incident to the Business Application. An incident may have nothing to do with the application itself.

Our plan is to train folks to...

1. For an incident, create the initial incident referencing the Application Service CI. If further trouble-shooting identifies an issue with a database or server, change the CI on the incident to reflect that. The goal is that when the incident is *resolved*, it accurately reflects the CI where the incident occurred.

2. Change Requests should be created for the CI that is being changed. That may seem like it's stating the obvious but we have historically always created the CR to reflect an application, even if it's the database or server that's being changed.

Does anybody disagree with this approach? More relevant to this thread, will the above approach correctly roll-up incident/change reporting to the Business Application?

On an off- but related topic, I still have some concerns about confusion over Application Service v Application. It's probably very clear to the practitioners on this thread and anyone familiar with the CSDM. But I'm finding it hard to articulate that to end-users in IT, particularly when it comes to what an incident or change should be created for. I'm also unsure if this will get better or worse once ServiceNow build out the definition of "SDLC Component". I *think* we're using that how ServiceNow intends but it's created a situation where sometimes an "application" is one thing and sometimes it's something else. Is anybody else working through that? Any advance insight into what will be in CSDM5 in that area?