Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

Pratiksha
Mega Sage
Mega Sage

One of the most common questions I hear in every CMDB or CSDM conversation is:

“Should this go in Business Application, or should it be created as a Business Service and Service Offering?”

This confusion happens everywhere — ITSM teams, application owners, architects, and even ServiceNow admins.
The good news? The answer is actually very simple once you understand the core idea.

Let’s break it down.


Business Application ≠ Business Service

A Business Application (BA) is NOT the same thing as a Business Service (BS) or a Service Offering (BSO).

They may sound similar, but they serve very different purposes in the CMDB and CSDM.


1. What is a Business Application?

A Business Application represents an enterprise software system that:

  • Supports a business capability

  • Has an owner

  • Has an application admin team

  • Has infrastructure behind it (servers, databases, integrations, or a SaaS backend)

  • Requires lifecycle management

  • Has architectural relevance

Think of it as: The “system” used to run business functions.

✔️ True examples of Business Applications

  • Salesforce CRM

  • Workday HCM

  • SAP

  • Oracle EBS

  • ServiceNow

  • HRMS platforms

  • Banking core systems

  • Manufacturing execution systems

All of these depend on application services, have support teams, and are tied to business processes.


2. What is NOT a Business Application?

The biggest misunderstanding is around desktop software.

Software that is installed locally on a laptop or PC is NOT a business application.

Why?

Because these tools:

  • Do not run on enterprise-managed servers

  • Do not have application services

  • Do not need application admins

  • Do not have architecture documentation

  • Are simply utilities installed on personal devices

Not Business Applications

  • Adobe Reader

  • Microsoft Office (local install)

  • WinZip

  • Chrome / Firefox / Edge

  • Notepad++

  • VLC Player

  • Any end-user tool installed via SCCM/Intune

These tools are part of the End-User Computing Service, not enterprise application architecture.


3. Then what are these desktop tools?

These should be modeled as:

Business Service: End-User Productivity

Service Offering:

  • Adobe Reader

  • Office Suite

  • WinZip

  • Chrome

  • PDF Printers

  • Text Editors

These are offerings provided to employees so they can do their daily tasks — not enterprise systems.


4. The right model: BA → App Service → BS → BSO

To simplify:

Business Application (Architecture Layer)

Describes what the application is.

Application Service (Technical Layer)

Describes how it runs — servers, SaaS backend, integrations.

Business Service (Service Management Layer)

Describes what we provide to users.

Service Offering (Service Catalog Layer)

Describes the individual offerings of that service.


5. Practical Example: Workday

Layer Record
Business Application Workday
Application Service Workday SaaS Subscription
Business Service HR Management Service
Service Offering Workday HR Operations

→ When creating Incidents, users select Service, Service Offering, or CI, not the Business Application.


6. Practical Example: Adobe Reader

Layer Record
Business Application None
Application Service None
Business Service End-User Productivity
Service Offering Adobe Reader

→ Adobe Reader is NOT a business application.

→ It's just an end-user software offering.


7. The rule of thumb (Keep this handy!)

✔️ If the software depends on enterprise servers, DBs, integrations, or SaaS →

Business Application + Business Service + Service Offering

If the software is simply installed on a laptop →

Service Offering only
(NO Business Application)


8. Why this matters

Getting this wrong creates massive CMDB clutter:

  • Hundreds of useless Business Applications

  • No alignment with CSDM

  • Incorrect Incident/Change routing

  • Confusion during audits

  • Misleading dashboards and metrics

When modeled correctly, however:

  • Support teams know exactly what to pick in Incident forms

  • Ownership is clear

  • Architecture stays clean

  • Dashboards show real insights

  • CMDB remains healthy and easy to maintain


Final Thoughts

The distinction is simple:

Enterprise systems = Business Applications

Desktop tools = Service Offerings

Once teams understand this, CMDB modeling becomes clean, predictable, and CSDM-compliant.

If you are often asked this question (like I am!), feel free to share this blog with your teams.
It eliminates 90% of the confusion around BA vs BS/BSO almost instantly.

 

PS:

I’ve personally struggled with this distinction in the past, and I know how confusing it can get when you're trying to model CMDB correctly. I hope this post helps simplify the thinking and enables more teams to understand CSDM a little better. If it clears even a bit of the confusion around Business Applications vs Business Services/Service Offerings, then the purpose of this post is achieved.

 

Regards,

Pratiksha Khandelwal

Comments
Miklos Palfi
Tera Expert

Thank you for this good summary, it addresses many important points well.
We went through also this learning curve and honestly the Application CI class (cmdb_ci_appl) has also caused some misunderstanding for some colleagues additionally.

But now we have to address the issue of managing the lifecycle of those desktop software. Many of those are packaged and are distributed via SCCM/Intune. These packages must be owned, lifecycle managed, n, n-1, n-2 versions kept tracked, also billed.
What's your view on these topics? How do you handle this part of the estate? Are you using the Product owner field in the software model?

 

MiklosPalfi_0-1764238907842.png

 

Thanks,

Miklos

 

Pratiksha
Mega Sage
Mega Sage

Hi @Miklos Palfi , great point.
In previous implementations, whenever we recommended using the Product Owner field, many clients were hesitant. Their main concern was exactly what you mentioned — people leave, roles change, and then it becomes a continuous manual effort for someone to maintain and update those records.

When we integrate with AD, we get groups along with their distribution list email IDs. These can also be represented in ServiceNow as a functional user account, which helps avoid the dependency on a single individual. But again, it really depends on what the client prefers and what fits best without deviating from out-of-the-box practices.

 

Regards,

Pratiksha

Version history
Last update:
3 hours ago
Updated by:
Contributors