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!

[Arco Keijzer]

In itself I do not get it, following the explanation above; -> when you design something, part of it is capturing the requirements of what the customer expects to be met in the implementation.
So from that perspective it makes perfect sense to use the same labels for 'what is desired' and 'what gets implemented and is being delivered'.
Its like registering a demand for a car (on the engine power requirement) to be registered in 'horsepower', but registering it for the actual delivered cars in 'Watts'. 
In this car example, it still sort of works because you can find that 1 horsepower corresponds to roughly 740W; but using different classifications without any link in an attribute with one and the same name, still seems very much off to me..

When asked to our Impact team -> it was mentioned that the Business Criticality as defined in Business App is used in IRM (if I remember well) in the same way, so should preferably not be adjusted to correspond to the same value-set as the 'service' classes.

So it seems more a 'clash' of module integration. I can understand that; but would have preferred that this attribute in Business App would have had a different label then the ones in the service tables; it would make the different value-sets easier to handle with the system users.

[Arco Keijzer]

This explanation is useful as well:
why Business criticality drop down option differen... - ServiceNow Community

[GeoffL-Coles]

>I wouldn't personally make this change

If you have lots of applications, and even more application services, who is doing all the assesments and classifications? That is a lot of work. And it adds confusion and makes no sense to have different labels - what does high mean compared to most critical? Also people can't remember the difference 'somewhat critical' and 'less critical'. We changed it all to C1, C2, C3, C4. (but have seen C1-5, where 5 is non-prod. And seen a C0 for foundation services/apps) 

I think it makes sense to keep them the same, do business impact assessment for criticality on the business application (by the business) and the prod application service inherits business application criticality, non-prods get the lowest criticality with ability to override where needed (development environments with lots of developers/testers).