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

[Cassandra Kittl]

I'm going to say something scandalous: we don't have a complete non prod infrastructure so there hasn't been a reference establish for the non/sub prod environments: the MAS applications aren't exposed to the end user community, mainly inner department so it helps mainly in the set up of relationships for CSDM/CMDB and when selecting a Configuration Item. Our implementation of CMDB is in its infancy as well.

[Mark Bodman]

You aren't alone in not covering non-prod environment.  I will say that in my experience, the cost of maintaining non-prod has been hidden or unaccounted for when you don't cover it, or you lump in non-prod with prod infrastructure under one Application Service, having operations treat the non-prod requests the same as prod, not a good thing.  

In one case, I found that an organization had 38 non-prod environment that were being maintained in the cloud, many developers had long since left the organization.  Once they established the Application Services for each instance, they identified this as a huge cost savings opportunity that in this one instance, covered the cost of capturing non-prod for the entire company.   

[CMDB Whisperer]

Makes sense.  Deciding to focus on Production in the initial phases is a potentially wise decision and not uncommon.  However, in the long run, keep in mind that you will want to expose the Application Service to your end users as it is generally the prime focus for reporting incidents against an "application" that they are using, and that eventually you will also probably want to understand the use of all of your infrastructure assets, and that means your non-production assets as well, which means you will want to be tracking the Environments that they are part of and probably the application services as well.  Sometimes it is still important to have SLA and OLA for our non-production environments, as they still do have business value that is important even if only indirectly as a Technical Service dependency.  That said, the MAS (mapped application service) prefix I'm guessing was there to just set them aside from other services in a drop-down list or otherwise make them easier to identify by humans, in which case there are probably other ways to do that which will provide you more value in the long run.  Just some food for thought as you continue your CMDB journey.

[Mark Bodman]

From a naming and organizational perspective, the more you can place in the name to make sure you are unique and distinct, the better.  We have discussed internally creating the name automatically, based on the context of references (business application name) intended scope of use (what you would find in the offering subscribers) and environment.  

Many of our customer are starting to leverage our API's to create them in their CI/CD pipeline, so coming up with a consistent approach that is automated can be done through automation too. 

I wrote this APM article a long time ago that provides guidance similar to what folks have already stated below.  The images in the article were botched when we changed our community software, the explanations should be helpful still.  https://www.servicenow.com/community/apm-forum/application-portfolio-management-inventory-best-pract...

[Alan Prochaska]

Thanks, Mark.

Lots of helpful thoughts in the referenced article, even though it's from 2017 and Madrid/New York.

The consensus approach seems to be <app name> - <environment> - <other context>, where other context could be geographical location or some other distinguishing parameter.

Thanks for all the feedback, everyone!