easyCMDB

Supported Configuration Items

The term configuration item or CI refers to the fundamental structural unit of a configuration management system. Examples of CIs include documents, software, people, Assets, etc. Configuration Management systems oversee the life of the CIs through a combination of process and tools. The objective of these systems is to avoid the introduction of errors related to lack of testing or incompatibilities with other CIs.

locations The Location CI represents a physical location where People and Devices reside. A Location can also contain Racks, to which Devices are assigned. A Location could represent a building, floor of a building, or even a room within a building. Locations may also be linked to Networks and Documents.
networks A Network CI represents a physical network, for example a LAN or WAN. A Network can be associated with multiple Devices, and a Device can be connected to multiple Netwo1ks by defining multiple network interfaces. A Network can also be associated with multiple Locations, Documents, Changes and Incidents.
device configuration item A Device CI represents any type of computer hardware, for example Personal Computers, Laptops, Printers, Routers, Switches or Servers. A Device is assigned to a Location and may optionally reside within a Rack. Devices can contain Applications, Software Products & Data Stores and be associated with People and Documents. A Device may connect to one or more Networks.
software license management A Software Product CI represents a commercial software product that does not directly perform a business function, but may support an Application. Examples of Software Products are Operating Systems, Development Tools, Database Software etc. A Software Product resides on one or more Devices and may utilise one or more Data Stores. A Software Product can be associated with People and Documents.
CI Applications An Application CI represents a software component that supports a business process. An Application usually depends on Software Products and Data Stores to operate, and can also be associated with People and Documents. An Application will typically reside on multiple Devices.
datastores A Data Store CI represents a logical information repository, e.g. an Oracle RDBMS or LDAP directory. A Data Store resides on one Device and may be linked to one Software Product. One or more Applications and Software Products may utilise a Data Store. A Data Store may be associated with People and Documents.
people ci The People CI represents someone that has an involvement in your IT operation. Optionally, a Person may be given access to read and/or write data to the CMDB. A Person may be assigned to a Location and associated any other CI. An example of an association between a Person and Device might be "Administrator" or "Installer"
document ci A Document CI represents any type of file containing information relevant to another Configuration Item. Documents may be associated with any other Configuration Item type. An example of a Document might be a User Guide associated with an Application or a build document for a Device. Once uploaded a Document can be linked to any number of CIs providing a powerful information repository.
collections ci
Collections allow you to group arbitrary CIs together. There are a number of pre-defined Collections that enable you to define Services, Projects, Releases, Support Groups and Access Control Groups. Plus you can create your own Collection types to group related CIs.
services Services are a special type of Collection that help you to define your IT Services and related CIs. Each Service can have its own SLA definition and provide default categorization, assignment and priority for incidents affecting the Service.
change management Changes record all modifications to your infrastructure by association with your CIs. Changes may be linked with other dependent Changes. Only users flagged as Change Approvers may approve Changes. Changes can be assigned to Support Groups or People.
incident management An Incident represents a Fault, Problem, Known Error or Service Request. An Incident may be linked to any other CI that was affected or caused the Incident. Incidents can inherit from Services which define priority and other attributes. Incidents may be assigned to Support Groups or individuals for action and can track all associated Tasks.
Tasks Both Changes and Incident records can have Tasks defined. A Task can be assigned to a group or individual and can be dependent on other Tasks. Tasks have their own due date and time and can be linked separately to Documents. By defining templates you can create your own workflows for recurring Changes & Service Requests.