Applicaton vs. Business Application

jaguthrie · ‎03-18-2025

Looking at "How CSDM concepts map to CMDB tables" in the ServiceNow documentation. I noticed that there is Business Application (cmdb_ci_business_app) and Application (cmdb_ci_appl) that are stored in different tables. Looking at it from the CSDM perspective, what is the difference between the two? Given that there are two separate tables in the CMDB for them, what is the litmus test we should use in capturing something as an application vs a business application?

CSDM Glossary:

Application: Any deployed program, module, or group of programs that is designed to provide specific functionality on a computer infrastructure.

Business Application: Represents all software and infrastructure environments (dev, test, prod) that are configured to provide functionality.

Daniel Needles · ‎03-18-2025

ServiceNow behaves like the "Borg" from Star Trek, collecting bits and pieces of diverse tech, revamping the UI/UX experience to match ServiceNow and converting the backend module’s databases to function hierarchically (with sysids) on a relational database. These tech bits can be external but are often internal. As a result, there can be overlap and redundancy of data due to different modules dealing with the same stuff but for different purposes. That is the case here though in this case the business cases are different enough to not have much record redundancy.

* cmdb_ci_appl: Used for technical application instances—i.e., actual software installations and services running on servers or within a technology infrastructure.

* cmdb_ci_business_app: Represents business-facing applications—i.e., a named, logical “application” as recognized by business or IT stakeholders at a higher, organizational level.

Although they sound similar and can model the same apps sometimes, these two tables serve different purposes and are used in distinct contexts. In particular, Common Service Data Model (CSDM) and its best practices underscore a separation between the “business” view and the “technical” view of applications. For example,

A technical application instance might describe a running Tomcat server on a specific machine.
A business application might be “Customer Order Portal,” which the organization references for business capability and cost tracking.

Keeping these representations separate—yet related—ensures that each group of stakeholders (technical or business) has the right information and context.

The cmdb_ci_appl Table

Purpose

Technical/Infrastructure Application
Typically represents discovered or manually entered application instances (e.g., WebSphere, JBoss, Tomcat, Apache, .NET, etc.).
Tracks the “where and how” an application is actually running in a given environment.

Usage in ServiceNow

Discovery and Service Mapping

Discovery: Finds running software in your environment. The discovered data is typically stored in cmdb_ci_appl or one of its child classes.
Service Mapping: Maps infrastructure-level application components into application services; these components often anchor from cmdb_ci_appl.

ITOM Visibility

The table supports monitoring and event management capabilities by providing the “technical anchor” of an application instance.

CMDB and CI Class Manager

You can see “Applications” under the Configuration → CIs → Applications menu, or by using the CI Class Manager to browse the cmdb_ci_appl class.

Examples

A specific WebSphere instance running on server A.
A Tomcat service that hosts a custom web application.
An instance of JBoss discovered by a pattern or probe.

When to Use cmdb_ci_appl

You’re tracking actual software installations or services on servers.
Discovery or Service Mapping is populating these items with infrastructure details (ports, service names, versions, etc.).
ITOM teams primarily need these records to handle patching, monitoring, performance tracking, and operational support.

The cmdb_ci_business_app Table

Purpose

Business-Facing Application
Represents the “nameplate” or “conceptual” application recognized by the business, regardless of how many technical instances deliver it.
Focuses on attributes like business ownership, cost center, internal/external usage, compliance, etc.

Usage in ServiceNow

CSDM (Common Service Data Model)

A key entity in CSDM is the concept of a Business Application, which is ideally stored in cmdb_ci_business_app.
Helps create a distinction between the conceptual business application and the technical infrastructure that supports it.

ServiceNow ITSM and ITBM

ITSM processes like Incident, Problem, and Change may reference the business application for high-level impact assessment.
ITBM (IT Business Management) might link to these applications for portfolio management, cost allocations, and application rationalization.

Governance and Ownership

Typically, a business application has designated business owners, application owners, and users. This data is tracked as attributes in cmdb_ci_business_app.

Examples

“HR Payroll Application”: The conceptual application used by HR for payroll management.
“Sales Cloud (Salesforce)”: A well-known SaaS application used by the sales department.
“Custom Order Management System”: A specialized application for internal supply chain processes.

When to Use cmdb_ci_business_app

You need a high-level organizational representation of the application.
Business stakeholders need to track ownership, costs, usage, and other governance data.
CSDM alignment is a priority, to differentiate business applications from underlying technical components.

Key Differences and How They Work Together

Perspective

cmdb_ci_appl: Infrastructure perspective; tracks each instance of software.
cmdb_ci_business_app: Business perspective; a single record for the overarching, conceptual application.

