MSP Domain Separation - CSDM 4.0

[ashleygiann]

Hiya,

I work for an MSP who offers and support infrastructure services to customers, our customers are onboarded to our platform as part of domain separation and our domain model is defined. 

I am trying to wrap my head around the CSDM service structure for services in this way. 

As an example an Infrastructure Service.
Traditionally you would create a business service called Infrastructure Management and have Service Offerings called Standard, Gold ect....
As part of CSDM that Offering would be related to an Application Service for say the data centre.
This would then have CI's for all the servers as part of that data centre.

For an MSP this doesn't work due to not having the visibility per customer.

I have been trying to design a few models

1. Business Service - Infrastructure Management, Service Offering - Customer X Infrastructure Management, Application Service - Customer X Data Centre

2. Business Service - Customer X Infrastructure Management, Service Offering's - Maintenance/Access/Software, Application Service - Customer X Data Centre

Any advice would be appreciated and if there is any reference material for this out there to read would be helpful.

[a_soto87]

Ashley,

We leverage ITOM Health and ITOM Visibility. I've not yet been tasked with figuring out how the organization will incorporate CSDM principals in our Discovery but I do think about it often.

Curious to know what you've come up with. We have a lot of clients, the services vary including the level of responsibility, and we have a taxonomy in place that I'm not sure would even work well for CSDM. In my discussions with leadership, I've advocated for only implementing CSDM for our larger, strategic, accounts. I mean, for example, we have Network Management but I can't just throw the network hardware against that Business Service because it could be 5,000 devices across various networks. That's when you start to get into defining the services at each location, ownership of the services, CIs for that and then looking into how to set thresholds on that stuff.

It's going to be a massive undertaking.

Hoping to hear back from you!

[Jan Ujcic1]

Hi,

did you have any luck in get relevant information on this topic (specific to MSPs)? We are in a similar situation where moving the business towards the CSDM is incredibly valuable in the long-run but hard to implement since it requires significant changes of how some things operate. There's many ways to model what we do so it would be nice to see some similar ideas/approaches.

[fknell]

Hi @ashleygiann,

with domain separation you might need to replicate CSDM data to each domain, to have it present and leverage it for processes / workflow running under the domain context. 

Is there a need to use domain separation only?

A combination of CSM and ITSM/ITOM might be an option too. Meaning, linking the service consumption domain from CSDM with the product and install base from CSM.

Hope this helps!

[DaveMerrett]

Hi Ashley, 

I'm unfortunately going to give you a very 'developer / partner answer' and  apologies for doing so. 

CSDM has a few assumptions 

• A single enterprise
• Clear ownership of business services
• Shared visibility across services

As an MSP  your introducing the following:

• Multiple customers (tenants)
• Strict domain separation
• Need for repeatable service templates
• Requirement for per-customer visibility + isolation

You don’t model services globally,  you model them per customer domain.

Your different options you've presented, as someone who runs a MSP Instance, as someone who is a developer I look at in the following

Model 1
Business Service (Global) → Customer-specific Offering → Customer App Service

Pros:

• Reusable top-level structure
• Cleaner taxonomy

Problems:

• Breaks domain separation visibility
• Business Service becomes meaningless to customers
• Reporting becomes messy (shared BS, isolated AS)

Verdict: Not recommended

Model 2
Customer-specific Business Service → Offerings → Application Service

Pros:

• Fully aligned with domain separation
• Clear ownership per customer
• Clean reporting, SLA, and experience mapping
• Matches how MSPs actually deliver services

Trade-off:

• More objects (but this is expected in MSP models)

Verdict: This is MUCH closer to best practice

Best Practice for MSP CSDM 

Per Customer Domain Model 

For each customer:

Business Service

• Customer X – Infrastructure Management

Service Offerings

• Monitoring
• Maintenance
• Access / Support
• Backup / DR
• (Avoid Gold/Silver naming unless truly different services)

Application Service

• Customer X – Data Centre
• Customer X – Azure Environment
• Customer X – Network

Technical Services (Optional but Recommended)

• Computer
• Storage
• Network

CIs

• Servers, VMs, firewalls, etc. tied to Application Services

Recommendation

Go with a refined version of your Model 2, but:

• Avoid pricing-tier naming (Gold/Silver)
• Focus on capability-based offerings
• Keep everything customer-domain aligned
• Use templates + automation for scale

By keeping everything in Customer Domain alignment you get 

• CMDB clean
• Reporting accurate
• Customers isolated