Websites provide information or access to functions which are required by a business service. Websites are browser-based and are similar to application software but typically they do not execute any business logic or update databases. A website may be part of more than one business service and may require other services to support it.
CI Naming Convention
Website Configuration Item names should follow the form of:
{common_name} Website ({url}) [{version}] [ - (ownerclient)]Where:
{common_name} | The name of the website as it referred to by the majority those who will reference the CI. Whether provided by a third party or developed in-house, this should be the full, formal title of the website (e.g., "UCI Student Affairs" or "UCI Alumni") rather than a URL, nickname, abbreviation, or acronym. 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. |
|---|---|
Website | All website CIs will contain the word "Website" in the CI name between the common name and the URL. |
{URL} | URL used to access the website. The URL should include only the fully qualified site name (e.g., "studentaffairs.uci.edu") without the URL scheme label ("http" or "https"). It should always be enclosed in parentheses to separate it from the common 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 website. |
{ownerclient} | The name of the primary end user of client that is the primary end user of the CI. This is optional and should only be used to eliminate any confusion about the owner primary user of the CI or to eliminate duplication of CI names. For example, if several departments are using the same name for a website but there are separate instances of the website for each department, include the department name as the ownerclient. For example: Home Page - (DUE), Home Page - (Graduate Division), etc. The owner client should always be enclosed in parentheses and separated from the rest of the CI name by a hyphen. |
| Info | ||
|---|---|---|
| ||
When an application is retired, the application name must be modified to include a prefix of RETIRED to make it obvious in listings and searches that the application is no longer being used. |
Examples
The following are examples of CI names that have been standardized using the conventions described above.
studentaffairs.uci.edu
using this standard:
- Student Affairs Main Website (studentaffairs.uci.edu)
- Grad Division Main Website
GD Home
- v10.2 (grad.uci.edu)
- OIT Public Website (www.
- oit.uci.edu)
- RETIRED - UC Irvine Athletics Public Website (ucirvinesports.com)
Typical Life Cycle
for Websites
CI Maintenance
Owner | Create CI | Change CI | Decommission CI | Maintain Relationships | Comments |
|---|---|---|---|---|---|
|
|
|
|
|
Typical Relationships
The following relationships should be used when defining dependencies for applications| Info | ||
|---|---|---|
| ||
Additions and changes to the CMDB should be made carefully and at the appropriate time. Be sure to review How to Maintain the CMDB Quality and Data Integrity before making any changes. This article explains when and how CIs are maintained and who should be maintaining them. If you have any questions about maintaining CIs then contact the ServiceNow Support Team for more information. |
| Phase | CI Activity |
|---|---|
Phase 1: Website Developed | If ServiceNow will be used to track incidents, changes, or task assignments while the website is being developed then a CI will be required. Otherwise, a CI is not required until the website is ready for publication. |
| Phase 2: Website Tested & Deployed When the website is ready and OIT determines that it is ready to begin production support, the website is moved to a production state. This phase ends when the website is ready to be used for its intended purpose. | A Configuration Item Management Form is submitted by a member of the team preparing the website and the new CI will be added to the CMDB by the CMDB Administration Team. |
Phase 3: Website In Service & Maintained | Ongoing adjustments to the Status, State, and other fields in the CI record are made as needed by a member of the team supporting the website. |
Phase 4: Website Retired | The Status and State are updated by a member of the team supporting the website to reflect the fact that it is no longer operational and has been retired. At the same time, the website name in the CI is modified to include a prefix of RETIRED to make it obvious in listings and searches that it is no longer in use. Under no circumstances should a CI ever be deleted from the CMDB. Deleting a CI record will make it impossible to trace the history of the software and any activity documented by incidents and change requests. |
Suggested Relationships
When mapping dependencies and relationships, the following are typical connections to other CI classes used by websites:
Relationship | Dependent Class |
|---|---|
Depends on | Email Server |
Gets data from | Database |
Receives data from | Application |
Uses | Database1 |
| Runs on | |
| Apache Web Server | |
Sends data to | Application |
Sends data to | Business Service |
Sends data to | Database |
Used by | Business Service | Uses | Load Balancer
Notes:
- Use the appropriate subclass. For example, if the website references a SQL Server database then define a dependency to the appropriate database CI in the SQL Server Database class and not the more generic Database class.
| Include Page | ||||
|---|---|---|---|---|
|
On this page...
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|