Supported Configuration Items
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.
The Rack CI represents a computer cabinet or other storage in which Devices are contained. The position and size of each Device in the Rack can be recorded and displayed to show the layout and free space. Power and heat capacity can be calculated to show the total output.
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 Networks by defining multiple network interfaces. A Network can also be associated with multiple Locations, Documents, Changes and Incidents.
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 have multiple Interfaces which are linked to other Devices or Networks to show point-to-point connections.
A Device can have multiple interfaces (e.g. a 48 port switch) and each interface can be linked to one or more other Device CIs. It is possible to record all point-to-point connections in easyCMDB at interface level.
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.
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.
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.
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". People may be imported and synchronized with Active Directory.
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. Documents may be uploaded into the CMDB or linked to externally via UNC file path or URL. Documents may be linked with any CI including Changes and Incident records.
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 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.
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.
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.
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. Tasks may also execute a custom function to perform system integration or trigger an external event via the API.
Home