If you are about to embark on or have embarked on the development and/or loading of a Configuration Management Database (CMDB) it is important to know and understand the different Configuration Item Types (CI Types) that are expected to be loaded into your CMDB.
Defining the CI Type
A Configuration Item Type (CI Type) is nothing more than a Data Type, Entity Type, Data Class or a Noun Type. For example: Software, Applications, Mobile Devices, Laptops, Desktops, Organizations, People, Facilities, etc. It is called a CI Type because it implies that any instance of such a CI Type has a configuration that must be managed and maintained.
NOTE: A CI Type is also often referred to as an Inventory Type.
Defining the CI Instance
A Configuration Item Instance (CI Instance) is an object or an objectified representation of a CI Type. For example, if we have a CI Type called “Laptop,” a specific Laptop with its own Serial Number would be a CI Instance.
Defining the CI Attribute
A Configuration Item Attribute (CI Attribute), also known as a CI Field, is a descriptive attribute or field that helps capture and establish a descriptive trait for a specific CI Instance. For example, “Serial Number” is a CI Attribute that is important to the CI Type “Laptop” because it helps distinguish any one Laptop from all other Laptops.
Defining the CI Attribute Value
A Configuration Item Attribute Value (CI Attribute Value) is the specific value captured and maintained for a CI Attribute. For example, if we have a CI Attribute called “Serial Number” that is important to capture for all Laptops (CI Type), the specific Serial Number “1234567890” is the CI Attribute Value for a specific Laptop (CI Instance).
Defining the CI Inventory
A Configuration Item Inventory (CI Inventory) is the list of all known CI Instances for a specific CI Type. For example, the list of all individual Laptops (CI Instances), each with their own Serial Number, represents an inventory of all Laptops (the CI Type).
Defining the CI Relationship
A Configuration Item Relationship (CI Relationship) are those relationships that exist between any two CI Instances.
Semantic Relationships, where there are descriptors (i.e. descriptive predicates) between source CI Instances and target CI instances, are always preferred to generic relationships that have no such descriptive predicates. This is because a descriptor always helps to provide context.
Example of a generic relationship: “Person A is related to System X.”
Example of a Semantic Relationship: “Person A is related as an System Owner to System X.”
The first example tells us nothing about how Person A is tied to System X, while the second example tells us exactly how Person A is tied to System X.
Not all CI Types have the same traits. The following subsections break down some important traits that you should always be aware of while working with your CI Types.
Technical versus Non-Technical CI Types
Technical CI Types refer to those that represent technologies. For example, Laptops, Servers, Software, and Applications represent Technical CI Types. These are also often referred to as Technical Assets.
Non-Technical CI Types are those that have nothing to do with technology. For example, People, Organizations, Industries, Capabilities, etc. They are also assets but they are Non-Technical Assets.
Discoverable versus Non-Discoverable CI Types
Discoverable CI Types are those types whose CI Instances and data about said instances can be automatically discovered through software tools, specifically referred to as Automatic Discovery Tools (ADTs). ADTs can be built or purchased to address the discovery of specific CI Instances from different software and hardware systems.
Non-Discoverable CI Types are those types whose CI Instances and data about said instances cannot easily be discovered by ADTs. This type of data is usually human created and maintained, often in tools like spreadsheets or applications with proprietary database models.
NOTE: ADTs are often also used to help identify and harvest Semantic Relationships that exist between CI Instances, for specific and discoverable CI Types.
Pre-Deployment vs. Post-Deployment CI Attribute Values
An important thing to consider is that every CI Instance for a given CI Type has an associated Life Cycle and that a good CMDB implementation helps you capture and maintain data throughout the life cycle of a CI Instance. In general, Life Cycle data is classified into two categories:
- Pre-Deployment Data: Data about a CI Instance that usually exists in its inception, planning, and design phases but that has not been deployed to an operational environment, yet.
- Post-Deployment Data: Data about a CI Instance that exists and is available after a CI Instance has been deployed to an operational environment.
It is important to note that, even for Discoverable CI Types, ADTs are relatively useless for the collection and maintenance of Pre-Deployment Data. This is because ADTs can only collected data about technical assets that have already been deployed (Post-Deployment Data).
Where to Start: An inventory of CI Types
The EICG acts as a Command, Control and Communications (C3) tool for CI data management. You can use the EICG for:
- quickly identifying the CI Types that are most important to most enterprises
- establishing ownership to different CI Types
- creating a roadmap for CI Type data collection
If you are an established CMDB implementer and you want a more exhaustive list of CI Types, we suggest reviewing the Taxonomy of Configuration Item Types.
Custom CI Types
It is important to understand that every industry is different and your industry may dictate Industry-specific or Business-specific CI Types that are not listed in either of the above resources. For example, the medical industry might care about things like Medical Instruments, Diagnosis Codes, Treatment Codes, Claim Processing Policies and Reimbursement Codes. The biology and pharmaceutical industries might care about Chemicals, Drugs, Clinical Trials and Adverse Events. The financial industry might care about Securities, Investments, Portfolios, Funds, Trades, and Settlements. A mature CMDB implementation will often include industry-specific CI Types.
You can see examples of industry-specific CI Types in the Knowledge Management Body of Knowledge (KMBOK), which inventories and inter-relates Knowledge Management CI Types and CI Instances. For example: Communities of Practice (CoPs), Blogs, Methods, Tools, etc.