CSDM - App Service

[averma1]

Hi, I am working in a project where we need to define app service from the scratch and was wondering if we should use a specific Naming convention for the better use something like below 

Technology / Service - Operational Function- Environment (Prod, Dev, QA, Staging)

for ex Business App is Microsoft Email Exchange so app service name should be 

Exchange Online Email Service - Prod

or is it ok to name Microsoft Exchange Online - Prod ?
Please recommend best practice 

[mikesisson · Accepted solution]

Thanks for posting this.  Naming certainly matters and what is important is to think about where the name will show up us well.  Its not just in a table list...  The reason this matters also is that the Business App or Digital System is often comprised, or will be as you mature, of multiple App Service/Service Instances.  Depending on where you are gaining your first value from a process integration perspective is often where you will recognize this need.  Lets consider an incident and the progressive use of the Service Instance:

1. At the incident from a human - What do they think in terms of CSDM Objects most often? - Business Service Offerings.  What does a Business Service Offering depend on - Service Instance (Does the naming of that Service Instance make sense to the L1 Support of that Business Service Offering?)
2. If that Business Service offering is only dependent on a single Service Instance... The naming of the Service Instance doesn't really add value.  The service and L2 Support is straight forward and you have your escalation handed to you on a silver platter...
3. However - Depending on your setup the model allows for an offering to be dependent on multiple Service Instances - This is where the naming brings value for the L1 support to make a call on being able to engage a single L2 Support derived from the Tech Service of that Service instance or from the direct Support Group on that Service Instance.
4. The incident form itself can limit that choice to those dependent service instances.  This is where your question and ultimate answer comes to your seat at a strategic and that it "makes walkin' around sense".  This requires you to act like the L1 depending on your naming convention strategy and your desire to make that choice as easy, or as automated as possible.

So the answer...depends on the view of the game.  The best practice is the one that works for the processes depending on it.

If you want to carry the name of the Digital System/Business App into your App Service and then environment, I can see that making sense and that is the path I am also going down based on our Enterprise maturity and ways of working, especially since we are modeling multiple Service Instances that roll up to the business app and are finding at this stage that our Business Service Offerings are at times depending on multiple service instances to be consumed.

Just make sure it makes sense to the folks that are being presented with the choice of plucking the Service Instance.  The best practice is the one that works for your org without completely breaking the model.  The model will bend and your naming convention will not break it.  Go with it and revisit and iterate based on the feedback from the process owners.

I'm right there on a parallel path with your journey - Interested in the feedback you get, just don't get stuck.... Be Bold.  Document the naming convention requirements for Gov and build - You can always iterate.

Mike