IT Service Naming Recommendations
Recommendations and best practices for naming IT services at UW-Madison
What's (really) in a Name?
A good IT service name establishes a meaning and a context for the service. Although there may be a need for an exception, an IT Service name should consider these recommendations to avoid difficulty:
- Be unique
- Be descriptive of the service that is being offered
- Be agnostic of any protocol or delivery mechanism - as protocols may change
- Be agnostic of any vendor - as vendors may change name, be purchased, or change branding
- Not use an acronym unless it is universally understood across the UW university system. May contain the acronym in parentheses for Help Desk reference
- Not contain a number or version
- Refrain from containing the word “Service” in the name, except for consulting services
- Provide the appropriate context, and define the service scope. Service names should be assigned differently, depending on service type.
- Avoid using ambiguous naming
- May contain a hyphenated “surname” to reflect scope or eligibility, that is, a 2nd name part defining a specific customer, if needed to differentiate the uniqueness of the service / support
- Avoid commas or periods as punctuation in the IT Service name. Punctuate the service name only using “-” or parentheses “()”.
- Avoid starting the service name with "UW-Madison" or "UW"
Relevancy - Where Technical Service Names are used
Technical Service Names are used in different parts of DoIT for different purposes. Changing an existing IT Service Name can cause a difficulty to the numerous processes which utilize a service's name. Places where IT services names are used may include:
- Outage Page(s)
- WiscIT (CMDB)
- Help Desk KB - Handling Documents (Internal)
- Help Desk KB - Technical / Troubleshooting (Internal and External)
- Service Provider KBs (such as Learn@UW KB or WiscWeb KB)
- SNCC KB
- COOP KB
- Incident assignments
- API's
- https://it.wisc.edu/services/
- metrics-gathering scripts
- various known/unknown scripts and email processes (e.g. automated ticket creation via email monitoring, etc.)
- other service catalogs and inventories
- Historical records and metrics for Changes/Incidents/Problems/Outages
- some Change Request workflows
- Searches saved in WiscIT
- Dashboards