Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

width78%

Configuration Items (CI) are services, components, or other assets that need to be managed in order to deliver an IT service. They are the basic units of the configuration management system and represent the specific services provided by OIT. Examples of CIs include documents, software, hardware, and services such as consulting and technical support. Regardless of form, composition, or complexity, the life cycle of a CI is documented and controlled. CIs are classified into several configuration groups, each of which has a life cycle. The configuration group life cycle describes each phase of a CIs life from requirements definition and acquisition through deployment and maintenance to retirement and disposition of the CI.

...

...

Typical Life

...

Although some CIs have a special life cycle, the typical life cycle for most CIs representing hardware is:

...

Cycles for All Asset Classes

Asset life cycles vary widely depending on the type of asset. The following is a description of the general life cycle for all assets:

Image Added

  • Phase 1: Asset Requested & Approved
    During this phase, a need for the asset is determined and a decision is made to deploy the asset. Specifications for the equipment are determined, quotes are obtained, approvals are collected from appropriate stakeholders, and a supplier is selected. In some cases, the "supplier" may be internal if, for example, an existing device can be repurposed or one is located in another department.
    This phase ends when the asset has been approved for acquisition or development and required funding has been obtained.

  • Phase 2: Order Placed & Asset Acquired
    If the asset is being acquired from a third party, an order is placed. If the asset is being transferred internally within OIT or from another department, the required documentation is prepared and executed. In the case of software assets, this phase includes the design and development of the software.
    This phase ends at the point where the asset has been delivered and is ready for installation or configuration.

  • Phase 3: Asset Tested & Installed
    The asset must be compared to the original specifications and acquisition documents to confirm that it matches the original requirements. Any required assembly and configuration is done during this phase. This includes operating system software, application software and services, databases, network connections, user definition and security rules, and arrangements made for backups and disaster recovery. When all configuration steps are complete, a system test is performed on the asset in place to ensure it meets all client requirements.
    This phase ends when the asset is ready to be deployed into production.

  • Phase 4: Asset in Service & Maintained
    This phase represents the useful production life of the asset. Throughout this phase, the asset will undergo periodic maintenance, upgrades, failures, and fixes. At some point, the usefulness of the asset will come to an end and plans need to be made to take it out of service. (Normally, these plans are made well in advance of the decommissioning of the asset.)
    This phase ends with the end of the useful life of the asset and planning for the retirement of the asset are complete.

  • Phase 5: Asset

...

  • Retired
    When the asset is no longer needed, either because it is being replaced by something newer or it no longer serves any useful function, it is

...

  • retired.

...

  • Retirement can be a fairly complex process depending on the asset class. If the services provided by the asset are no longer needed then

...

  • retirement can be as simple as taking the asset off line and disposing of it or making it available for other purposes. Plans for

...

  • retirement are generally made well in advance of the actual deinstallation of the asset.

...

Image Removed

  • Phase 1: VM Requested & Approved
    During this phase, a need for the server is determined and a decision is made to deploy a VM rather than a physical server. The specifications for the VM are determined, and a new VM is requested from the appropriate OIT team.

  • Phase 2: VM Configured & Tested
    Once configured, the VM must be compared to the original specifications to confirm that it matches the original requirements. Any required configuration is done during this phase including operating system software, application software and services, databases, network connections, user definition and security rules, and arrangements made for backups and disaster recovery. When all configuration steps are complete, a system test is performed on the VM to ensure it meets all client requirements. This phase ends when the VM is ready to be deployed into production.

  • Phase 3: VM in Service & Maintained
    This phase represents the useful production life of the VM. Throughout this phase, the VM will undergo periodic maintenance, upgrades, failures and fixes. At some point, the usefulness of the VM will come to an end and plans need to be made to take it out of service. (Normally, these plans are made well in advance of the decommissioning of the VM.)

  • Phase 4: VM Decommissioned
    When the VM is no longer needed, either because it is being replaced by a newer system or it no longer serves any useful function, it is decommissioned. Decommissioning is usually a fairly complex process when the VM is being replaced. If the services provided by the VM are no longer needed then decommissioning can be as simple as deinstalling the supporting configuration files. Plans for decommissioning are generally made well in advance of the actual deinstallation of the VM.

...

The typical life cycle for most CIs representing software or other intangible assets differs from that of physical assets in several significant ways:

Image Removed

  • Phase 1: Requirements Defined & Approved
    A need for the asset is determined and a decision is made to deploy the asset. Requirements for the asset are determined and approval is obtained from the client to proceed with the development or acquisition of the asset.

  • Phase 2: Planning
    Implementing software or systems usually involves significant planning to make sure the needs of the client are fully understood and the client understands the commitment for training and proper use of the asset.

  • Phase 3: Development or Acquisition
    With respect to software, it usually doesn't matter whether the software is developed in-house or acquired from a third party–one way or the other, the client will be changing business processes to take advantage of the new system. The asset must be compared to the original specifications and acquisition documents to confirm that it matches the original requirements. When the asset is ready, a system test is performed to ensure it meets all client requirements. This phase ends when the asset is ready to be deployed into production.

  • Phase 4: Production Rollout
    When the client determines that the asset meets all the initial requirements and OIT determines that it is ready to begin production support of the asset, the asset is moved to a production state. This process differs depending on a lot of factors and it it usually strategized well in advance of the actual production deployment. Rollout can be a simple process or can be phased over a long period of time.

  • Phase 4: Asset in Service & Maintained
    This phase represents the useful production life of the asset. Throughout this phase, the asset will undergo periodic maintenance, upgrades, failures, and fixes. At some point, the usefulness of the asset will come to an end and plans need to be made to take it out of service. (Normally, these plans are made well in advance of the retiring of the asset.)

  • Phase 5: Asset Retired
    When the asset is no longer needed, either because it is being replaced by something newer or it no longer serves any useful function, it is retired. Retirement can be a fairly complex process depending on the asset class. If the services provided by the asset are no longer needed then retiring can be as simple as removing a set of software. If the asset needs to be phased out rather than replaced, retirement can take some time. Plans for retiring intangible assets are generally made well in advance of the actual retirmement of the asset.

