Hardware life cycle

  • Release version: Xanadu
  • Updated August 1, 2024
  • 3 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Hardware life cycle

    The CSDM framework provides standardized fields and values to help ServiceNow customers track the entire life cycle of hardware assets and Configuration Items (CIs). This structured approach reflects the progression of physical hardware—from procurement through operation to retirement and end of life—ensuring consistent asset management and visibility within Asset Management and the CMDB.

    Show full answer Show less

    Key Features

    • Life-cycle value pairs: These consist of a life cycle stage (broad phase such as Operational or Retired) and a life cycle stage status (specific condition within that stage, e.g., In Use, In Maintenance, End of Support). This dual classification allows granular tracking of hardware status.
    • Hardware-specific visibility: Life-cycle stages and statuses are configured for hardware-related tables within Asset Management and CMDB only.
    • Hardware CI classes: The framework applies to various hardware CI classes such as computers, communication devices, storage devices, racks, and more, each represented in specific CMDB tables (e.g., cmdbcicomputer, cmdbcihardware).
    • Life cycle control: The [lifecyclecontrol] table governs which life cycle stage status values are available based on CI type, ensuring appropriate statuses for hardware versus logical or other CI types.
    • Relationship with application services: Application services represent logical groupings of hardware and software CIs. Hardware CIs have their own physical life cycle independent from the application service’s logical life cycle, allowing hardware to remain active even if an application service retires.

    Practical Implications for ServiceNow Customers

    • Implementing hardware life cycle value pairs helps maintain accurate and consistent asset status information across hardware CIs.
    • Understanding that hardware CIs may outlive application services ensures proper management of shared or idle hardware, avoiding premature retirement of physical assets.
    • Recognizing dependencies—such as shared hardware for multiple application services—helps in impact analysis and prevents unintended disruption during service retirements.
    • Customers can view detailed attributes, identification rules, and schema structures for hardware CIs through the provided CMDB classes, aiding in effective configuration and management.

    The CSDM framework provides standard fields and values that you can use to track the life cycle of an asset or a CI. The hardware lifecycle states represent the overall life cycle of hardware assets and CIs as related to their products.

    Life-cycle values for hardware

    Hardware assets are physical items that are stocked, for example servers, monitors, and keyboards. A life-cycle value pair is the combination life cycle stage and life cycle stage status values for a CI, asset, or IBI over the life cycle of a product instance. The stages and statuses for the hardware life-cycle process are visible only in hardware-related tables in Asset Management and the CMDB.

    The standard CSDM life-cycle value pair covers all phases of a product instance life cycle.
    • A life cycle stage is one of the broad phases that a CI moves through, from inception or procurement to retirement and end of life.
    • life cycle stage status is the particular status of a CI within its current life cycle stage.
    For example, a hardware CI in the Operational stage might change status over time from In Use to In Maintenance to End of Support. A different hardware CI might go from In Use to End of Support without ever having been in In Maintenance status.
    Allowed life-cycle values during the Operational stage of a hardware CI's life cycle
    Note:
    The [life_cycle_control] table uses the type of CI (hardware, document, logical and so on) to determine which life cycle stage status values are available for each life cycle stage.

    Hardware life-cycle process: pipeline, purchase, inventory, deploy, operational, defective, missing, and end of life.

    For additional information on how you can benefit from implementing life-cycle value pairs for CMDB entities, see the 'Map existing status values to CSDM life-cycle value pairs' section in the 'Foundation domain' topic.

    Holistic life cycle: CMDB hardware tables (from cmdb_ci)​

    CMDB hardware tables​ CMDB hardware table name​
    Accessory​ cmdb_ci_acc​
    Communication Device​ cmdb_ci_comm​
    Computer Peripheral​ cmdb_ci_peripheral​
    Computer Room AC​ cmdb_ci_crac​
    Display Hardware​ cmdb_ci_display_hardware​
    Facility Hardware​ cmdb_ci_facility_hardware​
    Hardware​ cmdb_ci_hardware​
    Imaging Hardware​ cmdb_ci_imaging_hardware​
    IP Device​ cmdb_ci_ip_device​
    Monitoring Equipment​ cmdb_ci_monitoring_hardware​
    Network Adaptor​ cmdb_ci_network_adaptor​
    Printing Hardware​ cmdb_ci_printing_hardware​
    Rack​ cmdb_ci_rack​
    Storage Device​ cmdb_ci_storage_device​

    Example hardware classes

    View attributes, identification rule, and other important schema structures for the CMDB Computer [cmdb_ci_computer] class. See Hardware [cmdb_ci_hardware] class.

    How retiring an application service might affect a hardware CI

    An application service is the logical representation of the underlying hardware and software CIs that work together to implement a business application or system. The application service represents an instance of the business application or system.

    Hardware and software CIs are managed using the physical life-cycle value pairs. Because an application service is a logical representation, it is managed as using the logical life-cycle value pairs. The physical hardware CIs that are part of the service map under an application service have their own life cycle, but they are related through the application services as a specific set of dependencies or decomposition.

    Example 1: A hardware CI is not retired when the application service is retired

    When an application service is retired, the associated hardware might not be retired. For example, the hardware might remain idle, unrelated to any application service, until it is reallocated for use by a new application service.

    Example 2: A hardware CI is shared by multiple application services

    In the common scenario of a shared database, multiple application services (each with a unique database schema) share a single database service. The database service runs on a single physical host.

    When one of the application services is retired, the database service and host cannot be retired. All of the other application services still depend on the database service that is running on the host.

    See Monitor the health of application services on the Application Services dashboard.

    CSDM videos in the ServiceNow Community

    Playlist of all CSDM videos