- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on
10-10-2024
11:34 AM
- edited on
03-19-2025
01:31 PM
by
Kranthi P
It is a question we get all of the time and its not so simple yet it can be crucial to you successful application portfolio practice and it could impact you enterprise architecture program since the application portfolio is a crucial tool in an EA practice. In order to help you in identification of business applications, please see the attached document that @justincatchings has built for us.
In ServiceNow’s Common Service Data Model (CSDM) Whitepaper, a Business Application is defined as
“A business application represents all software and infrastructure (For example catalog of titles) configured to provide business functionality. Business applications are the logical representation of all instances, used to increase productivity and to provide functionality to perform business functions accurately (For example payables, receivables, general ledger). Business applications are typically the software used by business users, but also may represent the “products” that the business uses for generating revenue or performing missions. They can span multiple environments and / or deployed per geography (For example dev, test, prod, or Americas, APJ, EMEA)”.
Let us take this definition further. A Business Application is not Software but instead an abstract representation of all the Software, Hardware Technologies and Services that are working together to “perform” a business function. It is important to remember that IT is business so this definition includes those foundation systems that are pillars of the enterprise such Identity and Access Control like Active Directory. Another term for Business Applications might be Enterprise System or perhaps Digital System.
In many cases, there may well be a single, key Software product that is indeed the “primary” software element of an overall deployment but it still requires at least some form of operation system and most like backend and middleware software plus virtual or actual hardware to run on.
A Business Application record is the abstract, Design level, parent of each and every deployment or instance of the application. These deployments can vary widely in environment, locations, versions, constituent usage and so forth. The common thread is they are all an “instance of” or a “deployment” and have a real physical presence.
What about Software as a Service (SaaS)?
SaaS as well, the only difference with SaaS is how we treat the Application Service(s) as they will have no Infrastructure (Servers, Databases, middleware, etc.) associated because the actual running instances of software/hardware is hosted and managed by the vendor.
Why is this software, “ABC Product” not a Business Application?
Why is something like Oracle Database not a Business Application? Oracle DB is most certainly a very important part of many Business Applications but by itself, even deployed with its supporting software/hardware (servers, operating systems etc.) it does not do anything until such time as you configure an Application Schema, tables etc. and the other parts of the application, code, microservices, middleware connection and so forth push and pull data from it.
- 20,071 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Great post and attachment @mcastoe!
Question:
It is usually dedicated stakeholders follow up on the risks, lifecycle management, rationalization etc. regarding databases, operating systems etc, and not the stakeholders of the application dependent on them, so why would you not want to offer the same capabilities the Enterprise Architecture Workspace offers for these?
Where should they instead "do" their product governance?

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
I have the same question as @Johannes. I can see not having an application service, but there should still be a Business Application.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Interesting since we define them slightly differently. We are using Business Applications as the umbrella item, where Application Services would be the representation of the environment. You mention SaaS as not needing an Application Service, but I disagree - it has an entry point (a URL) and therefore SHOULD have an Application Service as defined. A SaaS could have multiple entry points for various environments (we have three for ServiceNow alone) and therefore each needs its own Application Service.
We could be using it completely incorrectly, but that is how we are currently doing it.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi @SNFan
As far as I know, you can not use the functionality provided with Enterprise Workspace (APM) for TS/TSOs, like rationalization, TPM/TRM, etc., hence the reason I am asking 😉
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
@Johannes,
While i agree rationalization of distinct technologies, OS, database, middleware etc are definitely important and to be considered, our other product offerings by SAM/HAM have a degree of this capability especially SAM Pro. So, if we incorporate into EA, we have a duplication of functionality. We have asked for an enhancement to allow "assessment" at the Technology Reference Model (TRM) level and that is where, in EA, we would do individual tech rationalization. I've seen a few of our TRM customers create/configure the appropriate workflows for this. A TRM Product is a declaration that a particular Product (software, hardware, coming at some point patterns) is an allowed technology standard in the organization/enterprise. A great point of focus for periodic rationalization.
@SteveMac1 , indeed, all Business Applications must have at least one Application Service, Saas and otherwise. I was stating that the Application Service would likely not have any infrastructure CI relationships.
As for Technical Service and Offerings, by CSDM and Service Portfolio best practice, they must/should be created at the appropriate layers: Application Service, Infrastructure and Delivery. While it would be excellent to have a association/reference from a TSO to the TRM Product being "delivered/supported" by the TSO, the wide varioation on how TSO are defined and the facilities to management them being outside of Enterprise Architecture's (our tool not the practice) area of concern, make it difficult to do anything with TS/TSO in EA Workspace though Modeling does indeed recognize and include them.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
@mcastoe I'm a little confused / concerned with some points you made in your response and I'm hoping you can clear them up.
E.g. In your first response to @Johannes you say:
definitely important and to be considered, our other product offerings by SAM/HAM have a degree of this capability especially SAM Pro. So, if we incorporate into EA, we have a duplication of functionality.
This implies dependency on SAM / HAM within CSDM, and from my recollection CSDM is not supposed to be dependent on any product. If a company does not have SAM / HAM, how are they to model these?
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
@SteveMac1 ,
Sorry for misunderstanding. No, CSDM does not depend or really address the concepts of Software and Hardware as products beyond a vague reference to Product Models. I am speaking in terms of what ServiceNow Enterprise Architecture (fka APM) does with these. Other than the intent to clearly define what a Business Application represents, this an EA conversation rather than CSDM.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
In the context of the ServiceNow Common Service Data Model (CSDM), a business application is defined as an abstract representation that includes not only software, but also the associated hardware, infrastructure, and services that together enable business functions. This includes everything from the primary software products to the underlying fundamental systems, such as Active Directory, that keep the enterprise running. Always thought by the way that best digital business card matter too. A business application is not just software, but a complete ecosystem - software, hardware, and services - that provides critical business functionality.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
When you have a platform that has multiple instantiations would you model it as multiple business applications.
e.g. Salesforce as the platform, but you have different orgs that support different business units or functions how would you model it.
Option 1 - Platform only
- Salesforce only
Option 2 - Platform and applications
- Salesforce
- Application 1 (Salesforce software model)
- Application 2 (Salesforce software model)
Option 3 - Apps only
- Application 1 (Salesforce software model)
- Application 2 (Salesforce software model)
Which approach would I take.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
A Business Application refers to the combination of software, hardware, technologies, and services working together to perform a specific business function. It’s not just a single software program; rather, it is an abstract representation that includes all the components that work together to enable business processes.
For example, a business application could be a payables system. While the software for managing payables is the main element, it also includes the infrastructure, operating systems, middleware, and any other technologies that support and ensure the functionality of the software. This broader view includes foundational systems like Identity and Access Control (e.g., Active Directory), which may not directly interact with business users but are critical for system operations.
Key Points to Understand:
- Business Applications are Logical Representations: They represent all components (software, hardware, services) that together enable business functionality.
- Not Just Software: A business application involves the integration of various elements such as operating systems, databases, servers, and even middleware.
- Not Typically Single Software: A business application could consist of multiple systems working in concert—such as the interaction between databases, backend software, middleware, and business-specific applications like CRM or ERP systems.
- Software as a Service (SaaS): For SaaS, the application service is hosted and managed by a vendor, which means the infrastructure (servers, databases) is abstracted away, but the business application still operates as a service to perform business functions.
A Business Application Record is essentially the “parent” of each deployment or instance of that application, spanning different environments and versions.
Example of Business Applications:
- Enterprise Resource Planning (ERP) systems
- Customer Relationship Management (CRM) tools
- HR or Finance systems
Why Something Like Oracle Database Isn’t a Business Application:
While Oracle Database is a critical component of many business applications, by itself, it doesn’t constitute a business application. It’s the framework or backend that supports data storage and retrieval. Only when it's configured with application logic (such as schemas, tables, and connections) does it become part of a functional business application.
To summarize, a Business Application is a holistic representation of the various software, services, and infrastructure that work together to perform a key business function, and it's crucial to understand its abstract nature in enterprise architecture and application portfolio practices.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
A Business Application is essentially a combination of software, hardware, and services that work together to provide functionality for a business function, such as payables, receivables, or general ledger operations. It is not just the software itself but represents the entire environment required to perform a specific business task. This could include the software being used by business users, as well as the underlying infrastructure like servers, middleware, and even identity management systems like Active Directory.
In simpler terms, a Business Application isn't just a single software product; it's the broader system, including any supporting technologies and services, that enables a business to operate effectively. For instance, while a product like Oracle Database is vital to many business applications, it's not considered a business application on its own because it doesn’t serve a business function by itself—it requires additional components (like code, services, or middleware) to fulfill that role.
In the case of Software as a Service (SaaS), the difference is that the infrastructure is managed and hosted by the vendor, so the "business application" consists solely of the application service, without the need to manage underlying hardware or infrastructure.
The definition provided by ServiceNow in their Common Service Data Model (CSDM) Whitepaper highlights the broader scope of a Business Application, which includes all components working together to achieve a business function.
If you're implementing or managing business applications within your enterprise, understanding this holistic approach is crucial for managing your application portfolio and supporting your enterprise architecture effectively.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
I saw a different user ask a similar question, but I didn't see a response. we have having this discussion internally and I would like your inputs.
As we take our ServiceNow platform (everyone's favorite) as an example, how would you structure this.
ServiceNow Platform
- ITSM
- APM
- SPM
- SecOps
- etc etc.
Currently we have business application records for every module, but it causes a lot of confusion for EA, Security, audit and others. I would like to simply put it down to just having ServiceNow as the only business application in this example and then details the modules in the business capabilities.
Thoughts?
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
@grant21 - That's an interesting take on it, and I definitely like the idea of minimizing confusion amongst the users of the system. For ServiceNow, my org is attempting to treat it the way we treat SAP, M365 and some others, as Platform Host and Platform Applications. One disadvantage I can see of your proposed simpler approach, is that when it comes to assessing applications, I think you would want to distinguish between assessments for ServiceNow's different modules. For example, users may be very happy with APM/EA but not so much with SPM. If you have it all lumped into one Business Application, then the assessments and rationalization efforts are also lumped all together. You may have workarounds for that, just something to consider.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Determining what should be an app in EA/APM has been more of an art than science for us. For ServiceNow specifically, we've chosen to lump ITSM, ITOM, ITAM, etc. into one entry "ServiceNow" which is a platform host. We then list APM, SPM, and a few others separately... for much the same reasons as @cbaser mentioned. APM/EA ownership is separate from SPM which is different from the "core platform". Not that ownership is a sole determining factor or anything... So far (knocks on fake wood desk) this is working out for us.