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. 

[Fabian Kunzke · Accepted solution]

Hello,

It is common to migrate everything into that CMDB table. But yes, when aligning with CSDM, you should move these into their proper classes. However, judging by the screenshots, it seems that at least some of these records are indeed in the correct table already.

So make sure that they are indeed in the base class. Any records from child classes will also be shown in their parent class. You can best check that by looking at the sys_class_name property of each record (called "Class" in the list view).

Regards

Fabian

[ahbrook]

Thank you, that helps a ton to view things closer! 

Using that, it appears we have the following in our DEV environment:

• 321 "Service" classes
  • 251 "Application Service" Service classifications
  • 70 "Technology Management Service" Service Classifications
• 1 "Application Service Group" class ("All")
• 43 "Business Service" classes (the portfolio structure I added)
• 1 "Mapped Application Service" class (*ServiceNow Event Management)
• 371 "Offering" classes
  • 16 "None" Service classifications
  • 106 "Business Service" Service classifications
  • 108 "Technology Management Service" Service classifications
  • 141 "Application Service" Service classifications
  • (0 "Service Offering" Service classifications)
• 23 "Service Instance" classes (All "Application Service" service classifications - I think I added these)
• 38,864 "Technology Management Service" classes (all with "Technology Management Service" Service classification -- long story)

So based on what you are suggesting/recommending, I should probably move the CIs in the root "Service" class into the appropriate child CIS -- once I make sure it won't break anything, like permissions/access.)

This makes sense, and thank you for helping me figure out how to view the hierarchy better. Turns out I had a custom list view in place that was overriding the global modifications I was using. 🙂 

[Mathew Hillyard]

Hi @ahbrook 

Rather than just moving things, I'd assess what you have and where you want to be with each object. Given the current position it could well be the case that some or more of these objects, or the data in them, belong elsewhere. 

The base service class has many classes extended from it - Business and Technology Management Services, Service Offerings, and Service Instance with all of its extended classes as well (including the various Application Service classes).

Have a read of the CSDM white paper and be clear on the definition of each object. Some guidelines:

• Business Services should not generally contact a product or vendor/manufacturer name but should express what they enable. 
• Service Offerings are a flavour of Business/Technology Management Service and will often contain a product (e.g. Office 365). I'd avoid putting the environment into the name - the Environment field exists for this purpose.
• Business Application represents a piece of application technology in its entirety - agnostic of version or deployment
• Service Instance links Business Application to Offering and represents a deployment of either a Business Application, or a group of related CIs (a Dynamic CI Group).

It is not uncommon for people to combine one or more of the objects above into a single object, or spread data attributes that belong in one object to an entirely different one, so also be clear on what attributes belong and where - e.g. operational information should not normally reside in a Business Application.

In your screenshots of Outlook in your first post, the first image (Outlook 365) should probably be both a Business Application and a Business Service Offering, and the second image (Outlook 365 Production) the object that joins the Business Application to the (production) Service Offering - a Service Instance.

I hope this helps!

Mat

[ahbrook]

Oh, I 100% agree. I've been pouring over the whitepaper since it first came out, first to try and convince my institution to adopt it, and then to try and explain it to people better. When I say "move," I don't mean straight lifting and shifting. I plan on going through and properly building out things, and more importantly making sure that everyone agrees on the terminology used and how it is represented. 

The hardest part, honestly, is explaining all those interlinking features and why they need to be there. In the old system, it was fine to just casually mention an app (or its environments), and move on. I know how much ServiceNow benefits from the CSDM being implemented right, but I'm not at a point where I can have others fit into that model themselves. So I am needing to come up with "on-ramps." 

I'm also exploring this topic in the context of higher education, and trying to lean on the models put out for those (such as the higher education reference model from educause). One of the biggest problems with higher education is that we have multiple customer bases - internal, external, public, students, prospects, decentralized IT, etc - that need to be represented, and services switch from being business to technology management pretty quickly based on those lenses. 

Again, I very much appreciate the feedback. I'm trying my best to incorporate it.