Application Services: How to use them?

[David Skowronek]

Application Services are essential part of the Common Service Data Model (CSDM). This article focuses on how to use Application Services for manually maintained Service Maps in the situation when Service Mapping is not deployed. Proper usage of Application Services is critical for correct behavior of some features, e.g.:

• Impacted Services (e.g. in the Change Management)
• Event Management (service impact, priority calculation, Operator Workspace etc.)

It is highly important to understand how Application Services are working: they DO NOT USE RELATIONSHIPS, they are WORKING WITH CI ASSOCIATIONS.

What is a CI Association?

ServiceNow Documentation says: "The Service Configuration Item Association table [svc_ci_assoc] binds an application service and a CI to track which CIs are part of each application service."

In practice, it is flattened table that contains "relationships" among Configuration Items and Application Services. I am having word relationships in quotation marks because CI Associations are separate data model that can be different from the relationships. And in this situation, when relationships and CI Associations are different, unexpected situations resulting in "Why my Service is not listed among Impacted Service when I have relationships in place?" may happen.

It is highly critical to have CI Associations populated correctly and in sync with Relationships. For performance reasons, traversing through all Relationships in the Impact analysis etc. is not possible. Therefore, Service Configuration Item Association [svc_ci_assoc] table is used for fast search.

How to make sure that Service Configuration Item Associations are populated?

This chapter will focus to 2 Application Service types:

• Mapped Application Service [cmdb_ci_service_discovered]
• Calculated Application Service [cmdb_ci_service_calculated]

There are 3 more Application Service types available:

• Application Service [cmdb_ci_service_auto] where no CI Associations are created at all
• Dynamic CI Group [cmdb_ci_query_based_service] where CI Associations are automatically created based on the specified CMDB Group
• Tag Based Application Service [cmdb_ci_service_by_tags] where CI Associations are automatically created based on Tags

You may check my previous Community Article CSDM 3.0: Paris release CMDB changes where they are visualised.

Mapped Application Service

This Application Service type may be created and maintained by:

• Service Mapping, and in this case you do not need to take care about the CI Associations as they are created automatically
• Manually, where you need to build Service Map and CI Associations manually

The following picture shows a new Application Service being created with Manual population method. You can add multiple Configuration Items into the manual map however: only directly added configuration items will create CI Associations.

If the added Configuration Item, DEMO Server on the example used, have some child relationships, they are ignored and CI Associations are not created for them. It means, Impacted Services etc. will work for directly listed Configuration Items but not for their children.

Once the Mapped Application Service is created, you may need to populate remaining Configuration Items manually, based on the existing relationships. Open the Mapped Application Service in the form view (the most easy is to type cmdb_ci_service_discovered.list in the filter navigator) and use "Update with changes from CMDB" UI Action (highlighted on the screenshot below). There is a need to use this UI Action after every change in the relationships, to ensure Service Map and CI Associations are in sync with CMDB relationships.

This approach is manual, with risk that CI Associations are not in sync with CMDB relationships, as people simply forget to click this UI Action. If you want to have the synchronization automated, you may need to use Calculated Application Service.

Calculated Application Service

A Calculated Application Service [cmdb_ci_service_calculated] is a type of the Application Service that is populated automatically based on the CMDB relationships. Changes in the CMDB relationships are detected automatically and Service Map together with CI Associations are adjusted automatically (through a scheduled job). You may control what Configuration Item classes are imported, for details please check my Community Article Application Services: Tips and Tricks.

Creation of the Calculated Application Service not straight-forward in the Quebec release, there is a need to:

• Create a Mapped Application Service
• Open the service form and use "Convert to Dynamic Service" UI Action

Once this UI Action is clicked, Mapped Application Service is re-classified as Calculated Application Service with few additional parameters populated.

Attribute "Levels" is highly important in here. This number says how many levels of CI Relationships is imported to the Application Service. Default value (set by the "svc.manual.convert.levels.default_value" property) is 3.

Attribute "Levels" is in practise attribute with element name "metadata" that needs to be populated with a JSON String: {"levels" : <number>}.

Summary

The following table explains different types of Application Services and how Service Configuration Item Associations are populated.

Using Mapped Application Service [cmdb_ci_service_discovered] is not recommended for manually maintained maps. There is a significant risk of incorrect Service Configuration Item Associations. Use Calculated Application Service instead.

Table below shows limits for some Application Service types however it is NOT recommended to add more than 1000 Configuration Items into a single Application Service.

Application Service type	CI Associations population	Note
Application Service [cmdb_ci_service_auto]	Not populated
Mapped Application Service [cmdb_ci_service_discovered]	Automatically when Service Mapping is used Manually using "Update with changes from CMDB" UI Action
Calculated Application Service [cmdb_ci_service_calculated]	Automatically based on the existing Relationships
Dynamic CI Group [cmdb_ci_query_based_service]	Automatically based on the CMDB Group	This Application Service type supports max. 10 000 Configuration items
Tag Based Application Service [cmdb_ci_service_by_tags]	Automatically based on the Tags	This Application Service type supports max. 5 000 Configuration items

Check my next Community Article Application Services: Tips and Tricks for useful tips on how to influence behavior of Application Services.

