Business Application without Application Services - filtering out Retired

[Oneimus]

We are well on our way in our journey of the Crawl Phase. However we I need to understand how to filter out "Retired" Business Applications from needing to have an Application Services created or recognized by the CSDM Data Foundational Dashboard's  "Business Application without Application Services" Performance Analytic.

[Carolyn Rast]

@Oneimus I learned a critical lesson about CMDB - CMDB should NOT have non-operational CIs in it.

Once a CI is retired - it should be moved out of the CMDB to the Archive.  

Do you have a Business case for not moving it to the archive?

As you have noted ServiceNow logic assumes only operational CIs are in the CMDB.

[Oneimus]

Tech Debt!!!!!   The problem is that you cannot fully automate even the archival of data because it is shown to be process intensive. In addition to regulations, auditing controls, etc, etc... We have to leave or show the "Retired" Business Applications and Application Services. We are trying to make sure no one retires a Business App and App Service before they have fully and operationally gone through the process to "Retire" the CIs correctly so the relationships don't get recreated. 

[SNFan]

Is it too crazy to suggest creating minimal App Service records for your retired biz apps? 1 App Service per biz app and put it in retired state? 

[Pat Espin]

I'm not sure if this is what you are looking for but the indicator in question is called "Business Application Missing Application Service Relationship" and the indicator source is called "BizApp.Missing.AppServiceRelation".  Looks like you'd need to update the indicator source to eliminate the retired app services.  Note: this is not in the Global application, it is in the CMDB and CSDM Data Foundations application.

[Marshall Parker]

I have had to dive into these foundational dashboards for a couple of use cases .. although changing away from OOB is not always the best method, sometimes there is a business case to adjust these tools.

These dashboards are populated with metrics collected by the 2 scheduled jobs:

• CSDM Get Well Metric Collection
• CMDB Get Well Metric Collection 

Reviewing these you can dig into how / where the code is built .. I have had to dive deep into some of the calculation scripts to fully understand what is being checked for each metric to explain different scenarios as we work to improve our best practice adherence. Some options I have considered or used:

1 - Explain why certain metrics are not 100%, and the rationale for why that is accepted on my current instance

2 - Identify a metric that is no longer relevant and disabling the metric from being calculated [comment out the metric calculation in the scheduled job & turning off the active flag on the control table sn_getwell_metric]

3 - Modifying the OOB code to change what is in scope [just a theory so far .. have not identified a use case that was worth actually modifying the default code]