CSDM - Services naming conventions

[Ben Van Aken]

Dear all,

I'm currently trying to get my head around the Service layers of the CSDM, more specifically I'm struggling with coming up with a standard naming convention for Services (business, application, technical)

From the limited examples I've seen so far, mainly the application service seems to be composed of different attributes of its underlying CIs which makes perfect sense. On top of that, it also ensures that from an administration pov, the effort is limited.

E.g. 

the SN Platform example:

MID server --> application service = "SN MID Server - NY - PROD"

Change Management --> application service = "SN NY Change management"

ServiceNow --> application service = "SN NY PROD" / "SN NY QA" / "SN NY DEV"

When looking at these examples I am inclined to implement this approach where the application service is composed of its underlying (main) application, its version, and its environment.

Because this is a relatively new concepts, I am looking to the community to get some feedback on this thought process.

What do you think about the approach? Do you see any obstacles in the way?

The main driver why we want to do this is to have a clear and easy distinction (by name) of what type of service (technical, application, business) we are talking about 

Thanks for the feedback, 

Have a happy 2020 all!

[s4scott]

FWIW, depending on the size of your enterprise, I would advise using full names instead of acronyms. Acronyms can become very confusing and create issues for other ITSM users who aren't in the weeds with the data. Otherwise, you're naming example is largely representative of best practices: Name - InstanceName - Environment. 

If you have multiple instances, it can help to avoid using the version name/number above the Application Server/Application CI layer. If you have large service platforms there will be times when multiple different versions of applications exist within it. I.e. you are doing a ServiceNow upgrade and DEV is New York, while PROD and QA are still Madrid. I've run into situations where there are multiple non-Prod instances on different versions, as different parts of the company upgrade at different times. 

That said, always start with the simplest approach and add complexity as it is required. It's easier to grow than shrink.

Below is my interpretation of the current CSDM. At the top level, business application/service offering, the choice of CI depends on your organization's goals. It is possible to do both, but currently the data model requires different structures for each.

• Business Application -  You are headed down an Application Portfolio Management path
• Business Service Offering - You are headed down a Service Portfolio Management path

Mid Server ->(application CI) ServiceNow MidServer New York - PROD

Change Management -> (application service CI) SerivceNow Change Management - Northeast - PROD

ServiceNow -> (business application CI/business service offering CI) ServiceNow - Northeast

(edited: the business application/service offering CI would not usually be environment specific)