Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Section
Column
width78%

Naming Applications

Applications provide functions which are required by a business service. Applications are typically software and are usually referred to as "application software." But in some cases applications, may require specific hardware components or other assets in order to function. An application may be part of more than one business service and may require other services to support it.

Application software Configuration Item names should follow the form of:

      {common_name} [({nickname})] [{version}] [ - (owner)]

Where:

{common_name}

The name of the software as it referred to by the majority those who will reference the CI. Whether a commercial product or something developed in-house, this should be the full, formal name of the product (e.g., "Office Suite 2016" or "Graduate Applicant Tracking System") rather than a nickname, abbreviation, or acronym ("Office 16" or "GATS"). While nicknames and abbreviations may be meaningful to frequent users of the CI, they are not so apparent to others who are not as familiar with the application.

{nickname}

Nickname, abbreviation, or acronym for the CI. The nickname is optional and should always be enclosed in parentheses to separate it from the full name.

{version}

A version is used to identify a specific baseline of a CI. This information should only be included if the CI is being defined to track a specific version or release of the applicaiton.

{owner}

The name of the primary end user of the CI. This is optional and should only be used to eliminate any confusion about the owner of the CI or to eliminate duplication of CI names. For example, if several departments are using the same same application software but there are separate instances of the software for each department, include the department name as the owner. For example: Office Suite 2016 - (DUE)Office Suite 2016 - (Graduate Division), etc. The owner should always be enclosed in parentheses and separated from the rest of the CI name by a hyphen.

Application Software CI Name Examples

The following are examples of CI names that have been standardized using the conventions described above.

Common
Standard

GATS

Graduate Applicant Tracking System (GATS)

GD ZotPortal Portlets
ES ZotPortal Portlets

ZotPortal Portlets - (Grad Division)
ZotPortal Portlets - (Enrollment Services)

Jack/port location (JPL) databaseJack/Port Database (JPL)

A Configuration Item (CI) is any service, component, or other asset that needs to be managed in order to deliver an IT service. Information about each configuration item is recorded in a configuration record and each is identified by a unique name. CI names should be concise, follow a consistent format, and contain enough information that a unique name can be assigned to each individual item and the nature of the item is immediately apparent to any user.

General Principles in Naming CIs

It is unlikely that the same naming standard can be used for all CI classes. The following are general guidelines that should be considered when determining the most appropriate naming convention for a particular CI.

  • A format should be chosen that eliminates the need to ever have to rename the CI throughout its life cycle. Do not include version numbers or release dates in CI names unless you are tracking that specific version of the CI through its entire life cycle.
  • The name should describe the CI in a way that it is recognizable by the majority of users (including clients) who will see it.

  • The name should have the more significant information at the beginning, which will make it easier for systems with autocomplete to find the name when a user searches for it.

  • For hardware, consider including the asset tag ID or chassis serial number in the name. This will uniquely identify the CI and typically will not change during the CI's life cycle.

  • For software, use the common industry name of the product (for commercial products) or the name by which the software is usually referenced (for software developed internally) as the basis of the name.

  • For servers, printers, workstations and other network devices, consider that host names often change and care should be taken when considering them as CI names.

  • Make every attempt to avoid abbreviations, jargon, and slang in CI names. Keep in mind that everyone from end users on the business side to the technical staff called on to provide support will need to understand the name.
  • Use appropriate capitalization in the name. Pay particular attention to acronyms, application software names, and other words that have unusual letter casing. (See Capitalization Conventions for more information.)
  • Under no circumstances should a person’s name be included in a CI name. If, for some reason, a person's name must be included then use the person's home department rather than the person’s name.

Duplication of CI Names

CIs are classified into any number of categories based on the purpose of the item. CI classes typically include IT or business services, hardware, software, buildings, and formal documentation such as process documentation and service level agreements. Every effort should be made to prevent duplication of CI names even across different classes. For example, the name of an application software package often becomes synonymous with the business service supported by the software, as in the following examples:

Application Software
Business Service
ServiceNowITSM Services
CognosBusiness Intelligence
Xerox DocuShareElectronic Document Management

In everyday use, the application software name is commonly used to refer to both the application and the service. Naming both an application software CI and a business service CI "ServiceNow," even though they are in different configuration classes, leads to confusion when referring to one or the other.

Column
width2%
 
Column
width20%
Include Page
adcom:CI Naming Standards Left Navigation Pane
adcom:CI Naming Standards Left Navigation Pane