Best Practice for Representing Application Modules in CSDM

VulcanLogic · ‎10-08-2025

In our CMDB (aligned with CSDM v4), we currently have Business Applications and Business Services defined — for example, Outlook as the Business Application and Email as the Business Service.

Similarly, other applications are classified this way. However, when it comes to application modules, some are microservice-based while others are logical components of the main application.

For instance, our Passenger Booking Application includes a Billing Module (a separate microservice) and a Fare Module (an inbuilt feature within the main app).

I’d like to classify incidents by module when issues are reported and also route change approvals to the respective approvers based on these modules. Currently, our CMDB only defines Business Applications and Services — so we lack lower-level granularity.

👉 Question:
Which CSDM domain (Design, Consume, Capability, or Build) should these application modules reside in?
Are there any existing tables or CI classes recommended for representing these modules?

One option I’m considering is using the cmdb_ci_appl_component table to record logical modules as components, or alternatively, defining them as child Business Applications.

Has anyone faced a similar challenge? How are you modeling and managing application modules in your CSDM-aligned CMDB?

Barry Kant · ‎10-09-2025

This is one way to do it:

Have indeed a 2-layer business application:
- Platform/Host
- Application/Module

You would do this when:
- your build/models/deployments/funding is/can be different/separate.

Each of those records will have Application Services below per deployment:
The Business Application for the Incident application component will have an Application Service per deployment with a depends on relation to the platform deployment Application Service.

BR,

Barry

View solution in original post

VulcanLogic · ‎10-13-2025

Thank you @Barry Kant , this approach makes sense. Will try it.

Tyson Elder · 2 weeks ago

We've also been looking at this.

We currently just have 'ServiceNow Platform' (BA) and a service instances for our deployed instances.

I've been looking at this CSDM example (This is provided by ServiceNow)

I'm really conflicted. I get it - it's the right way - but the overhead here is significant.
The relationships between the service instances are manual.
6 instances.
We'd end up with 6 business apps (1 platform host, 5 platform apps)
Thus....6 instances...that's 36 instances to manually maintain and 36 manual relationships.

Heaven forbid we'd consider this for Azure Platform. I'm totally open to improving the modelling.

Our primary rule is really more guided by:
Does this have a different technical product owner?
We will model all subprod instances of the platform, but only the prod instances of the platform applications Service instances.

This one stings.