CSDM Table for Product Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-25-2023 04:35 AM
■Background
The following three types of information are supposed to be managed in the CSDM table (manual registration).
-Product (All systems owned by a company, e.g., HR system, mail system, ServiceNow, etc.)
-Functions (Areas within a product that provide specific functions)
-Infrastructure (virtual infrastructure at each location, storage at each location, network equipment at each location, zones, etc.)
■Questions
(1) Is the following the appropriate CSDM table for managing products, functions, and infrastructure?
Product : Business Service [cmdb_ci_service_auto]
Function : Application Service [cmdb_ci_service_discovered]
Infrastructure : Technical Service [cmdb_ci_service_technical]
(2) In addition to ITSM, are there any other CSDM tables below that require additional licenses?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-25-2023 05:50 AM - edited 05-25-2023 05:51 AM
Not really, here is my take on this:
Product : Product Models -> Application Model, Software Models -> Technology Portfolio
Function : Business Service and Business Service Offering, visible to consumers/endusers
Infrastructure : Application Service
Then I would add
Supporting services -> Technical Service / Technical Service Offering
Then for each Technical and Business Service you add the "Product Model" to identify every thing around the product.
Then to show the benefit use the Digital Portfolio Management Workspace (DPM), with the supporting modules ITSM, SPM, IRM - to get an complete picture of the PLAN, BUILD, RUN, RISK process.
The data model, might change a bit in the CSDM 5.0 which was presented at know23, but for now, I would use the above data objects.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-25-2023 08:58 AM
Based on your definitions, I would say "Products" as you describe them here are in the Application Service and Business Application table. An Application Service (a.k.a. "system") is a specific deployed instance of the Business Application, so they work together.
Functions, as you have defined it here, do not necessarily exist as a table, but it might exist in some cases as a separate Business Application and Application Service. For example, ServiceNow is a Platform and it is represented as a Business Application, and the Production instance of ServiceNow is represented as an Application Service and related to the Business Application. But in addition, you may have several additional applications which are hosted on ServiceNow Platform, like ServiceNow HR Service Delivery for example, and these too are represented as Business Applications with a reference to the Host application. But not all applications will work that way. Within a non-platform application, there isn't a specific function to break down the logical functions or features of the application itself.
Infrastructure are CIs of various classes, typically Hardware, Applications, and Virtual Objects, which are related up to the individually deployed Application Services.
Also some corrections. Product (i.e. "system") in your definition is in fact most likely represented by the cmdb_ci_service_auto class, but that is actually an Application Service, not a Business Service! cmdb_ci_service_discovered is also an Application Service but it is just a specific kind of Application Service.
Business Services represent the business outcomes delivered to business consumers.
Technical Services represent the technical outcomes delivered to technical consumers.
Business/Technical Service Offerings represent how those Business/Technical Services are delivered to consumers.
Application Services represent the specific instances, application stacks, environments, or systems that are deployed. Application Service have dependencies on Infrastructure.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.