- Created by Eric Puchalski , last modified on Dec 19, 2018
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 6 Next »
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}] [ - (owner)]
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. |
{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 name for a website but there are separate instances of the website for each department, include the department name as the owner. For example: Home Page - (DUE), Home Page - (Graduate Division), etc. The owner should always be enclosed in parentheses and separated from the rest of the CI name by a hyphen. |
NOTE
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 using this standard:
- Student Affairs Main Website (studentaffairs.uci.edu)
- Grad Division Main Website 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
Phase | CI Activity |
---|---|
Phase 1: Website Developed | No CI required. A CI does not need to be added to the CMDB until the website is acquired (or developed) and is ready for deployment. |
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. | ubmit a ServiceNow Configuration Item Update Request and the new CI will be added by the CMDB Administration Team. Once the CI has been added to the CMDB, you can use the Status and State fields to indicate the installation status and operational state of the website. |
Phase 3: Website In Service & Maintained | If a CI is in ServiceNow for the website then Status, State, and other fields are maintained by the asset owner. If a CI has not yet been added, then submit a ServiceNow Configuration Item Update Request and the new CI will be added by the CMDB Administration Team. |
Phase 4: Website Retired | The Status and State are updated by the website owner to reflect the fact that the website is no longer operational and has been retired. 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 website and any activity documented by incidents and change requests. When there is no longer a need for the website, the website name in the CI is modified to include a prefix of RETIRED to make it obvious in listings and searches that the website is no longer in use. |
Typical Dependencies
The following relationships should be used when defining dependencies for websites:
Relationship | Dependent Class |
---|---|
Uses | Database1 |
Runs on | Apache Web Server |
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.
Configuration Management Process
Overview
CI Life Cycles Overview
CI Naming Standards Overview
How to Maintain the CMDB Quality and Data Integrity
Resources
Committee Membership and Meetings
C/wiki/spaces/adcom/pages/68025789
OIT Architecture Review Board
Configuration Items
On this page...
- No labels