should any CIs exist in the base cmdb_ci_service class?

[ahbrook]

Hello there! 

After a few months away, I'm finally able to turn my attention back to our service and service offering structure, and trying to align with the CSDM v5. However, I have a bit that I'm not sure if things are.. correct.

Our implementation partner handled converting our old ITSM data into ServiceNow ITSM. That previous system had a concept of "systems" rather than services as SN defines them. So the implementer took those systems and loaded them into our "cmdb_ci_service" class for the CMDB. The vast majority of these have a Service Classification of "Application Service," though many have "Technology Management Service" listed. When I click through on these services, I'm presented with buttons that say "Convert to Application Service," and related links to "convert to business service" and "convert to technology management service." 

All of the items appear to be in the "Pipeline" phase with a status of "Operational" or "Requirements." 

Further, some of the services do have attached offerings. These are in the form of listing our environments - for example, "TEST" or "PROD" versions of the application service.

Now, this is somewhat working for us now - in that when our help desk folks create an incident or service request, they are able to select these services and offerings to indicate the affected system. But it really feels like this runs contrary to the rest of the CSDM, and when I try to properly implement things, I'm going to run into confusion.

This gets back to my initial question: Should there be any CIs at the top level "cmdb_ci_service" if you are following the CSDMv5? I am betting these need to be broken into proper application instances and business applications, and moved out of there. 

[Mathew Hillyard]

Hi @ahbrook 

A Service is either a Business or a Technology Management service. It cannot be both and cannot switch based on context. If you have consumers of that service that are internal, external, public or students then that's a Business Service. For finer-grained management of scope CSM would possibly help, but reserve Technology Management Services for things that people who build services request or use.

I find that you need to make it real to help stakeholders understand the concept. Build a real service that your org would recognise (in a sandbox if possible), then talk through the various objects and relationships, linking them back to their definitions. This is a model designed (in theory) to fit any organisation type, size, or structure.

The most common question I've fielded is "what should X be" - X being the name of something in the existing environment. Take a clear description of what it is and test it against each of the CSDM definitions to get the answer (and the justification - the "why").

I hope this helps!

Mat

[Vijaya_Mnpram]

@ahbrook  As per the screen shots, those should be Business Applications and respective environment will be Service Instance. 

I mean, Outlook(365) should be a Business critical Business Application and TEST, PROD and DEV will be Service Instance. 

Email can be a Business Service and OWA (Outlook Web Access) and Blackberry can be Business Service Offerings. 

If you map Outlook365 and environments as parent child in Services, the difficulty is when you want to map the Infra for each environment. We can always map Infra (like Email servers) to the Service Instance but not to Service Offerings. 

[ahbrook]

This is where I'm hoping to head with things, though I do want to capture our Outlook (365) as being a subset of Microsoft 365 - specifically the fact that we have an A5 plan. This is because we administratively restrict a chunk of M365 functions, or at least have controls/configs on them. I'd love to see a CSDM-compliant map of the entirety of M365 as a use case example... I think the "CSDM Data Model Examples" powerpoint (May 2025 version, page 35-38) gets close, but A) it starts at Run/Fly, without showing crawl/walk implementations, and B) it only shows a small snippet of all the functions in M365.

I have been thinking lately that there might be some value in coming up with a standardized/normalized set of systems, apps, and definitions that can plug into these models, so other architects can have a starting point on the totality of what a product can do -- and then customize or narrow down to the functions and business capabilities they actually use. But I recognize that would be a near impossible task to maintain for every bit of commercial software out there. I don't know.. at this point I think I'm just musing out loud, hoping someone has already done that work. 🙂 

Again, thank you for the guidance. I know a lot of my confusion has been around (Application) Service Instances... I wish there would have been a more clean break for them in the CSDMv5 so that overlapping terminology wasn't used for what a "service" is.