Sharing real World CSDM Data?

[Tone1]

Someone eager to share real world data of their CSDM Tech Services/Offerings?

Over time i saw a lot of different approaches how to model the Technical part of the CSDM and more i know the more i get confused. Is someone willing to share some excel exports of the Service Delivery part?

[Cassandra Kittl]

I'm a proponent of prefixing certain CI classes with a prefix. The criterion for the prefix is for those that are user created such as Dynamic CI groups, Business Applications and Service Instances.  Business Services and Technology Management Services are an exception in that there aren't sources into CMDB that are likely to be named the exact same thing as the ones previously mentioned.  Let's use UKG:

There could be a Business Application and a Service Instance named UKG Time and Attendance. While the Configuration Item field should NOT show Business Applications, when "UKG Time and Attendance" displays - without the prefix, it's not apparent which is shown. There are other forms IPC, Requests, and Outage where the type of CI is not explicitly apparent. 

Note, I have applied a service specific prefix to a service offering when the offering can be applied as a name to multiple services. (Service Offering names must be unique).

Please give me credit (thumbs up) if my response is helpful.

[JeffE]

Hello,

Here is my 2 cents. As part of setting up and deploying ServiceNow ITSM, you should already be excluding the Business Application table from selection across all tasks so there shouldn't be confusion on if you are selecting a Business Application or a Service Instance CI.

I am not a proponent of prefixes because you should be filtering at the class level for things you want to display. I also think about it from a Service Desk or Help Desk perspective, if I type AS, I could possibly see hundreds or thousands of CIs. I know there are instances in some CSDM examples where you can have two CIs with the same name, so we avoid that at all costs. I have seen examples where Business Applications are listed as Service Offerings, so we don't do it and often times just keep them as Service Instances. We figured it would cause more confusion than clarity especially for a team who has to manage and report the same CI across multiple classes.

I am a proponent of adding suffixes to service instances to indicate environments but not including Prod on production instances so that production always displays at the top of the list when users are searching for CIs in CI fields. Example, if I have three environments for App1, we create App1, App1 Dev, App1 Test, so if service desk is looking for App1, when they start typing App1 (the production instance) is listed at the top. 

For real-world examples, we have separated Technology Management Services based on service ownership. When I say ownership, we think in terms of the team and manager responsible for ensuring the service is running and healthy, owns the budget and forecast around providing the service, and ensuring it is cost optimized. As an example, we know that Compute can include cloud compute and on-prem compute, but we created different Technology Management Services (because we have different ownership and support) for Cloud Computing and On Prem Computing. The service offerings we support under each Technology Management Service also have different on-call schedules and support so that helped us delineate a little bit more, such as Windows Virtual, Windows Physical, Linux Virtual, and Linux Physical. We then are able to create Dynamic CI Groups to data sync information with the service offerings, so when new devices are discovered with the appropriate attributes, they automatically inherit or have fields updated in accordance with the service offering. I have other examples around Storage where ownership around Mainframe, File Storage, Block Storage, and Cloud Storage are owned by different managers, support teams, etc. I don't know if it's 100% the way to do this, but it's the way that works for us and gives us value because at the end of the day, everything we are doing should be making life easier, not harder, and providing value to the teams using the platform.

This concludes my TedTalk,
Jeff