How To Design An Effective Naming Convention

While recording my VMware vSphere 5 Training course this past summer, I made mention that I developed a process for building an effective naming convention for enterprises. Server and desktop virtualization significantly increases the number of named objects within our enterprises, so an effective naming convention that describes what an object is, its location, function and purpose is critical. Doing so allows us to identify objects in a speedy way, but it also provides a structured way of searching for objects using keywords in a logical manner.

Even as I developed these guidelines, I did not think it would interest folks very much. But I started receiving near daily tweets and e-mails requesting a copy of the document. So, I've decided to publish it and share it with everyone in today's blog.

Here are my basic guidelines for the object naming convention:

• A name should identify the device's location and its purpose/function/service.
• A name should be simple yet still be meaningful to system administrators, system support, and operations.
• The standard needs to be consistent. Once set, the name should not change.
• Avoid special characters; only use alphanumeric characters.
• Avoid using numeric digits, except for the ending sequence number.
• Avoid the use of specific product or vendor names, as those can be subject to change. (There are some generally accepted exceptions: Oracle, SMS, SQL, CTX, VMW)

Here are some basic recommendations:

• The name should begin with a rigid header portion that identifies the location and optionally a type identifier. These should be followed by a delimiter to signify the end of the header portion. This delimiter shall be a "-" (dash) unless the system does not recognize a "-". In this case, substitute the dash for another suitable agreed-upon character (i.e. $ or #).
• Allow for a variable section that completes the identification (function, service, purpose, application).
• End the name with a unique ID, a sequence number, which can be multi-purpose.
• Allow for flexibility. Since technology is constantly evolving, this standard must also be able to evolve. When necessary, this standard can be modified to account for technological, infrastructure, and or business changes.
• There must be enforcement, along with accurate and current documentation for all devices.

Here is an example of the proposed naming convention standard:

Structure:

Header portion
GG -- Geographical location
L -- Location should be generic and not vendor- or building-specific to facilitate moves, building name changes due to mergers, acquisitions or dissolution of business, etc.
T -- Type
- -- Dash is a required delimiter to signify the end of the header portion

Variable portion:
AAA -- Function /Service/Purpose
BBB -- Application
(Unique ID)
## -- 2 digit sequence #

Values Defined:

Geographic:
CH -- Chicago
NY -- New York
LN -- London
SY -- Sydney
MA -- Madrid
SI -- Singapore
MU -- Mumbai

Location:
D -- Main Data Center
C -- COLO Data Center
T -- Test Area (should be used for test machines that are to permanently stay in the test area)

Type (optional):
V -- Virtual
C -- Cluster server
P -- Physical
O -- Outsourced or vendor supported system

Delimiter (required):
- A "-" (dash) will be used unless the system does not recognize a "-" at which point an agreed upon character can be substituted. This could be a $ or # or other character.

Variable portion - AAA
Identify the primary purpose of the device:

DC -- Domain Controller
FS -- File Server
PS -- Print Server
ORA -- Oracle database
SQL -- SQL database
DB -- other database(s)
EXH -- Microsoft Exchange
CTX -- Citrix Server
ESX -- VMware ESX Server

Variable portion BBB
Identify the Application on this server. If the server is for a specific application, then an application identifier should be the second part of this portion of the name, preceded by the service:

JDE -- JDEdwards
DYN -- Dyna
EPC -- Epic

This area of the name offers a lot of flexibility to handle identifiers for specific purposes, functions, and/or applications. There are many challenges to select identifiers that are meaningful and consistent and are not subject to frequent change. Here are some examples based on th guidelines I propose above:

CHD-DC01 -- Chicago Office, Data Center, Domain Controller, sequence # 1
CHD-FS01 -- Chicago Office, Data Center, File Server, sequence # 1
CHD-EXH01 -- Chicago Office, Data Center, Microsoft Exchange, sequence # 1
CHD-ESX01 -- Chicago Office, Data Center, VMware ESX Server, sequence # 1
CHC-CTXJDE01 -- Chicago Office, Data Center, Citrix Server,JDEdwards Application, sequence # 1
CHC-WEB01 -- Chicago Office, Data Center, Web Server, sequence # 1

Unique ID / sequence number
## This is a 2 digit sequence number

I would love to hear your comments on this naming convention and if you have ideas to improve it.

Posted by Elias Khnaser on 10/13/2011 at 12:49 PM