- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
3 hours ago
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
- 71 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
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?
Thanks,
Miklos
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
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
