 | enterprise_tag_standard_2_5.pdf | 438 KB |
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.
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.
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 an 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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. Also, since not all tags are relevant to all technology domains, this section sets out the mandatory and optional tag usage per technology domain.
Details of the tags can be found in the attached pdf document.
The promotion of local domain tags to Enterprise level is a living process that reflects changes in configurations, technologies, and processes. This section addresses tags that are needed, but have not been fully defined, ratified, or implemented. During routine review cycles of the use of tags, some of these will be promoted to the Enterprise Tag list, while others may continue to evolve, or be deprecated.
Details of the tags can be found in the attached pdf document.
