Enterprise Tag Standard

Standard
This HUIT standard presents a discussion and implementation guide for incorporating enterprise level meta-data on IT resources and infrastructure.
 
enterprise_tag_standard_1.3.pdf501 KB
Authors
  • Raoul Sevier (Enterprise Architecture)
Version 1.3
Last Revised 21-Apr-2021
Status Released
Document Type Single Topic Guidance
Audience Level
  • IT Director / Manager
  • Solution Architect and Project Manager
  • Application Developer and Designer
  • DevOps Staff
  • Senior IT Engineers
  1. Problem Statement

    Effective management of IT resources requires that various attributes describing the resources be available for cost allocation, cost optimization, reporting, compliance, and security purposes. These attributes must be consistently defined and available across organizational boundaries.

    The general concept of tagging resources applies to cloud and on-premise infrastructure in the server, network, storage and application domains. Cloud based computing environments offer standard tagging mechanisms, but nomenclatures and availability vary by vendor.

    The lack of a consistent set of enterprise level meta-data on IT resources across domains and organizational boundaries currently limits HUIT’s ability to address the above requirements.

  2. Recommendations

    • Define a limited set of tags to be ‘Enterprise’ in scope and specify the naming, meaning and allowed content of the tags
    • Identify a group with the responsibility to maintain and evolve the set of enterprise tags and approve exceptions as appropriate
    • Implement automated mapping or translation processes if needed to convert tags from existing domain systems to the enterprise specification
    • Require all HUIT teams to maintain accurate inventories of IT resources and their appropriate Enterprise tags, in the central Configuration Management Database (CMDB).
    • Encourage all HUIT IT teams to provide the CMDB with additional information about resources which may be deemed important, but without the constraint of consistent naming or value formats.
    • Inform Harvard School IT partners of HUIT’s enterprise tagging policies and processes and use the Cloud Community of Practice to begin an effort to align tagging efforts across the University.
  3. Discussion

    1. The role of Tags in HUIT

      HUIT, like many IT organizations, is largely organized by IT technical domains. Platform and server teams manage compute resources, network organizations own and operate switches and access points, backup teams manage the resources necessary to store and protect data.

      Each organization’s management of the technologies under their purview is augmented by the use of meta data or tags which hold attribute information about the resources they manage. Examples of tag information include the environment (development, stage, production), owner, cost center as well as technical data.

      Many of the systems, although robust, expect users to conform to specific design and usage conventions limiting their cross-domain value. Differences in the implementation and design of these individual tagging systems currently limit their use in answering broad cross organization questions around usage, cost, dependencies and security. For example, the AWS platform team may use a tag named ‘Environment’ with a value of ‘Production’, while the Azure team may use a tag named ‘State’ with a value of ‘P-1’.

      When IT management review IT resources across different organizations and technical domains, they are faced with inconsistent tag usage. This presents itself both in the names of the tags used by different tools and organizations, as well as the allowed formats and values in those tags. These inconsistencies make aggregate reporting and analysis very difficult.

    2. Standardization of Selected Tags for Enterprise use

      Requiring adherence to a single monolithic tagging nomenclature is inadvisable. Many of the existing individual systems have developed over time, provide specific domain functionality and cannot be easily changed. Much of the information about IT resources in a technical domain is important, if not essential, to the successful management of the resources by the operators of the domain. For example, AWS administrators need to know the configuration of elastic load-balancers, which style of RDS database is used by a application, and if the virtual server is used for production operation. These systems provide significant value and should continue to operate. Nevertheless, there is a clear need for a relatively small number of tags to be ‘Enterprise’ in scope, with consistent naming conventions, standard content and meaning.

      The primary tool for managing IT service-related data in an ITSM environment is the Configuration Management Data Base (CMDB). The existing ServiceNow based CMDB is the logical container for managing the meta-data held in enterprise level tags as well additional information about resources which may be deemed important but does not require consistent naming or value formats.

    3. Standardization of Selected Tags for Enterprise use

      Requiring adherence to a single monolithic tagging nomenclature is inadvisable. Many of the existing individual systems have developed over time, provide specific domain functionality and cannot be easily changed. Much of the information about IT resources in a technical domain is important, if not essential, to the successful management of the resources by the operators of the domain. For example, AWS administrators need to know the configuration of elastic load-balancers, which style of RDS database is used by a application, and if the virtual server is used for production operation. These systems provide significant value and should continue to operate. Nevertheless, there is a clear need for a relatively small number of tags to be ‘Enterprise’ in scope, with consistent naming conventions, standard content and meaning.

      The primary tool for managing IT service-related data in an ITSM environment is the Configuration Management Data Base (CMDB). The existing ServiceNow based CMDB is the logical container for managing the meta-data held in enterprise level tags as well additional information about resources which may be deemed important but does not require consistent naming or value formats.

    4. Criteria for Enterprise Tags

      From an enterprise management perspective, the non-technical and/or operational attributes of a resource are often the focus of interest.

      Criteria for selecting Enterprise Tags may include:

      • Data necessary to understand:
        • Usage
        • State
        • Ownership
        • Cost Allocation
        • Service and Applications support by resource
      • Attribute information that supports operational requirements such as backups and patching
      • Attribute information that describes and supports automated resource creation and

      These criteria, and others, should be considered when determining the need for an Enterprise Tag. As a practical matter, this process will start organically and stabilize over time.

    5. Criteria for Enterprise Tags

      The names and values of tags within each existing resource domain may, or may not, currently conform to the naming of the attribute in the Enterprise CMDB, nor may the values align to the standard created for enterprise level tags.

      Whenever possible, existing tags nomenclatures should be aligned to the standard for enterprise level tags in order to minimize the number of variant names and values of the same attribute across different technical domains. However, as discussed above, this may not always be practical. In these cases, an automated translation or mapping process can be implemented in order to convert the existing local meta-data into the enterprise tag form and content.

    6. Propagation of Tag Information to the Enterprise CMDB

      Where enterprise management identifies attributes in local resource domains that must be propagated to the Enterprise CMDB, it is up to the organization owning the resource domain to craft a means of providing the required information.

      The HUIT organization has procured several tools, such as CloudAware and LogicMonitor, that do resource discovery by looking into platforms, such as AWS and VMWare, and identifying IT resources. This information is aggregated into the tool’s internal database. This is a convenient way of acquiring information about resources. Further these tools often have pre-built connectors that populate Configuration Management tools such as ServiceNow’s CMDB.

      When using tools such as these, it is up to the local resource domain team to ensure the Enterprise Tags and values conform to the Enterprise Tag standard as the information is moved to the CMDB.

      In other situations, there may not be an existing tool that can provide discovery or propagation to a CMDB. In these cases, custom procedures or code may be needed to provision the CMDB with the requisite information.

    7. Use of Automation for Effectiveness and Efficiency

      A central goal of the Enterprise Tag Standard process is the use of automation to the greatest degree possible.

      In principle, tagging of IT resources should take place at the time the resource is created. In the case of resources that are created by Ansible Tower or by SCCM, the scripts used to create the resources should contain the directives that create the tags in the appropriate platforms. For example, an Ansible script to create an AWS virtual machine should also create the tags that identify the server as a production machine using the correct Enterprise Tag name and value.

      Where automated resource management is not available, in principle the tag names and values should be defined as early in the life-cycle as possible, and only once.

    8. Mandatory vs. Optional Enterprise Tags

      Given the great variety of resource domains, it is a given that not all IT resources will be able to support all Enterprise Tags.

      It is up to the organization managing the local resource domain and the team responsible for enterprise tag management to agree which tags will be required for each domain. Once agreed, then the resource domain must provide the agreed tag information in the standard name with standard values.

    9. Tagging Practices at Harvard

      While initially scoped to the HUIT organizations, HUIT routinely manages IT resources belonging to Schools and other organizations. As a practical matter, any IT resources that fall under the management of HUIT organizations must conform to the tagging standard. As HUIT interacts with Schools and other organizations, they must inform them of this approach and take steps to ensure that School and other organization resource information makes its way to the Enterprise CMDB.

      The Cloud Community of Practice can be used as an initial vehicle for discussion of and alignment of enterprise tags with HUIT’s University partners.

  4. Updates, Exceptions, and Waivers

    IT environments undergo continuous change. As a practical matter, it is important to manage that changes with as much automation as possible to maximize both effectiveness and efficiency of IT operations. This means updating the standards as the mix of resources change. Just as important as knowing what a resource should be tagged, is a sense of where exceptions are important, and an inventory of waivers to the standards with the reasons the waivers were given.

    1. Updates to these Standards

      The responsibility for tasks related to maintaining and updating enterprise tags should be clearly defined. Should the scope of change be large enough, an additional round of peer and management review may be required. This material and updates will be cross-published on the EA web site and in the HUIT TPS Confluence wiki site.

    2. Waivers and Exceptions from these Standards

      There may be some circumstances where standards have not yet been defined for a class of resource. Under these circumstances a waiver for that class can be allowed, as long as there is management concurrence. This becomes the basis for updating the standards document. The responsible organization must keep a log of waivers.

      In the event there is an applicable name or tag standard for a resource, but there are compelling reasons to deviate from them, exceptions may be granted. Under these circumstances, the responsible organization must grant the exception in writing. The responsible organization must keep a log of exceptions.

  5. Standard Enterprise Tag Names

    The list of Standard Enterprise Tags identified in this document represents that essential set of information that management needs to conduct cross-organizational and cross-technical domain management.

    This list is simplified for presentation purposes. A complete table with additional descriptive material can be found in the side-car Excel spreadsheet for this document.

    1. Enterprise Tag List

      The following table describes tags that must be used in a consistent fashion across IT organizations and technical domains.

      Enterprise Tag Name Purpose Content Amendments
      AD Domain Used to relate resource AD domain, and manage the use of Active Directory to control access and permissions. One of:
      • fas
      • uni
       
      Automated Build Enabled
      CMDB name: automation_bootstrapped
      Indicates that server has been configured to receive automation from Ansible Tower or SCCM. One of:
      • successful ssh connection
      • ssh unreachable
      • generic ssh failure
      • incorrect ssh key
      • unknown
      • windows host
       
      Backup Policy
      CMDB name: backup_policy
      Indicates the backup policy in effect for the resource. Applies primarily to resource type of server. One of:
      • No Policy
      • No backup needed
      • Daily incremental, monthly full
      • Daily incremental only
      • Monthly full only
       
      Created By
      CMDB name: created_by
      Denotes the Ansible Tower ID used to create Stackbuilder resources, or the SCCM ID. One of:
      • <AnsibleTower username>
      • <SCCM username>
       
      Criticality
      CMDB name: criticality
      Used to identify the criticality of the resource, typically thought of in terms of availability, but can accommodate other criteria. One of:
      • Foundational/Life Safety
      • Mission Critical
      • Critical
      • Important
      • Non-Critical
       
      Data Classification
      CMDB name: data_class
      Denotes the maximum level of sensitivity of data contained or managed by the resource. This usually applies to servers and databases. One of:
      • L1
      • L2
      • L3
      • L4
       
      Environment
      CMDB name: environment
      Used to indicate the operating level of a resource. Production indicates the resource is configured to full standards and policies for operational use by the intended users. Non-production indicates a (generic) lower-level environment that is less exposed, and may use lower standards and policies for operation. Other values provide a finer-grained indication of operating level. The remaining tags highlight the traditional stages of promotion towards Production. One of:
      • Production
      • Non-production
      • Stage
      • Test
      • Development
      • Sandbox
       
      Exceptions
      CMDB name: exception
      This tag indicates that there is a quality about the resource that is non-conformant. The content of the tag is the compliance date that was given when the exception was granted. One of:
      • No tag on resources that are compliant
      • For resources that are non-compliant, a value of the compliance date as text in the format of YYYYMM to allow collation. In the case of multiple exceptions, the earliest compliance date must be used
       
      Hosted By
      CMDB name: hosted_by
      Used to indicate the support group that is responsible for providing tier-2 level support and beyond. One of:
      • DevOps-APT12
      • DevOps-APT3
      • DevOps
      • IAM
      • Library
      • (other values to follow)
      Defer: Add 2+ character school IDs as well as unit names such as NOC, IAM, LTS
      HUIT Asset ID
      CMDB name: huit_assetid
      Used to associate resources with administrative codes. This enables ICAPS to divide up a single account among multiple billing codes. <Asset ID number assigned by ICAPS> Defer: Modify ICAPS ownership to 'Finance', assert only one asset ID per resource
      Resource Name
      CMDB name: name
      Used for people to identify the resource. The tag value should be configured to present the essence of the resource’s identity, perhaps by concatenating several attributes. When a friendly name is not possible, the value should reflect the resource unique identifier. One of:
      • <A friendly name for a given resource that helps with readability>
      • <A technical identifier from the technical domain that operates the resource>
      Defer: Anna to review 'name' or 'Name' usage in CMDB for resource type 'EC2'
      Resource Type
      CMDB name: resource_type
      Used to indicate the type of the resource.

      This is intended to simplify the selection of resources in the CMDB and allow efficient and effective reporting and analytics.
      One of:
      • Applicance
      • Controller
      • Database
      • Firewall
      • Load_Balancer
      • Proxy
      • Router
      • Security_devices
      • Switch
      • Virtual_Guest
       
      Server Platform
      CMDB name: platform
      Used to distinguish between the major operating system types and enable better visibility within configuration management.

      This is primarily used with server resources.
      One of:
      • linux
      • windows
      Defer: Consider 'Other', 'Appliance', ??
    2. Enterprise Tags Pending Implementation

      The following table describes tags that will become Enterprise Tags once an implementation plan is completed.

      Enterprise Tag Name Purpose Content
      Product ID
      CMDB name: product_id
      Used to associate a set of application configurable items (CI) with a business product. The primary use-case is where a business product consists of multiple application components which may use a variety of resources such as servers, databases, and middleware components such as IAM.

      The process of defining business application inventories is being developed by the CMDB Workgroup. Relating these applications to components (in the style of a bills-of-material) is also being defined in the CMDB.
      Multi-valued list separated by commas, using values <Encoded by CMDB>

      Examples could include: GMAS
      Application CI ID
      CMDB name: app_ci_id
      Associates an IT resource with a component of an application.
      The process for creation application IDs is being developed by the CMDB Workgroup.
      <Encoded by CMDB>

      Examples could include:
      gmas_prod, web_server
      gmas_test, app_server
      gmas_dev, db_server
      gmas_integration, iam 
      Operations Policy
      CMDB name: op_policy
      Used to indicate that the Product ID is undergoing maintenance One of:
      • Scheduled_downtime
      Patching Policy
      CMDB name: patching_policy
      Used to define patching frequency and weekly timeslots. One of:
      • Zero-day + Monthly
      • Zero-day + Weekly
      • On-demand
      • 1 | 2 | 3| 4 | 5 (One of the weeks in the 5-week cycle)
      Single Component Security Standard exception
      CMDB name: one-exception
      Excuse non-conformance to the Security standard by one component

      Flags a resource as having a waiver for a single component of the Security standard.
      One of:
      • Inventory Collection
      • Endpoint Detection
      • Windows Anti-Virus
      • Logging
      • Vulnerability Scanning
      • Monitoring
      • Manage Configurations
    3. Other Candidate Tags for Inclusion in the Standard

      These tags are candidates for inclusion into the list of Enterprise Tags. A Tag Review Board or similar group will determine the appropriateness for inclusion, as well as the naming construct and allowed values.

      Tag Notes and Examples
      Backed Up  
      Building Root  
      Lifecycle  
      Network priority  
      Patched  
      Self-managed  
      Server owner  
    4. Deprecated Tags

      These tag names are published on the Cloud web site, they are not intended to be used by HUIT.

      Deprecated Tag Notes
      owner Deprecated in the DevOps domain
      department Deprecated in the DevOps domain
      project Deprecated in the DevOps domain
  6. Usage Standard

    The list of Standard Enterprise Tags identified in this document represents that essential set of information that management needs to conduct cross-organizational and cross-technical domain management. Since not all tags are relevant to all technology domains, this section sets out the mandatory and optional tag usage per technology domain.

    This list is simplified for presentation purposes. A complete table with additional descriptive material can be found in the side-car Excel spreadsheet for this document.

    1. Usage for Enterprise Tags

      The following table describes tags that must be used in a consistent fashion across IT organizations and technical domains. Mandatory indicates the tag must be associated with every resource within the technology domain. Optional indicates the tag is helpful when associated with the resources in the technology domain. ‘n/a’ indicates the tag is not relevant to the technology domain.

      ENTERPRISE TAG TECHNOLOGY DOMAIN
      Enterprise Tag Name AWS Azure VMWare Network Storage Backup IAM Logging Automation API
      AD Domain
      CMDB Name: ad_domain
      M M M n/a n/a n/a n/a n/a n/a n/a
      Automated Build Enabled
      CMDB Name: automation_bootstrapped
      M M M n/a n/a n/a M n/a n/a n/a
      Backup Policy
      CMDB Name: backup_policy
      M M M n/a O n/a M n/a n/a n/a
      Created By
      CMDB Name: created_by
      O M O O O O O O O
      Criticality
      CMBD Name: criticality
      M M M M M M M M M M
      Data Classification
      CMDB Name: data_class
      M M M n/a O O M O n/a M
      Environment
      CMDB Name: environment
      M M M M M M M M M
      Exceptions
      CMDB Name: exception
      M M M M M M M M M M
      Hosted By
      CMDB Name: hosted_by
      M M M n/a n/a n/a M n/a n/a n/a
      HUIT Asset ID
      CMDB Name: huit_assetid
      M M M O O O M n/a n/a O
      Resource Name
      CMDB Name: name
      O O M O O O O O O O
      Resource Type
      CMDB Name: resource_type
      M M M M M O M M M
      Server Platform
      CMDB Name: platform
      M M M n/a n/a n/a M n/a n/a M
      Legend:
      M = Mandatory
      O = Optional
      n/a = Not Applicable
    2. Usage for Enterprise Tags Pending Implementation

      The following table describes tags that will become Enterprise Tags once an implementation plan is completed. Mandatory indicates the tag must be associated with every resource within the technology domain. Optional indicates the tag is helpful when associated with the resources in the technology domain. ‘n/a’ indicates the tag is not relevant to the technology domain.

      ENTERPRISE TAG TECHNOLOGY DOMAIN
      Enterprise Tag Name AWS Azure VMWare Network Storage Backup IAM Logging Automation API
      Application CI ID
      CMDB Name: app_ci_id
      M M M O O O n/a n/a n/a n/a
      Operations Policy
      CMDB Name: op_policy
      M M M O O O M O O M
      Patching Policy
      CMDB Name: patching_policy
      M M M M M M M M M
      Product
      CMDB Name: product
      M M M M M
      Legend:
      M = Mandatory
      O = Optional
      n/a = Not Applicable
  7. References

a54d3b3f70a15a25e8eef64048e10d7f