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

[s4scott]

I Agree with CMDB Whisperer. The convention we implemented add an instance identifier for business applications that are deployed regionally, or have multiple distinct instances: ProductName - Region/InstanceID - Environment

Something like: MyAppName - Far West - Prod

We also use multiple alias fields to allow the service desk to filter easily. But the name should be very simple. You should use the fields on the CI form to capture additional detail beyond what is required to identify the correct CI.

[CMDB Whisperer]

Agree that region/instance ID, or other addition may also be necessary, depending on the application.  If there is only a primary Dev/Test/Prod for an application service, however, adding the region it is located in could cause confusion, because it may be located in a specific region while serving users in multiple regions.  So it might make sense to include this data only when the applications themselves are regionally deployed.

[Stuart J]

We we thinking for SaaS  Business Applications naming the Application Service <Bus App> - SaaS.    ie don't expect to see Infrastructure here.     Is anyone else using this ?   Any thoughts ?

[CMDB Whisperer]

I get there are some philosophical differences here, but as a long time configuration manager mine has always been that we should not overload names with configuration information, and the name of a CI should contain precisely the information that helps a user identify the CI.  Any other details are extraneous and potentially problematic.  One thing to consider is what the purpose of your naming convention is.  Generally, the most important reason for a naming convention is so that CIs can be easily and reliably identified.  Does adding "SaaS" to the end of the name help to identify the CI?  If not, then it may be better to surface this information via the relationship to the Business Application which will tell you what kind of Application it is, and then possibly cascade that information down to the Application Service if you want it to be more visible, such as displaying it in a column next to the CI name when selecting the CI from a drop-down, for example.

Everyone will make their own decisions about naming conventions, but those are my thoughts. 

[Alan Prochaska]

CMDB Whisperer, I agree.  A key fact in "so that the CIs are easily recognizable" is "by whom?"  It's "by human users."  Systems and integrations can get all the information they desire from metadata, but human users are accustomed to looking at just the CI name and discerning all the information we want.  That expectation may be higher than reasonable. 

Those of blessed with memories of system management in the 80s and 90s can recall the enthusiastic system admin showing us the 15-part naming convention of servers, mostly all consonants with a 2 page job aid to decode the names.  Over time, the admin was usually the only one still enthusiastic.