APM Implementation – Frequently Asked Questions

Implementation guidance from ServiceNow

Purpose:
The purpose of this document is to answer most commonly asked questions when configuring APM
application in ServiceNow. The questions and the answers are focused on the use case of setting up an
application inventory, and do not address other topics such as application assessments.

The following is the list of questions answered in this document.

1. What data should we capture for business applications?

2. We are already using the application class in ServiceNow to manage our applications. What
is the difference between the ‘application’ class and ‘business application’ class?
3. What is a business service? We thought applications are business services, is there a
difference? How are Business Services and Applications related?
4. What data should we track as business applications, and what data should be tracked as
business services?
5. How do we associate Business Applications to other entities such as business process,
business capabilities, and underlying technologies? What relationship types should we use?
6. How do we associate a single application that is running different versions at different
regions? In Jakarta, there is a one-to-one relationship between business application and
software model. Do we need a Business Application record for each version?
7. What should be linked to ITSM records like incidents and changes? Business Application
record, business service or both?
8. If SAM and Service Mapping are not being used, what is the best way to create relationships
between Business Applications and underlying technology components (these could be
infrastructure or application related components).
9. How do other organizations ensure that application data stays current, and is validated by
relevant stakeholders?
1. What data should we capture for business applications?

Two types of data are used to understand the context of Business Applications.
• First, there are different attributes (think of these, as ‘demographic attributes’) about
the application which help in categorizing the application.
• Second, relating the application with other entities (think of other CIs in ServiceNow
platform) in the enterprise.
In this question, we will cover the first type of data – application categorization attributes. A
different question will address the business applications’ relationship to other CIs.

There are several stakeholders for business application data, and thinking in terms of their
questions and needs helps us define the data attributes. Below is a sample of stakeholders and
the data elements of interest to them:

Stakeholder Data attribute

Enterprise Standards
Architects Lifecycle stage and dates
Application Category
Application Type – COTS, Homegrown, SaaS
Application Family / Group –e.g., Peoplesoft, SAP, ServiceNow
Application and Business lead
Business Owners Business executive owner
IT executive owner
IT platform
Usage - # of users, regions and BUs
IT and Business Business capability / service supported
leaders Business Function / Unit
Alignment to Enterprise strategy
Cost of application support
Investments planned by application
Security SOX Classification
Compliance Data Classification
Business Criticality
Last review date
IT Operations Disaster Recovery tier
IT Platform
IT Support status – internal, vendor etc
IT support group (assignment group)

2. We are already using the application class in ServiceNow to store our applications. What is
the difference between the ‘application’ class and ‘business application’ class?
This is common at most of our customers. Until we introduced APM, all applications were
stored in the applications table (cmdb_ci_appl). This table consists of all applications – business
applications as well as desktop applications. Typically, only a portion (about 10% or so) of these
are ‘business applications’ that would fall into the purview of APM. The rest of the applications
 are more useful for processes such as Software Asset Management. Our recommendation is to
move the business application portion of this table into the business application table.

3. What is a business service? We thought applications are business services, is there a

difference?

Well, yes and no. Before APM product was introduced, most ServiceNow customers created
applications as ‘Business Service’ class. This worked for the most part as business service CIs
were used in other ServiceNow applications such as ITSM and ServiceMapping. For most part,
this scenario served the operational use cases. There was no out of box functionality to support
analysis and decision-making that is needed to make investment decisions such as retire
applications, invest in enhancements, upgrade underlying technology.

With APM, we introduced a new class of CI called business application. APM functionality such
as categorization, assessments is built around this table. The recommended approach now is to
create business applications using this table.

Business service table will instead be used to identify application instances, and will be related
to the business application. Some use cases for business services are: applications in different
environments such as Prod, QA, and Dev, or applications installed in different regions such as
EMEA, North America. Business services or Application instances are then mapped to technical
components such as software model, technologies.

Figure: Business Application and Business Service / Application Instance

Note: Within ServiceNow platform business services can be used in two ways: one, as ‘technical
entities’ such as applications and two, as true services provided by IT such as Email, Recruiting
etc. For the purpose of this answer, we are assuming the first type of usage, meaning business
service is analogous to application instance.

