Application Service to represent the 'System'

[RichardHeap]

Keen to hear from people/organisations who have used the application service to reflect the system, what worked well, what would you do differently if you were to do it again.

[Mathew Hillyard]

Hi @RichardHeap

I would start with this excellent article on the different types of Application Service, what they do, how they work, and importantly how they are populated: https://www.servicenow.com/community/common-service-data-model/application-services-how-to-use-them/... - it also contains a link to some tips and tricls

App Services break down into three basic classifications:

• Manual - Mapped Application Services [cmdb_ci_service_discovered] require manual population and updating when you have ServiceNow Discovery but not Service Mapping.
  • I wouldn't recommend using this type of App Service if you don't have Service Mapping as they require the user to click the "Update with changes from CMDB" link on the form to recalculate the service map, which is inefficient and error-prone.
  • This is the default App Service type to use if you are implementing Service Mapping.
• Dynamic
  • Calculated Application Services [cmdb_ci_service_calculated] - the App Service map is automatically populated based on the Levels parameter, but it requires you to relate at least one CI to the App Service manually.
  • Tag Based Application Services [cmdb_ci_service_by_tags] are App Service types that automatically populate the service based on key-value pairs. Often used in cloud environments. Requires Service Mapping
• Query - Dynamic CI Group [cmdb_ci_query_based_service] - primarily for grouping related CIs based on CMDB Query Builder queries, table queries, or via manual selection
  • The typical use case is for Technical Service Offerings that support a particular set of infrastructure CIs in a given location based on foundational attributes of the CI (e.g. "Texas Windows Server 2022 Servers").
  • This also supports patch management as it enables easy selection of CIs in a patching Change Request.
  • You can also define a regular application service where you have no Discovery tools set up and have a static, perhaps manually-imported CMDB.

However, before you start any of the practical work it's worth understanding how you are going to work out what the Application Services will be in the first place. I would highly recommend understanding the CSDM and in particular conducting some discovery sessions to build out a basic inventory of Business Applications, starting with your organization's key platforms (e.g ServiceNow!) as this will give you the source data for defining Application Services - each Business App will be linked to one or more Application Services, representing each environment (Dev/Test/Prod) or possibly location in very large organizations.

Building out Application Services manually using Discovery is in my experience a very time consuming and complicated exercise, and quite prone to error - plus the ongoing maintenance is considerable. This is where you will need to lean on your organization's configuration management practice considerably. 

It is a lot easier to employ Service Mapping for this as it uses top-down Discovery from the Entry Point (normally a URL) and will build the map for you, which you can then validate. You can also set boundaries for the Application Service so you get an accurate map of what is and is not a genuine part of the Application Service. The trade-off is that you need  the applicative credentials on top of the basic Discovery credentials to access both app to app and hardware to hardware relationships - so applications, databases, storage etc. This will inevitably need buy-in from configuration management, infrastructure and application support and particularly security - but the same applies for regular bottom-up Discovery anyway.

Service Mapping simplifies Application Service map buildout by using applicative Patterns for pretty much all recognised technology stacks.

Another option is Service Graph Connectors, which automate 3rd party CI Discovery but in some cases (e.g. Dynatrace) can build out the Application Service automatically.

My takeaways are:

1. Build out a team across IT, the business (because many app services will underpin critical services) and security to build out a basic Business Application inventory and define your Application buildout strategy (the people and process).
2. Frame this work as part of a wider planned CSDM program - you need the Foundation domain/phase for Dynamic CI Groups and the CMDB generally, and the Crawl maturity phase involves building out Application Services.
3. Assess the platform subscriptions and features - Discovery, Service Mapping and Service Graph Connectors - and select which options will suit your organization, and understand the pros and cons of each application service type and plan accordingly (the technology)
4. For Dynamic CI Groups and other technical underpinning services, it is useful to sketch out a basic Technical Service Portfolio to understand the support model, and therefore the likely types and volumes of DCGs required.

Hope this helps!