IT Operating Environments Best Practices - Map all custom and local environment names to the standard enterprise taxonomy
IT Operating Environments Best Practices
Map all custom and local environment names to the standard enterprise taxonomy
Overview
Organizations with complex delivery programs frequently develop custom environment naming to address specific needs that the standard taxonomy does not distinguish between. A team running parallel integration testing streams may name their environments SIT1 and SIT2. A team supporting multiple user acceptance testing populations may name their environments UAT-NORTH and UAT-SOUTH, or UAT-BUSINESS and UAT-IT. These custom names are operationally useful and should not be prohibited - they reflect real organizational and delivery complexity. The problem arises when custom environment names exist without an explicit mapping to the standard enterprise taxonomy, making it impossible to aggregate environment data across teams or to apply taxonomy-level governance policies consistently.
Best Practice
Require that every custom or locally-defined environment name be explicitly mapped to its corresponding standard enterprise taxonomy category, and maintain this mapping in the Environments Inventory as a standard attribute of every environment record. SIT1 and SIT2 map to SIT. UAT-NORTH and UAT-SOUTH both map to UAT. ENV-PERF (a performance testing environment used by some teams) maps to whichever standard taxonomy category most closely describes its purpose and position in the delivery pipeline. The mapping must be explicit and documented - it should not be inferred or assumed. Require teams to declare the taxonomy mapping when a new custom environment is created, as part of the environment creation governance process.
Where custom environment names reflect genuine delivery complexity that the standard taxonomy does not adequately distinguish, consider whether the taxonomy itself should be extended to recognize the additional distinction as a standard variant rather than leaving it as a team-specific convention that cannot be governed centrally.
Benefit(s)
Mapping all custom environment names to the standard taxonomy enables enterprise-level environment reporting and governance that encompasses the full diversity of the organization’s actual environment landscape rather than only the subset that uses standard names. Governance policies stated at the taxonomy level - such as the prohibition on Production data in lower environments - apply unambiguously to SIT1, SIT2, UAT-NORTH, UAT-SOUTH, and every other custom variant because their taxonomy mapping makes their position in the lower/upper hierarchy explicit. The Environments Inventory remains coherent and analyzable even in organizations with high delivery complexity and diverse naming conventions.
Another advantage of such mappings is that it becomes easier to generate executive-level and operational reports and dashboards. For example, if custom environments like System-X_PROD and System_Y_PROD are both mapped to the more generic PROD, it becomes easier to represent them through categorization or even as a taxonomy that allows a user to “drill into” PROD and find all custom environments associated with it that are of Production grade and require Production policies and compliance.
Copyright for the International Foundation for Information Technology (IF4IT): 2008 - Present
Legal Disclaimers