Summary
Question
>Validate that relevant indicators are contributing to status calculation. For instance, there could be redundant KPIs which are not needed in order to reflect application or service status. For example, if an application owner is interested in his application’s availability only, the performance data presented OOTB is not needed, and may add redundant clutter.
The same applies for Health Indicators (HIs).
>Verify that the Service Health rules being used reflect your business logic and need. Service Health OOTB rules aim at a common use case; however you may need to apply a different logic. For example, in a High Availability architecture application, the OOTB Availability KPI is calculated using the Worst Status Rule. However, from the perspective of the application owner and your organization, it may be perfectly acceptable if one of the application interfaces is down, as long as the application is available via other interfaces. In such a case, you would replace the OOTB rule for this KPI with the Best Status Rule.
>Confirm that only relevant CIs are participating in the view. Consider using pattern-based or perspective-based views in order to filter out irrelevant CIs and unneeded content.