With the ability to map services in i-doit, the documented objects can contribute to the business applications. An ERP system, for example, from various servers and services only delivers a useful service for users through its interaction. Such maps are the objective of the i-doit services functions.
The assets and components that are required for the service operation are united under a meta-level, the service. This can then be expanded, such as with SLA conditions, contact details or an operations manual. Services can be arranged hierarchically so that technical services such as a DNS system are described on a higher level and is therefore automatically defined as a function of all the underlying services.
Relationships and More …
i-doit already has everything in order to operate CMDB within the data base of technical IT documentation. Even the documentation is based on a relationship model, which then forms the foundation for the service modelling or visualisation of service and interdependency trees.
Relationships are created automatically when documenting – for instance connections between devices, software assignments, through membership in a cluster or the assignment of assets to a location. All of these relationships have a weighting to initiate technical infrastructure interdependency chains. Based on this, logical relationships are defined – which, for example, become necessary for service modelling.
With the CMDB explorer, the entire relationship model of i-doit is visualised and can be controlled according to various criteria. Thus, the interdependencies of individual objects or entire site trees can be displayed. Filters and profiles assist in making views clear and permanently available.
The CMDB explorer responds dynamically to changes in the dataset and allows an interactive operation. Any objects can be selected or the display type can be changed, views can be printed or exported as a vector graphic. For large trees, a zoom function helps to keep the overview.
External processes from the CMDB can be started with events such as save, archive or modify. The CMDB is thus a controlling entity from the central data repository. From the automated provisioning of virtual machines to triggering full Runbook automation, anything is possible. Any third-party systems can be fed with data or processes initiated.