Audit & Validation

...

    • Note that if a CI is entered into the CMDB by error or serves no purpose, and it does not have linked records, it must be deleted from the CMDB rather than Retired.   Please contact the ServiceNow Administrator to have  such a CI removed. 

Change Management

As assets progress through each phase of their life cycle, the corresponding CI record in the CMDB must be updated to reflect the current state and status of the asset. In some cases this is an automatic process but for some classes (e.g. Business Services, Applications, equipment used to house servers, and other classes) the updates are done manually. A CI does not need to be added to the CMDB until the asset is acquired and ready for deployment.

  • Phase 1: Asset being acquired
    No CI required.
  • Phase 2: Asset acquired
    Submit a Configuration Item Change Request and the new CI will be added by the CMDB Administration Team. Use the Status and State fields to indicate that the asset has been acquired but may not have been installed yet.
  • Phase 3: Asset installed
    If a CI is on file for the asset then the Status, State, and other fields can be modified by the asset owner or the team supporting the asset. If no CI is on file for the asset then submit a Configuration Item Change Request and the new CI will be added by the CMDB Administration Team.
  • Phase 4: Asset in service
    Changes to the Status, State, and other fields can be made as needed by the the asset owner or the team supporting the asset.
  • Phase 5: Asset Retired
    The Status and State can be updated by the asset owner or the team supporting the asset but the CMDB Administration Team must be notified of the change via a Configuration Item Change RequestUnder 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 asset and any activity documented by incidents or change requests.

Audit & Validation

CIs must be periodically audited with the information in the CI record validated against the actual asset. Wherever possible, auditing will be automated using a discovery process or some other method that does not require manual intervention. The result of the audit will be reviewed by the auditor who will also arrange for remediation of the differences. The audit process will be scheduled in such a way that every CI is audited at least once a year. Each time an audit is run, the following information will be maintained in a report that is stored with the CI class definition record in ServiceNow:

  • Date and time of the audit
  • Auditor
  • CI class
  • Method of audit (i.e. based on automated tools or manual audit)
  • Results of the audit
  • Revealed differences between CMDB and actual CIs installed
  • Effects of the deviations
  • Corrections carried out to the CMDB
  • Improvement potentials
  • Reasons for the revealed differences between CMDB and actual CIs installed
  • Measures for the future avoidance of the differences

Configuration Groups

The following are the configuration groups used by OIT for organizing CIs in the Configuration Management Database (CMDB):

Section
bordertrue
Column
width25%
  • Application Servers

    • Tomcat
    • BEA Weblogic
    • IBM Websphere
    • Java
    • JBoss
    • Domino
    • Web Servers
  • Servers

    • Linux
    • Windows
    • Unix
    • ESX
    • Solaris
    • AIX
    • HPUX
    • OS X
    • Netware
  • Clusters

    • Windows
  • Database Servers

    • DB2
    • MSSQL
    • MySQL
    • Oracle
    • Sybase
Column
width25%
  • Database Instances

    • DB2
    • HBase
    • MSSQL
    • MySQL
    • Oracle
    • PostgreSQL
    • Sybase
  • Database Catalogs

    • DB2
    • MSSQL
    • MySQL
    • Oracle
    • Sybase
  • Network

    • Networks
    • Services
    • Network Gear
    • Routers
    • Switches
    • VPN
  • Load Balancers

    • LB Hardware
    • LB Applications
  • Data Center

    • Data Center
    • Computer Room
    • Zone
    • Rack
    • UPS
    • Power Circuit
    • CRAC (Air Conditioner)
Column
width25%
  • Infrastructure Services

    • Email
    • FTP
    • Directory Servers
    • Other
  • VMware

    • VMware vCenter Instances
    • VMware vCenter Datacenters
    • VMware vCenter Clusters
    • ESX Servers
    • VMware Virtual Machine Instances
    • VMware vCenter Datastores
    • VMware vCenter Folders
    • VMware vCenter Networks
    • ESX Resource Pools
  • Hyper-V

    • Hyper-V Servers
    • Virtual Machine Instances
    • Networks
    • Resource Pools
    • Clusters
  • KVM

    • KVMs
    • Virtual Machine Instances
    • Networks
    • Storage Pools
  • Automation Servers

    • Puppet Masters
Column
width25%
  • Base Items

    • Business Services
    • Applications
    • Servers (Physical)
    • Servers (Virtual)
    • Computers
    • Workstations
    • Out-of-Band Devices
    • Network Gear
    • Printers
    • Communications
    • Communication Devices
    • UPSs
    • Accessories
    • Computer Peripherals
    • Software
  • Storage

    • Servers
    • File Shares
    • Pools
    • Volumes
    • Disks
    • Controllers
    • Ports
    • HBAs
    • Switches
  • Storage Networks (SAN)

    • SANs
    • Fabrics
    • Zone Sets
    • Zones
    • Endpoints
    • Connections
Column
width2%
 

...

width20%

...

Include Page
OIT CMS Navigation Pane
OIT CMS Navigation Pane

On this page...

Table of Contents
maxLevel4
indent20px
excludeTask report