[snowdev8]

@David Skowronek in addition to the challenges I listed above , the other challenge of having one Cat Item with dropdown is that it cannot be used on an order guide where the answer to the questions will determine which Application Access requests can be requested

[mikesisson]

I get the need to keep the numbers to something manageable, however, what matters is if you are offering something to a consumer (Business or Technical).  So if someone needs access to something, likely they are attempting to consume something.  What is the purpose of that App Service?, who or what is it serving.  So as you think through the need for the offering, you could in effect come the opposite side of the CSDM to help you with your answer.  So rather than coming from the Biz App to the App Service to the Svc Offering, go from the Biz App to the Capability to the Business Service to the offering.... Then.... ask, what app service do I depend on to deliver this offering.  This works for the Business Service side of things.  

We are finding that coming from the App Service side of things to the Business Service Offerings could sway the conversation to the tech side, when you really want a Business line weighted answer at the Service Offering, which leads down a path with the business consumer in the room, holding you uncomfortably, but necessarily accountable... 😉

[David Skowronek]

Hello,

this is a very wide discussion that cannot be solved in this way. I would suggest you to use the ServiceNow Impact and trigger an Advisory session, to get the best recommendation on how to setup the Service Catalog for you and your data model.

Personally, I see loose coupling between Catalog Items and Service Offerings. I prefer to have less Catalog Items that use data all data in ServiceNow as inputs. If you see the drop-down (reference) to 150 App Services as too large, you may have multi-step selection approach, based on some groupping element (e.g. taxonomy as the first layer). Or you have may have multiple Catalog Items for access management, one e.g. for on-premise software, another for Microsoft apps etc.

To your question about a need to create Application Access Management Service Offerings ... my answer is why? Application access is in-scope item of the service (offering), what would be the purpose of such a granular service modelling? Do the minimum you need. Do not create additional objects if you really do not need them.

I can easily imagine Catalog Item with the following hierarchy of data:

- use selects from the Service Portfolio the taxonomy node (filtered only for those where access is relevant)
- based on the selected taxonomy, you display the relevant Application Services (you can use prescribed relationships and references in CSDM for filtering)

If your required ticket requires a Service Offering, it can auto-selected based on the Application Service (if it has only 1 as a parent), it can be selected by end user, by service desk agent ... depends on the data and support models you have.

This is why there is no generic answer ... everything depends on your data and support model, including process designs.

As I wrote, using ServiceNow Impact and Advisory Sessions would the best way to get advice based on your situation.

[snowdev8]

@David Skowronek thank you for your input .
Catalog Items are tied to Service Offerings under the Items orderablle by Subscribers relationship.
I agree that this is loosely coupled, but the advantage I see is the ability to do service level reporting. 

This is the same advantage of having separate Catalog Items because you wouldn't need to run a report on RITM  variables to figure out which ones were for Application A vs B, and , it would be easy enough to incorporate into order guides. 

To me, it looks like the Fulfilment Group will have to be the temporary solution.
For example, if the organization has both Miro and LucidChart, and, the Fulfilment Group that works to provide Miro  access might be different from LucidChart. And that cannot be tied to the Service Offering for this reason.
It will have to be a manual activity where the Service Owner and Service Catalog manager collaborate and maintain the Fulfilment Group on the Catalog Item . 

And agreed with not needing an SO for each type of Application Access . The reason why I asked this is again to have an option of using the Support Group of the SO as the fulfilment group of the Catalog Item.

Ty for your suggestion on Impact and Advisory . We will take this into consideration

[snowdev8]

@mikesisson That is a very valid take! The challenge lies in the fact that many organizations, especially those new to SN, are used to referring to services by their product names. For instance, they might refer to "Active Directory Access" as a service, rather than viewing it as part of a broader Service Offering, such as the ability to access Sales reports, which requires an AD group access. While meta tags can be added, organizations often want to see these specific product names directly on the Catalog Item. This shift to service names, as opposed to application names, seems to require significant change management efforts.

Furthermore, ServiceNow suggests that discussions around Business Applications are most effective when the organization is prepared to have those strategic, value-driven conversations. Without that, software models might end up being recorded as Business Apps, which could lead to confusion.

Thoughts on a middle ground for creating a scalable approach to intake App Access requests for around 150 applications? The goal is be balance the immediate need to get something stood up , at the same time, being strategic to continue CSDM approach.

[poyntzj]

Hi @David Skowronek 

I have just heard in a meeting that we have encountered the 10,000 limit in svc_ci_assoc.  Global company with complex systems that are global, realtime and used by hundreds of thousands of customers at any one time, 24x7.

Is there a way around this ? I did throw a comment in that the figure sounds like the usual GlideRecord limit, but they said they looked at this - and ideally we would prefer not to increase that limit (other have suggested in the past to reduce it)

[David Skowronek]

Hi, @poyntzj . The limit of 10000 is per Application Service. As an Application Service is defined as an deployed application stacking, having an application with more than 10000 components is very, very rare. The number of customers / users consuming this application is not relevant, as this should be handled differently and not by configuration items. 

You should assess your Application Service whether it is really a single application stack, instead of "catch all" type of service. And you may model it as nested Application Services.