Configuration Management Funcionalities
Service components and IT assets are not the same thing. A specific item can be one or the other, or both. Therefore, this must (at a minimum):
- Allow for the management of service component records separately from the management of IT assets within a service component repository and an IT asset repository, respectively, and allow the records to be linked and to share common data through this link.
- Alternatively, allow for the management of both types of records within a common repository by managing them separately through specific component attributes and IT asset attributes within a single record.
Vendor response: Yes, it does. The platform allows create different asset types and customized fields for each one including life-cycle, relationships with assets, Cis and services.
Multiple service component repositories, if needed, can be federated into a single view.
Vendor response: Multiples Components can be federated into a single view using external integration via API
Different types of component records can be managed; examples of this can include but are not limited to:
- Records for physical components
- Records for virtual components
- Records for logical components (such as service records)
- Records for cloud and vendor-hosted components as well as services (logical components)
- Records for nontechnical components such as documentation, physical locations, etc.
- Records for environment components such as air handlers, coolant systems, physical security systems, power distribution units, etc.
Vendor response: The platform allow create different asset types and customized fields for each one including life-cycle, relationships with assets, Cis and services
Component records and attributes can be created and updated through multiple methods. This must include (at a minimum):
- Manual entry
- Through discovery and monitoring
- Through barcode scanning technology
- Via related records, such as changes and releases
- Through ETL (extract, transfer, and load) with external databases and sources
Where DevOps is in use, component records and related attributes can be automatically added or updated through the DevOps pipeline.
Virtual component records and attributes can be automatically added or updated through virtualization.
Vendor response: Yes, it does use manual entry, discovery, related items and processes, ETL, Low-code, API and for Barcode, using integration via API and webservices.
A data object model is provided, which must include (at a minimum):
- Common classifications of components
- Common attributes for each classification
- Defined relationships between component classes/types
- Multiple record types that support physical, logical, and virtual/digital items
Clients should be able to define and create their own component classes/types, attributes, and relationships, in addition to the provided data model.
Vendor response: Yes, it does use Configuration Item Type, customers can create their own Assets Types, Life Cycle, Tags, Models.
The install environment of components can be identified and updated in the corresponding component record; for example, a component is in the development, testing, or production environment.
Vendor response: Yes, components can be added in specific groups for identify each one.
Service models can be identified, defined, and updated through monitoring and discovery, which can include the automated mapping of relationships.
Monitoring and discovery can be done natively within the toolset or tool suite, as well as through standard integration with external tools.
Clients can manually create service models where discovery does not exist.
Vendor response: The platform can create mapping manually and relationship between all assets, components and services
Service records in the repository are linked to or related to services published on the service catalog, where selected attributes and information from the service records can be presented.
Vendor response: Yes, use the service catalog linked with Portfolio can provide the view of all service records and all attributes and information
A graphical view of related components (service models) is presented and can be filtered to manage the view. Individual component records can be selected and accessed from this view.
Vendor response: Yes, it does via Mapping on CMDB or Service Map, both views delivery same information
Common component life-cycle statuses are provided out-of-the-box, as well as the ability for clients to define their own unique statuses. Examples of this can include, but are not limited to:
- Not installed
- Installed, not active
- Online/active
- Off-line
- Maintenance mode
- Retired from service
Vendor response: Yes, the customer can create new status for create new life cycle based in their needs.
Through discovery and monitoring, the current state of services and related component records can be viewed in real-time; for example: active; off-line; not communicating; degraded; etc.
A dashboard view showing the status and health of services and individual components may also be provided.
Vendor response: The platform can monitoring and related component records can be viewed in real-time; for example: active; off-line; not communicating; degraded
The status history of services and related components are recorded, tracked, and can be reported throughout their lifecycle. Historical reporting (or view) provides the status at any (past) point in time, in addition to the current state.
Vendor response: Yes, use History/Baseline tan on CMDB screen
Service and component information can be audited to validate the accuracy of the information. This can be accomplished through a comparison of the record against the live component.
Vendor response: Yes, use History/Baseline tan on CMDB screen
Individual service and component records can be linked to other records in the toolset. This must include, at a minimum:
- Incident records
- Request/task records
- Problem records
- Change records
- Release records
- The DevOps pipeline (if DevOps is supported)
- Service and internal support agreements or related records
- Vendor contract records
- Disaster recovery/continuity plans or related records
All of the records that are linked to a specific service or component record can be accessed through the service or component record; providing a history of all actions performed against the service or component.
Vendor response: On CMDB screen there are all relationship between assets/ci and process
Business criticality and risks related to the component can be identified and recorded in the corresponding component record. Examples of this can include, but are not limited to:
- Criticality tier levels (associated with continuity or recovery plans)
- The manual entry of criticality, such as service and business impact
- Security vulnerabilities
- Risks related to failure and unavailability
In turn, this information can be used to identify the relative severity or priority of linked incidents, problems, and release records, as well as used for the risk assessment of linked changes.
Vendor response: Yes, it does use Knowledge Asset as documentation for: (Criticality Tier Levels, Security Vulnerabilities, Risks related).
Resource information can be identified and recorded in the corresponding component record, either manually or through automated methods. This must include (at a minimum):
- The owner (by an individual component or by component classification)
- The location of physical components
- The host association for virtual components
- Support group(s)
Vendor response: Yes, in Main screen, support, location and owners are available fields for fill out and customer can create new one.
Definitive sources, locations, and versions of software can be identified and recorded in or related to the corresponding software component record.
The status of the definitive software can also be identified. For example, supporting checked-out and checked-in statuses, and automating version updates in the component or related record.
Vendor response: Yes, based on environment discovery user can create the definitive media and platform will generate software reports
Component discrepancies can be identified and managed. Discrepancies can include differences between the record attributes and the actual component and non-compliance with change authorization.
This can be done through monitoring and discovery, where all discrepancies between the component record and the actual state of the component are captured for further review and appropriate action – either automatically or through manual verification.
Vendor response: Yes, using Baseline
Role-based / user ID-based access to component records and attributes ensures proper levels of access, view, or update capability.
Vendor response: The customer define who employee can view or edit CMDB by user or Group.