Level of Detail

cmdb_ci_appl: Typically includes version numbers, port connections, discovered attributes, etc.
cmdb_ci_business_app: Usually includes business owner, department, cost center, usage, and other high-level attributes.

Usage in Modules

cmdb_ci_appl: ITOM modules (Discovery, Service Mapping, Event Management) heavily rely on this technical data.
cmdb_ci_business_app: ITSM/ITBM modules for Incident, Problem, Change from a business-impact viewpoint; also for Application Portfolio Management, CSDM, and more strategic initiatives.

Relationships

A single business application (in cmdb_ci_business_app) might be supported by multiple underlying technical application instances (in cmdb_ci_appl).
One “HR Payroll Application” could be delivered by multiple Tomcat servers and microservices discovered as separate records in cmdb_ci_appl.

Deep Dive: When a Customer Should Use One vs. the Other

Scenario 1: Discovering Software in Your Environment

Use cmdb_ci_appl.

Each discovered software instance populates this table (or a child class). You gain an accurate representation of your technical environment.

Scenario 2: Aligning with CSDM and Providing Business Context

Use cmdb_ci_business_app.

Create or maintain a record in cmdb_ci_business_app that corresponds to the business-facing name and ownership data. You then relate it to the discovered technical application records.

Scenario 3: Troubleshooting a Performance Incident

Both come into play, but you’ll likely reference cmdb_ci_appl for the immediate cause (a specific instance is failing or misconfigured). The business application (cmdb_ci_business_app) is relevant to stakeholders who want to understand the impact to the business, leadership, or end users.

Scenario 4: Application Portfolio Management (APM)

Primarily cmdb_ci_business_app.

APM is about rationalizing and optimizing the named applications the business invests in. The technical detail is secondary.

Scenario 5: Service Mapping

Start with cmdb_ci_appl (technical components discovered).

Then, at the top layer, reference or create a cmdb_ci_business_app if you need the conceptual representation in line with CSDM best practices.

Summary and Recommendations

Keep Business and Technical Perspectives Separate: This is the foundation of the Common Service Data Model (CSDM).
Use cmdb_ci_appl for technical software instances discovered or managed in the environment.
Use cmdb_ci_business_app to represent the business-facing view. Track ownership, costs, and usage at this level.
Relate the Two: Typically, a single cmdb_ci_business_app can have multiple cmdb_ci_appl instances that collectively deliver the application.

By understanding and using each table as intended, organizations gain end-to-end visibility: from the highest-level business function down to the individual server processes that power it. This alignment drives better governance, clearer communication across technical and business teams, and more robust incident and change management processes.

View solution in original post

Barry Kant · ‎03-19-2025

Hi Jaguthrie,

the business application is in the design domain as it is a architect object.
It is not operational (it has a life cycle, but it is not in operations). This object connects to funding, artifacts, compliance, cost, risk, and architects own this record to outline the rules for deployment.

The application service/service instance are representing a deployment of a business application or a top level logical record of a stacked IT solution. (All IT). This is operational (or RUN if you will).

If a business application needs to be build or deployed it will get a downstream related application service as a result.

BR,
Barry

Miklos Palfi · ‎03-19-2025

One of my colleague explained the difference with a metaphor:

The business application (cmdb_ci_business_app) is the design or blueprint of a house,

the application (cmdb_ci_appl) is the house (or one part of it, if needed) that has already been built.

This metaphor works quite well in many situations helping to understand which task is related with the one or the other CI.

Johannes · ‎03-19-2025

If Business Application (table cmdb_ci_business_app) is the blueprint on a house, then Application/Service Instance Service (table cmdb_ci_service_auto or extended classes of this) is the house, not Applications (cmdb_ci_appl).

CIs in Applications (cmdb_ci_appl) are typically generated automatically based on running processes on a server, and is part of what is popularly called "Infrastructure CIs".

Hierarchically:
Business Application -> Application Service -> Application -> Server

Johannes · ‎03-27-2025

Here's a video I have created to communicate internally in our organization how we have modeled the ServiceNow Platform and its applications.

Houchen · ‎05-12-2025

Hi Johannes, I like the video.
One comment, you could simplify your Business Application relationships by having a Platform Host and associated Platform Applications.

In the example you provide you could setup the Business Application to be:
ServiceNow Platform [Platform Host]
ServiceNow IRM [Platform Application]
ServiceNow ITOM [Platform Application]
ServiceNow ITSM [Platform Application]
ServiceNow SecOps [Platform Application]
ServiceNow SAM [Platform Application]
etc