Business Criticality on Business Application vs Business Criticality of Application Service

[Caleb Cordes]

I need a sanity check here. The choices for the Business Criticality field on Business Application do not match the choices on Application Service (inherited from cmdb_ci_service).

I have always thought this was a disappointing and annoying user experience for anyone trying to use the CSDM and APM. My plan on fixing this aims to update the UX, while not impacting OOTB functionality. 

1. Align the number of choices, by adding "Critical" choice to the cmdb_ci_business_app.business_criticality field. Update the sequences of all choices to place "Critical" above "High."
2. Algin the LABELS by updating the labels (values are not touched) for cmdb_ci_service.business_criticality (dictionary for Application Service's "Business Criticality" field) field to match the labels on cmdb_ci_business_app.business_criticality. 

My question for the APM community:  The only thing I’m adding that the system won’t be accounting for is the “Critical” choice on the Business Applications "Business Criticality" field in step 1. I believe this new choice would only impact APM (please correct me if I'm wrong). Has anyone done this before and can share some feedback or lessons learned?

[Cheshire Cat]

I wouldn't personally make this change, but I understand the concern about the mismatch between Business Application and Application Service business criticality. Business criticality is relevant in four areas: Business Applications, Application Services, Technical Service Offering, and Business Service Offerings. While all Service types provide the same options (Application, Technical, Business), they differ for Business Applications.

The alignment of Application Service & Service Offering values likely stems from their placement in the operations side of the Common Service Data Model, whereas Business Applications belong to the development side. These two sides have different use cases and don't need to be synchronized.

When designing an application, consider the fit-for-purpose and fit-for-use criteria, including security, reliability, and maintainability. This defines the business criticality of the Business Application, which is environment and logical stack agnostic. For Application Services, the business criticality should align with the Service Level/Operating Level/Experience Level Agreements on expected uptime and availability etc for a specific logical stack which could be based on environment, location, or other differentiators.  The Application Services have a depends/depends on relationship with Service Offerings and therefore it makes sense for these three areas to match.

If anyone has additional context, can confirm, correct, or expand on this, it would be appreciated. I'm always eager to learn more about this data model and how to leverage it effectively!

[Mathew Hillyard]

Hi @Caleb Cordes 

There could possibly be a case for the production instance (Application Service) of a Business Application having the same business criticality as it's Business Application, but it's less likely any of the other Application Services have the same level of criticality given they're not used for production. In addition, an Application Service's criticality could depend on whether it supports any other Application Services - although it's recommended to use Digital Integration Management to define data interfaces and APIs at the Business App level instead of large numbers of parent-child Application Services.

As @Cheshire Cat mentions, the criticality to your business of a particular design object (Business App) may be treated differently for reporting purposes to the operational criticality of a stack of technology (App Service) that underpins one or more Service Offerings.

I hope this helps!

Mat