Naming Convention

Overview

Namespaces and naming conventions are a crucial part of EA(Enterprise Architecture). They allow for streamling more than just operations (albeit optimising for operations is a key goal). Conventions allow for clear and unambiguous management of logical or physical assets throughout an organization. Rather than deep dive in to namespaces, ontologies and taxonomies, there is a need for objects and their roles to be well defined, well structured, and labelled. Oftentimes an object’s expected lifetime or temporal nature influences how it will be managed. The goals of each organisational unit with respect to why and how they are identifying and naming things may differ. Whether asset tracking, troubleshooting, or describing an object and its role, there are multiple approaches and methods of encoding or surfacing characteristics quickly via their label.

Typically over the course and evolution of an organisation, the culture and thinking evolves and changes yet the assets under management (and respective linked workflows) change less often. Each team with responsiblity for managing different physical and virtual assets may have differing opinions or requirements for their respective domains, however certain default characteristsics and requirements persist across most enterprises. To allow for a naming convention that embraces all teams and organisational units (and one which does not result in years of discussion), it has been found that a mixed convention of mandatory initial characters (which entails site codes and operational/responsibility designations), and then team specific patterns ultimately satisfies the most constraints.

Asset Definition

The objects in question may represent devices, components, or other logical assets (such as virtual interfaces, virtual devices, network prefixes, even VLANs etc.).

Constraints

• Teams shall adhere to the global prefix when naming things (but have discretion after their team code)
• Sites shall not use airport codes. Cities may have multiple airports, no airport etc. This has profound consequences for efficiency, automation, and operational/design reasons.
• Fixed width schema. This is important for automation and policy application, recognition (and other forms of pattern matching).
• Fixed number of delimiters must be used in the global prefix. This is important for automation and policy application, recognition (and other forms of pattern matching which include human readability).
• Virtual devices or component which is reliant upon 2 or more underlying physically managed components of the same local system e.g. logical firewall contexts, clustered network elements, clustered servers.
• There must be an authoritative list of site codes used across facilities, HR, finance, and IT (especially for larger or expensive assets > $1000 USD)
• Mobile assets, if constrained by country, can use a country wide site code. If the asset may move globally, then a global or roaming site code may be used.
• Every name must be configured and written in lower case and one should always avoid lower‘l/L’s, ‘i/I’s, and ‘o/O’ which can be misunderstood.
• Dashes (hyphens) must be used to separate labels in to fixed width machine parseable variables
• Dots should separate zones, groups, and tiers which are then compatible with DNS ()RFC 1034 https://tools.ietf.org/html/rfc1034#section-3.1 )
• For policy based namespaces (and automation of all types including of course inheritance) the gTLDs, regions, and/or zones should be used when naming policies if applicable to said sites or regions.

Also the namespace for assets must conform across facilities, finance, HR, and engineering especially for large/expensive/important assets. Essentially things are named with schemas that relate to their temporal nature i.e. how long they last (in a general location or state) and when/how often they are updated, changed, replaced, upgraded etc.

It is well known that from a network and systems context, an object’s exact location should be defined by external systems (including but not limited to tags and SNMP fields) with the one caveat that site or country codes can be encoded in to the object or optionally the domain portion of the name ‘label’ to facilitate routing, organisational boundaries, and governance. The concept of temporality (time/longevity/ephemerality) of an object and it’s characteristics or role/function also plays heavily in to the schema. The element in question, and its respective label, should optimise for permanence in asset records (thus minimizing administrative overheads throughout the lifetime of an object, system, or component!).

Goals of Asset/Resource Records

• permanence as it relates to the lifetime (temporal nature) of the asset
• to minimise administration overheads throughout the lifetime of the asset (i.e. optimise for operations)
• to facilitate role and object identification
• to expedite and enhance fault finding (troubleshooting)
• consistency in terms of dependency of higher/lower order dependent services/functions
• consistency in trending and reporting functions

Naming conventions are crucial for lifecycle management and to ensure efficient administration. Accurate management and monitoring is one of the most immediate and obvious requirements. Additionally, one can not afford to be renaming objects constantly in documentation, DNS, or monitoring, asset management, and change management platforms. Also, as staff are onboarded, rotated, or cycle due to attrition), it’s extremely important that managed objects are unambiguously named.

Format

• Mandatory Prefix (6 character): <site[3]instance[1]><-[1]><team[1]> where the primary delimiter is hyphen -
  • the first character of the site code denotes the site governance/administration domain i.e. for company Bob running their own data centers but also leasing/renting co-located data centers from Equinix, and using IaaS(Infrastructure as a Service) from Amazon:
  • adn1 : a = amazon, dn = London, 1 = first
  • bpr2 : b = bob company, pr = Paris, 2 = second
  • esf3 : e = equinix, sf = San Francisco, 3 = third
• Discretionary Suffix (8+ character) <function[2]><instance[5]><sub_instance[1]> (E.g. where team=> n= network, s= systems, v= voice…)
• the pattern after the site code and team code may be decided upon for each team if so desired however the first 6 characters must adhere to the convention.
• A sub instance might be where 00001a is the primary physical, 00001b is the secondary physical, and 00001v is the virtual (if applicable).

** Note_I ** hostnames/labels must be fixed width for certain platforms i.e. a 14 char max for the host portion as an AWS limit.

A FQDN(Fully Qualified Domain Name) example would be adn1-nfw00001a.infra.domain.net and should include subsequent interface mappings for both A and PTR records. Another example might be adn1-nfw01a-g1-1.infra.domain.net or adn1-nfw01a-t2-11.infra.domain.net whereupon the network team has elected to encode interfaces in to the name (akin to many ISPs).

** Note_II ** Exact floor, room, or physical distribution, or X,Y location should never be hardcoded in to the name as the logical representation must stay in monitoring (and it outlasts all local physical moves, adds, and changes) whilst allowing for simple DNS changes whilst moving equipment inside a building or campus. Site level or country level is the only encoding to be used in a name and all other location details should be encoded in SNMP location or other asset management fields/tags (and to some degree in the subzone if required).