Hierarchy concepts in business application table

AjJomt
Tera Contributor

I manage the CMDB in ServiceNow, and I need to organize our setup.

For the `cmdb_ci_business_app` table, we have two distinct concepts differentiated by the architecture type:

  • Components (=platform application): These are the actual software items that are released, have a lifecycle, etc.
  • Products (=platform host): These are collections of business capabilities that may include multiple software, hardware, etc.

There's a parent-child relationship in the `business app` table as well as a `consumes by/consumes` relationship.

 

First Question:
What are the best practices for managing these concepts? Are we on the right track?

 

I need to model two other concepts: a product parent (Product Family) and an other parent (Product Category)
- A Product Family consists of products.
- A product Category consists of Product Family

 

How should I model these? I was thinking of adding new architecture types, but I'm not sure if that's the best idea. How can I align with ServiceNow's CSDM 4.0 (5.0) best practices with these requirements?

Proposed Solutions:
1. Using Custom Tables:
- Create custom tables for both new concepts, inheriting from `cmdb_ci`.
- Define relationships between `cmdb_ci_business_app` (products) and these new custom tables.
2. *sing Existing Tables:
- Use the `cmdb_ci_service_group` table to represent `Product Family`.
- Use the `cmdb_ci_service` table to represent product Category.
- Create relationships: Product (cmdb_ci_business_app) -> Product Family (cmdb_ci_service_group): Use `Uses::Used by` or a custom relation.
- Product Family (cmdb_ci_service_group) -> product Category (cmdb_ci_service): Use `Contains::Contained by` or a custom relation.

 

Which approach would be the best to follow, considering best practices and alignment with CSDM 4.0? And which tables should I use (may be not service ?) ? 

 

Thanks a lot for your help.
A. J.

 

 

 

1 ACCEPTED SOLUTION

Mark Bodman
ServiceNow Employee
ServiceNow Employee

The Architecture Type was intended to capture the different types of Business Applications that exist, and in the context of Platforms, which was the platform host itself (like ServiceNow) and which were the apps on the platform (like Digital Product Release) which are designed to run on and depend on the platform to exist. 

This Platform Examples video explains the concept, and how they relate to one another and other entities in the CSDM model.

 

As for how to manage the Application Portfolio, I wrote this APM community article some years ago to explain the practice and provided advice on how to structure them as well.  The images don't seem to work, but the explanation still stands.

View solution in original post

1 REPLY 1

Mark Bodman
ServiceNow Employee
ServiceNow Employee

The Architecture Type was intended to capture the different types of Business Applications that exist, and in the context of Platforms, which was the platform host itself (like ServiceNow) and which were the apps on the platform (like Digital Product Release) which are designed to run on and depend on the platform to exist. 

This Platform Examples video explains the concept, and how they relate to one another and other entities in the CSDM model.

 

As for how to manage the Application Portfolio, I wrote this APM community article some years ago to explain the practice and provided advice on how to structure them as well.  The images don't seem to work, but the explanation still stands.