Site Naming Standards: Turn a constraint into an Enterprise enabler.
From small to large business, a standardized site naming convention is an Enterprise asset with significant value that reaches throughout the Enterprise.
Where is the value?
From a network organization perspective, we've all seen the typical issues that could have been avoided if a site naming standard had been adopted. Devices shipped to the wrong locations, stakeholder confusion during all aspects of the service life-cycle, field techs showing up at the wrong locations, service requests & incident tickets opened for the wrong site, etc. etc.
These problems have quantifiable costs, including project budget/schedule overruns, incident management issues and request fulfillment delays.
Then consider the fact that these issues are duplicated across all your IT service towers and lines-of-business, with the costs duplicated not only within each but also compounded when these organizations interface with each other.
On top of that, there are additional "hidden" costs, as other Enterprise naming conventions may have dependencies on site naming standards. Therefore, without a site naming standard, any dependent naming standard will be impacted, causing further issues.
Recommendations & Considerations
A site naming standard should be applied regardless of business size, the value-add will increase exponentially with size, and the key is to start early.
All business are unique, there's no ones-size fits all standard, but here are a few guidelines from my experience.
A typical site naming convention includes a number of identifiers followed by an extension, the components and format of which is entirely up to you. I've seen town, city, country and even airport codes. Try and keep the length short and avoid any punctuation (I.E. periods or hyphens). This will allow easier integration into any dependent standards and avoid issues with dependent technologies (anyone remember the constraints for WINS & DNS names?).
Consider you site volume today, target geographic and business strategy. Are you regional, national or global? Do you need a town, city or country identifier? Will you have multiple sites in the same city or town, and how will your extension handle those?
The human element. To gain the most value from your site naming standard you need adoption (and therefore agreement) across the whole enterprise. This is actually where things get really tricky, not every stakeholder will "like" your standard, many stakeholders will have an opinion on how it "should" be done, and some simply on how it "should not" be done. It's interesting to see the office politics play out as one line of business challenges another for the coveted "NYC001" site name.
The trick here is to identify the most influential stakeholders (usually, but not always, the executives), work an acceptable standard with them and then drive that downstream. This review and approval process can be a real challenge, I know because I've done it.
Examples
Here's an example I've used in the past, feel free to use it as a base for your own site naming convention.
Standard = XXXZZZ, where;
XXX= City, Town or Borough code.
ZZZ= Extender.
For example: