IT speaks it's own language. This glossary is supposed to help to know what the vocabulary in i-doit means.
The "General" category belongs to those categories which are a fixed part of all objects. Because of this it cannot be unselected per object type. Important attributes are stored in these categories like the object title, SYS-ID, CMDB status and condition.
An attribute is a documented value to an object. Attributes of the same kind are summarized in categories. Example: in the "General" category the CMDB status.
Attributes of objects are saved and edited via form-fields in the web GUI of i-doit. Hence these fields are called attribute fields. These fields can differ: There are single- and multi-line text fields, date fields, HTML editors, object browsers, dialog-plus-fields and many more.
A category which is created by a user and configured with one or more attribute fields is marked as custom in i-doit.
Configuration Management Database (CMDB)
A Configuration Management Database, or CMDB, allows for the administration and access to Configuration Items (CI). i-doit covers important features of a CMDB as a software for IT-Documentation. More information to CMDBs can be found at Wikipedia.
The CMDB status serves to document the lifecycle of an object, for example a server or a software. This is documented per object as attribute in the "General" category. It comprises important steps in a lifecycle already in the delivery state of i-doit.
A dialog-plus-field is an attribute field for the selection of a pre-defined value. It's also called drop-down field in the web jargon. As many additional values as desired can be a created and edited. i-doit already offers some pre-configured dialog-plus-fields.
Extensions are available for free and offer additional features for your documentation. They can be downloaded via the customer portal. The installation is done separately via the i-doit .
|See attribute field.|
A global category can generally be assigned to any object type, so its attributes are available to the respective objects.
The name i-doit is a play on words and stands for "I document IT". And yes, we know the i-diot joke
The IT-documentation comprises the technical documentation, administration, consolidation of ITSM data and the modelling of services. The technical part includes the characterization of objects as well as their relations to each other. i-doit delivers a multi-dimensional data-model for this to gather data in a structured way, process it and use it again in various contexts. IT-documentation is to be unstood as a discipline of the IT Service Management (ITSM), which plays an important role in any IT-organisation. The terms "IT-documentation" and "CMDB" are often used as equals.
Thematically coherent attributes are summed up per object in categories. Three types of categories exist: global, specific and custom. They are also subdivided into single- and multi-value categories. Some categories are backwars while others serve as view. Last but not least special categories like "General" and the "Overview" exist.
Some thematically coherent categories are summed up to a folder structure. An example is the category folder "Network", which contains the documentation of physical and logical ports as well as interfaces in dedicated sub-categories. This folder structure can neither be edited nor can sub-categories be configured per object type.
|See multi-value-category below.|
If the attributes of a category can be documented multiple times per object, then this is called a multi-value-category. An example is the "CPU" category. If it is a multi-socket system, then each CPU can be documented separately concerning its frequency, number of cores etc. The counterpart to this is the single-value-category.
Modules are fee-based extensions with a significantly wider range of functions. These are made available after purchase and can be installed via the i-doit admin center.
In i-doit objects are all things which we document in an IT-documentation, no matter whether they are physical devices like server and clients, or logical constructs like networks and services. An object is defined by its object type, which determines what attributes can be filled with values for the object. In ITIL© the term "Configuration Item" (CI) is used. In the asset management the term "Asset Value" is widely spread. We want to establish a more abstract and therefore a more generally useful definition with the term "Object".
If objects are in a relation, then this relation is often times documented via an object browser in i-doit. This is an attribute field which is used in many categories. An example is the "Purchased at" int he "Accounting" category, to document where an object has been purchased.
IT-components can not only be documented separately for themselves in i-doit, but they can also be put into relationships. There are various pre-configured types of relations which can be adjusted and expanded upon. Each relation is a separate object (with no license required) which is automatically created, edited or deleted. A relation consists of a master and a slave object. An emphasis can also be set.
As many objects as desired can be set for each object type. These are summed up in a table in the object list of i-doit. It can be configured what attributes are shown in which columns.
Each object in i-doit receives a title. This is documented as attribute in the "General" category. "Name" is used synonymously for this attribute.
We call the sum of all objects of the same type object type. Examples are "Router", "Server" or "Applications". Typically this summary is also called "Class". In ITIL© the term "CI Type" is used.
Object Type Group
It's not a rare thing that many object types are in usage in a living and well-filled IT-documentation. In order to make this abundance more transparent, object types of the same kind can be grouped. These groups appear in the main navigation bar (uppermost area) of i-doit.
The quicklaunch widget allows for the fast access to frequently used features in i-doit. These can be accessed directly via the widget.
|Diese "virtuelle" Lokation wird benötigt um jenen Lokationen, die in der Lokations-Hierarchie an der Spitze stehen auch eine Lokation zuweisen zu können. Sie auch folgenden Knowledge Base Artikel zur Erläuterung.|
If two or more objects are in a relation to each other, then this is captured in the respective category. Any number of persons, person groups etc. can be assigned as contacts for an object in the category "Contact assignment" for example. Another category called "Assigned objects" exists to make it clear within these persons and person groups to which object they have been assigned as contacts. Since the same information is available there, but has only been saved once in another context, this is a backward category.
Each associated attribute can only be documented once per object in a single-value-category. An example is the "Accounting" category: Information to inventory number, costs etc. are only needed once. The counterpart to this is the multi-value-category.
A specific category differs from a global category in the sense that its attributes focussed on just one or few object types. An example is the "Rack" category which is assigned to the object type "Rack" and displays a rack-view for the user.
SYS-ID stands for "System Identifier" and automatically allocates an unique number per object. It's stored as attribute in the "General" category. In the delivery state of i-doit the SYS-ID consists of the "SYSID_" prefix and a string of numbers. Per object type a prefix for the SYS-ID can be set in the object type configuration, like "SRV_" for servers as an example. The attribute field for the SYS-ID can be marked as write-protected at
|The overview page is displayed in the web GUI of i-doit when opening an object. it consists of the "General" category and other optional categories which are assigned to that object type. These can be de-/selected and sorted in the object type configuration.|
In some categories no attributes can be set per object. These serve the evaluation of data stored elsewhere. The shown data cannot be edited. An example is the "Object vitality" category, which is an evaluation of the "CPU", "Memory", "Port", and "Software assignment" categories.
The "Condition" attribute is used to describe the lifecycle of the IT-documentation. It is displayed per object in the "General" category. Each newly created object receives the "normal" condition. Is the documentation of an object not needed anymore, then it can be "archived". The next step in the lifecycle is the "deleted" condition. Until here the documented data is completely conserved in the IT-documentation, but they are hidden. Only the last step "purge" removes the documentation of an object including all associated object relations from i-doit.
See CMDB status.