Applicaton vs. Business Application

[jaguthrie]

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.

[Christopher Hub]

An application should be a discovered instance of application software.  This shouldn't ideally be manually entered, just Discovered.  The Business Application is an abstraction of a stack.  Typically you would progress with Discovery by first ensuring that the servers running application software are discovered, then confirming that the application is discovered on those servers.  Next, you would create some kind of an Application Service, which "collects" the CIs associated with a deployed stack (application software, servers, storage, etc).  Application services can be created manually, or automated using flavors of Service Mapping. 

The application service would be striated into geographies, or (more commonly) criticality, or other system depending on what works best for requirements.  You would for example have  "App-DEV", "App-UAT", and "App-PRD" application services.  These three application services would then roll up under a Business Application that is the abstraction of the Application Services.

[Holger Buchner]

Cool description! In CSDM 5 the term business application will be replaced by „Digital Product“. The application term will be specified as „application instance“, what Chris is using already. 

[Johannes]

No, Business Application will not be replaced in CSDM v5, (even though some consultant companies claims it will:)

SerciceNow are talking about introducing the term "Digital System", possibly as a kind of a "parent" to Business Applications (and possibly also other new classes) in the Design & Planning domain. This will be maybe be introduced in CSDM v6/Australia release.

The Application Service class has already been relabeled to Service Instance (not "Application Instance") in v5, and new sub-classes for other non-IT stuff has been introduced. You can read more about that here:
https://www.servicenow.com/community/common-service-data-model/application-service-and-service-insta...

[Daniel Needles · Accepted solution]

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

1. 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.
2. ITOM Visibility
• The table supports monitoring and event management capabilities by providing the “technical anchor” of an application instance.
3. 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

1. 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.
2. 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.
3. 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

1. 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.
2. 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.
3. 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.
4. 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

1. Keep Business and Technical Perspectives Separate: This is the foundation of the Common Service Data Model (CSDM).
2. Use cmdb_ci_appl for technical software instances discovered or managed in the environment.
3. Use cmdb_ci_business_app to represent the business-facing view. Track ownership, costs, and usage at this level.
4. 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.