How to name an Application Service?

[Alan Prochaska]

How do you all name your Application Service CIs?  

Do you have a naming standard that works?  

Anyone care to share or hold forth?

In our young implementation, Application Services primarily represent deployments of the application.  Someone decided to name the App Services "<bus app name> + <deployment type> + <version>".  This leads to long and clunky names.  For analytic or machine access it's easier to get deployment type and version from metadata, however, humans get confused and frustrated having multiple objects in the same class with the same name (distinguished by other meta data).

What do all of you do?  How do you name your app services?  And does it work effectively?

Thanks for feedback, thoughts, and stories.

Alan Prochaska

Kaiser Permanente

[CMDB Whisperer]

100% agree.  The reasons for this were that many configuration systems (and IT infrastructure itself) were relatively simplistic.  There just wasn't a lot of metadata available.  The systems didn't provide the rich metadata back then that they do today.  So people would create elaborate, detailed, and ultimately cryptic naming conventions for their infrastructure to compensate for the lack of metadata options available, with abbreviations and coding that you had to look up to understand because there weren't that many characters available.  And in some cases, inevitably, they were faced with the fact that they included data in a naming convention that was subject to change!  So either you had to rename the object based on the data that changed, or you had to live with the fact that its name no longer reflected accurately the intent of the naming convention. 

It's all just ugly.  Yet we still find this living on today in practice, even when our systems offer rich metadata models.  Some things are just hard to kill.  That said, there is still a place for naming conventions.  I'm not against them, per se.  If server or network operators are getting a list of devices back from a monitoring tool, they may not be getting a rich data set, but have to go with the host name, and thus it makes sense for the host name to identify some important characteristics -- what the business unit or customer is, whether it is Dev/Test/Prod, what tier of the application stack it uses, and which node member of a cluster it is, possibly even the hardware manufacturer.  All very common, and perfectly fine at the infrastructure level.  But at the business layer and the logical layer we want things to be user friendly so that we get users enrolled and participating in the process!  

[matt barrett1]

We have four fields fields to classify the services, name and then use a calculated field, we have "used by" for part of the impacted org, "technical family" how we group similar services, the name, and environment type.

We have changed the name to be a calculated field of these four fields, however i'm wondering if it would be better if servicenow have a "display name" field for CIs, so the name could be something like Jira, but display name could be the different org deployment of Jira and the environment.

This has the same principle of display name on infrastructure, whereby server hostname of each environment type is the same, but the display name is shows the FQDN.

uniqueness for any class by default could the name + display name, and visible on all forms.

[Jim Zeigler1]

This is what I recommend:

[Nilanjan1]

Hello @Alan Prochaska , 

I generally agree with all the inputs that are provided by the experts. However, the naming convention should be based on the type of services that you are trying to maintain & the naming convention is very dynamic. 

For Application Services we have used : <App Service name> + Location + Env. 

TSO again it is very dynamic for e.g. network services - We have used the <support group - Location Name > 

Technical Service - < Name > Like desktop Services OR network services etc. 

The more simple the better ! 

Regards

Nilanjan

[PG2]

The naming conventions we've adopted follow a similar approach:

• Application Service Name = Business Application Name + an optional identifier to describe the instance.

We've also gone further and defined naming conventions for the Technical Service & Service Offerings containing the Application Services.

• Technical Service Name = Business Application Name + an optional identifier to describe the provider.
• Technical Service Offering Name = Technical Service Name + optional identifier to describe the service stratification.

For example (a simple application owned by a single provider, with unique support SLAs for its prod/non prod instances):

Business Application: MyFirstApp

Technical Service	Technical Service Offerings	Application Services
MyFirstApp	MyFirstApp Prod	MyFirstApp - Production
	MyFirstApp NonProd	MyFirstApp - Test MyFirstApp - Development

The above translates into the following benefits: 

• Clear, consistent and well-defined services.
• Alignment with CSDM (and its definitions).
• Easy to consume & replicate.
• Simplifies governance and management.
• Enables service onboarding/offboarding automation

Some say the above is too much of an application-centric approach to service modelling. I would love to get the thoughts & opinions of some on this post.