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

bd547 · ‎03-20-2025

This is really helpful. I have a few questions:

Use cmdb_ci_appl - You recommend documenting all the software discovered in the environment.
- Q1: Do we have one object for Tomcat with all the server CIs running in the environment linked to it? Or have a separate Tomcat object with CIs supporting specific business applications linked to it?
- Q2: These software objects must also be tracked for software asset management.
- Q3: How do technical services and technical service offerings come into play here?

Johannes · ‎03-21-2025

Q1: CIs in cmdb_ci_appl (or extended from this) are typically created by Discovery based on the running processes on a server, so you get one CI for each running process that discovery patterns "recognize". The are/should be related upstream to an Application Service (cmdb_ci_service_auto or extended from this). The Application Service is typically a representation of the Business Application in one particular environment, or a more granular representation like a module, an API, etc.

Q2: The Installed Software records used by SAM are created based on the installed software list on a server, but can also be populated based on the running processes on the server.

Q3: TSOs is about how you manage the different technical parts of a system. If your application is running on say "Windows Server 2022", these server CIs (and other similar for other applications) would be grouped in a DCIG (Dynamic CI Group), contained by a TSO managed by a server team. The CIs in cmdb_ci_appl would maybe be grouped by a DCIG contained to another TSO managed by the Tomcat team, and the Application Services contained by a TSO owned by the team responsible for managing/configuring/fixing the actual application. On the business side, you would typically have a BSO dependent on the Application Service(s), representing the usage of the application.

Jim OShea · ‎03-21-2025

How typically do you see organizations determine the granularity to track application services? In your Q1 answer you mention they're typically tracked at the environment level, but at times you see more granular tracking at a module or API level. What reasons are there for tracking more granular than environment? Additionally, and hopefully this isn't too far off topic, how do you see platforms such as Workday, SAP, Salesforce or even ServiceNow itself built out? ServiceNow as the BizApp and ServiceNow_PROD/_TEST/_DEV as AppSrvcs? Or if you wanted to be more granular maybe an AppSrvc ServiceNow_PLAT related back to the BizApp and _TEST/_DEV/_PROD AppSrvc's related back to the _PLAT?

I've often thought they should include ServiceNow as an OOB business application / application service as an example. 😀

Johannes · ‎03-23-2025

In our organization, we default automatically generate Tag-based ASs for each environment the owners of the applications say they have, so that the infrastructure CIs we discover that are tagged as agreed upon, automatically gets related.
In addition, we have some applications where the owners needs a more granular level, where they typically separate the ASs into the modules delivered by the application, and maybe a downstream "platform" AS they all depend on.
We have also started representing APIs as ASs, but are hoping for a more OOTB solution from ServiceNow, where both the data we have in Digital Integration Management can be used, preferably combined with API data imported with new API Insight app.
For our ServiceNow instance, we have created the SN platform as one "platform host" BA, and the other SN applications we use as separate "platform app" BAs, where their ASs are dependent on the SN platform ASs. Some "modules" within the apps are divided into separate ASs, but others are only represented as Business Service Offerings pointing to the same AS. I believe there is no "correct" answer on how to do this, as it should be done based on what you need to represent.
ServiceNow themselves have a lot of guides and examples on how to model both ServiceNow, SAP and many others, e.g.:
https://learning.servicenow.com/nowcreate/en/pages/assets?id=nc_asset&nc_ai_search=true&asset_id=42a...

andrewrouch · ‎03-23-2025

That is essentially what we have done as well, although we are only just starting to use Business Service Offerings.