Identifiers in systems infrastructure and their consequence in software systems is something that cannot be overstated. One disorganized engineer erroneously ignoring naming conventions can be the difference between a clean, unified and organized system, or spaghetti.
To that end, I have reflected on the importance of naming conventions over the years and their structure within the organizations that use them. Naming Conventions as a component of systems and software documentation save organizations tremendous amounts of time when deployed correctly. Here are some conclusions I’ve come to over the years about the nature of naming conventions:
One Organization, Many Brands
As the business space evolves to favor speed, an increasingly common phenomenon has occurred within the corporate zeitgeist: a single parent organization that owns many brands. Gone are the days when an organization could deliver a niche product (unless they own that niche), expansion rules the era and that means product/brand diversity.
This diversity of brand offerings results in increased infrastructural complexity inside of networking environments. You had a group of 55 machines connected to a Domain Controller? Now you have 100 more? How do you manage specific policies for machine 56 to machine 155? Simply using the next number, frequently will not do.
Simple Example:
A decent endpoint naming structure is simple, and concise. one may first specify devices by the name of the parent company or the brand itself, and then an office (or remote device) identifier to determine place, and finally a serialized number to determine position. A department identifier can be used as well for larger ecosystems. What does this look like?
EXAMPLECORP-SF-01
BAGELCOMP-MH-01
This is a valid and easily readable hostname naming convention, as you can see the name of the company and brand is easily understood, and for a fictional office like “Springfield”, we know it is the first endpoint workstation within the network. This can be expanded upon as needed, but the important things are as follows:
- It’s expandable: This is key for any naming convention. You need to anticipate growth within your naming convention. This is to avoid a situation in which you grow beyond the confines of your convention.
- It’s simple: I am not a fan long jumbled monowords, I like to use dashes to separate ideas and purpose within the naming convention where it is able to be done (as is the case, with hostnames, for example)
- It can be understood by non-technical users: This is an expansion of point #2, but can your end users understand your naming convention? If you are the only person who can instantly understand your naming convention, it’s likely overcomplicated (unless you are in a massive ecosystem)
The Chain’s Weakest Link: Documentation
So you built a strong Naming Convention for your organization. Everything is wonderfully designed on a Mcdonald’s Napkin (or worse, remembered). The thing about Conventions, is they must be used Conventionally. To that end, it is key that you document your newfound system as much as possible. A little bit of Markdown does wonders for keeping everything organized. Make sure to keep it as close to your engineering infrastructure as possible. I like Git for this.
People will ignore your conventions. They will connect random printers to your network that broadcast HP123blahblahblah as a device hostname. They will do silly things with laptops to get around blocks and group policies. That’s why you need to make sure your Documentation is well structured, and ran up every chain of command possible. Everyone, including non technical users should understand it, and its importance to the smooth operations of the organization, large or small.
Are you a one man IT guy for a small organization? go talk to the owner, tell them what it is and why it matters. Are you the C-suite or Tech Director of a massive Enterprise? Talk to your engineers in a group, get feedback, and decide what works best for the idiosyncrasies of your use case specifically.