Ever been in a meeting where everyone talks about “applications,” but they’re all picturing something completely different? One person thinks of the software on their laptop, while another is imagining a massive, deployed system in a data center. It’s frustrating, right? This confusion is a common problem and often leads to a messy CMDB (Configuration Management Database) and a lot of wasted time.

The good news? ServiceNow’s Common Service Data Model (CSDM) is here to help. CSDM provides a common language so that everyone, from architects to the service desk, can get on the same page. Let’s break down the key CSDM concepts using a simple, real-world example of an online retail company.

The different applications: A look through CSDM’s lens

At the heart of the confusion are the different ways we use the word “application.” CSDM clearly separates these into distinct components. Let’s take a simple real world example: Online Retail or e-Commerce to further understand the lingo.

1. Business Capability: The “What”

Think of a business capability as what your company does to achieve its goals. It’s a high-level function that doesn’t change very often. It’s not the technology itself, but the business process it enables. In our example, let’s start us take a core capability necessary for any online business.

• Order-to-Cash: The overall ability to take a customer order and receive payment.
  • Customer Order Management: A sub-capability that focuses specifically on handling customer orders.
  • Payment Processing: The sub-capability for managing payments securely.

2. Business Application: The “Tool”

This is the logical, portfolio-level view of the application. It’s the “thing” you buy, build, or decide on as a strategic tool to enable a business capability. It’s a conceptual model, not a deployed instance. Enterprise Architects live in this world.

• Online Storefront: The software that powers the website where customers browse and shop. This is the Business Application that enables the Customer Order Management capability.
• Payment Gateway: A third-party service provider you have a contract with to handle payment transactions.

3. Application Service (or Service Instance): The “Running Thing”

This represents the live, deployed instance of a Business Application. It’s a collection of all the CIs (Configuration Items) needed to deliver the service in a specific environment (like production or development). If something breaks, this is what you report an incident against.

• Online Storefront PROD: The specific live version of your online website used by customers. It’s a logical grouping of all the components that make it run, such as the production servers, database, and SSL certificate.
• Online Storefront DEV: The separate, non-production version where developers test new features. It has its own dedicated components.
• Payment Gateway API Prod: The secure and production version of the payment gateway that handles actual payment processing from the end-user and transfers the amount to the business’ bank account.
• Payment Gateway API Test: The test environment provided to test the payment against order functionality without actually requiring money or credit cards.

4. Application (the CI): The “Building Block”

This is the specific software product installed on a server, such as a database or web server. It is the technical component that forms part of an Application Service.

• Maria DB: The database software running on a server that supports the Online Storefront PROD Application Service.
• Apache Tomcat: A web server software that could be part of the underlying infrastructure for a web application.
• WordPress: A web framework installed on your web server that brings in the core CMS functionality.

5. Other CIs: The “Additional Building Blocks”

The application CI only refers to one kind of CI class. The application service in our example contain more CIs that are crucial for the e-commerce website operations. In our example this includes:

1. Servers:
   1. DB Server: Hosts Maria DB and My Admin
   2. Linux Web Server: Hosts Apache Tomcat and WordPress
2. Certificates:
   1. SSL: A web certificate that encrypts transmitted data
3. APIs:
   1. Payment gateway prod: Connects to the production version of the Payment gateway
   2. Payment gateway test: Connects to the test version of the payment gateway
4. Domain name servers
5. CDN

Putting it all together with CSDM

The power of CSDM is in formalizing the relationships between these different elements. This structured approach provides clarity and improves incident management, change management, and impact analysis.

Let’s look at the flow for our online retail example:

• A Business Capability like Customer Order Management is enabled by a Business Application, the Online Storefront.
• The Online Storefront Business Application has a deployed Application Service, Online Storefront PROD.
• The Online Storefront PROD Application Service is composed of several technical Applications, like WordPress, Maria DB, and other CIs (servers, certificates, CDN).

By establishing these clear relationships, you can trace an issue from a failed technical component all the way up to the business capability it affects. When a database server (Maria DB) goes down, CSDM tells you that it will impact the Online Storefront PROD Application Service, which, in turn, affects the Customer Order Management Business Capability.

Why is this important?

If you’ve dealt with a disorganized CMDB, you know the pain of mismatched CIs and confusing reports. CSDM solves this by providing a blueprint for your IT assets.

• For Enterprise Architects: It provides a clear, high-level portfolio view.
• For Application Teams: It defines the scope of a deployed, manageable service.
• For Infrastructure Teams: It provides a map of how individual components contribute to a service.
• For Service Desk: It links incidents directly to the correct, deployed service, speeding up resolution.

In short, CSDM gives everyone the same map, so you can all work together to fix problems and manage your IT landscape effectively, without talking past each other. It’s the key to a cleaner, more reliable CMDB.

Resources:
https://www.servicenow.com/community/s/cgfwn76974/attachments/cgfwn76974/common-service-data-model-kb/744/3/CSDM%205%20w%20links.pdf