4. What data should we track at business application level, and what data should be tracked at
business service level?

The exact data for business application and business service will vary based on an organization’s
needs. As a general rule of thumb, the business service or application instance could have
different ownership and technical attributes. For example, a different team might support
different application instances. But for business applications will have attributes that are
applicable to all application instances such as business function supported, business capabilities
provided, business criticality. It a safe bet to assume all attributes at the business application
level, and look for exceptions to change them at application instance level.
 5. How do we associate Business Applications to other entities such as business process,
business capabilities, and underlying technologies? What type of relationship should we use
as part of configuration?

Applications are related to the following types of items in ServiceNow platform.

• Business Capability: APM prescribes the use of the Provided By CI relationship. When
on a Capability, this relationship is “suggested” and the list of applications is provided by
default when editing these relationships.
• Business Service: Application consumes Business Service (instance) (CI relationship). At
a minimum, each business application CI
• Software Model: Applications are not directly related to Software Models. Software
Models are related to Business Service CIs, which are related to Business Applications.
This relationship is defined using a many-to-many table called Business Service Product
Model (only available in Kingston and beyond).

Figure: Business Application Relationships to other entities in ServiceNow Platform

6. How do we associate a single application that is running different versions at different

regions? In Jakarta, there is a one-to-one relationship between business application and
software model. Do we need a Business Application record for each version?
Here are the most common scenarios and how to handle them:
• An application on the same version is used across the enterprise – create one business
service that corresponds to the business application
• Different versions of the same application are used in different parts of the enterprise
(regions, BUs, etc) – business service record should have similar fields to application records
to show usage.
o This is where we would use the Application Instance / Business Service to represent
each deployment. A different application isn’t needed for each installation. Each
 instance / business service represents a deployment that is usually scoped for some
use.

• Track ‘components’ of applications – this could different modules or pieces of code that
make up the business application. Track infrastructure and other software used by
applications.
o These components (code packages or functionality associated with applications)
should be created as software product models. Discovery creates cmdb_ci_appl
records, not software product models. Software product model records are not CIs
(hence they don’t show up in related lists), rather these are normalized list of
product models, which are created using SAM. If SAM is not installed, we need a
different way to create software model records
o Linking business applications to software models should be done through business
service using Business Service Product Model table, which is a standard table in
Kingston. For Jakarta, we can apply an update set to create these tables. The
linkage between Business Application and Software Model is also removed in
Kingston.

7. What should be linked to ITSM records like incidents and changes? Business Application
record or business service?
• Business Applications are CI’s, therefore any related Change Management or Incident
records can be leveraged to tally up these operational metrics. This is how the
Application Indicators work OOTB now.
• Business Service is also a default field on incident records, which might be a better
option because business services (application instances) are more granular and better
suited for recording and resolving incidents.

8. If SAM and Service Mapping are not being used, what is the best way to create relationships
between Business Applications and underlying technology components (these could be
infrastructure or application related components).
Data import or by going through the UI is really the only method. We will need to create a data
import template. Import templates should address the following data:
• List of business applications and their attributes
• List of business capabilities, if used.
• List of software models (if SAM is not installed)
• Relationship between business application and business service
• Relationship between business application and business capability
• Relationship business service and software model

9. How do other organizations ensure that application data stays current, and is validated by
relevant stakeholders?
There are two out of the box capabilities that address data maintenance process.
1. Data certification: Data certification is an out of the box plugin that is pre-configured for
APM as of Kingston release. This plug-in can be used to create periodic (e.g., quarterly)
tasks for application owners or other stakeholders to review and certify the accuracy of data
on business application record.
2. Service catalog request item: While Data Certification is useful for periodic reviews, creating
a service catalog item will help with ad hoc changes to application portfolio – e.g., adding
new applications, changing application data or removing applications from the portfolio.
Service catalog item can be used to trigger workflows, notifications, and approvals based on
specific criteria such as data ownership. For example, if business criticality of an application
is being updated, business continuity team might get notified for approval.