When it comes to populating CMDBs, most IT professionals think that they’ll simply be able to install Auto-Discovery Tools (ADTs) which will collect Configuration Item (CI) Types, CI Instances, and CI Relationships. To often, they think that dealing with Non-discoverable CI Types will be easy. Almost always, the push dealing with Non-discoverable CI Types to the end of their integration schedules, never really getting to them. This article helps understand the differences between Discoverable and Non-discoverable CI Types, with some options for dealing with them.
Discoverable CI Types
Discoverable CI Types are those data types that can easily be discovered by automated software tools and which, once installed, know how find the CI Instances and many (but not all) of the relationships between them. For example, network sniffers can crawl the network to identify different software and hardware (e.g. laptops, desktops, servers) that are connected to it.
Non-Discoverable CI Types
Non-discoverable CI Types are those data types that cannot easily be discovered by automated software tools. For example, Applications, Business Functions, Organizations, Products, Services, and Market Segments are data types for which Commercial Off the Shelf (COTS) ADTs will never be to automatically discover. This is because the data for these types is rarely deployed to networks in a uniform manner, across different enterprises, in a manner where ADTs can find them in a standard way. They rarely have standard names, standard locations, standard attributes, etc. This makes them almost impossible to find with 3rd party tools.
Uses of Discoverable vs. Non-discoverable CI Data
When implementing a CMDB, the implementers should stop to consider who will get value from what specific types of data. The primary purpose of CMDBs is to facilitate Impact Analysis. They’re used to understand what is impacted if something breaks or if something needs to change.
If CMDB implementers only populate their CMDBs with discoverable data, they can only see low-level connections between very technical CI Types. For example, they can see what operating systems and operating system versions are installed on all computers, on a network. If we want to upgrade operating systems on specific machines, we can now quickly identify which machines will have to be upgraded. However, we cannot see what Customers, Business Organizations or Business Functions might be impacted by such changes.
Populating the CMDB with non-discoverable CI Types, along with their corresponding relationships, provides the end users with far more powerful and meaningful reporting that is higher up the business Value Chain. If we have relationships between Computers and Applications and Customers, we can more easily see what specific Customers will be impacted by changes to computers.
Some challenge with Non-Discoverable CI Types
The real problem with Non-Discoverable CI Types is that, while it’s easy to load a few hundred or a few thousand individual non-discoverable CI Instance records into your CMDB, it becomes virtually impossible to manually create and maintain the relationships between them, each other, and discoverable technical CI Instances.
This is especially true in an environment that is constantly changing, which is more often the case than not for most enterprises. Every time new CI Instances are added to the enterprise or any time underlying infrastructure changes (for example an Application moves from one set of Servers to another), Semantic Relationships (i.e. CI Relationships) need to change, too. In addition to adding new relationships, relationships that were valid yesterday might be gone or changed, today. Keeping up with these types of changes, especially for Non-discoverable CI Types, is very difficult and often expensive.
Non-Discoverable Semantic Relationship Handling
Diving a little further into the Non-discoverable CI data problem, we see that the real problem is in how Semantic Relationships are created and maintained.
For example, if we have 1,000 Applications (i.e. 1,000 Application CI Instances) that are non-discoverable, imagine mapping each and every Application to its related set of Software CI Instances and to its related Server CI Instances. What is worse is that the data for Applications, Software, and Servers, is constantly changing, which means the relationships are constantly changing. Keeping up with these changes, manually, is just not viable. This issue with relationships is the PRIMARY reason most CMDB implementations never get to the point where they have high quality and usable non-discoverable data loaded into them.
Options for dealing with Non-Discoverable Data
So, if 3rd party ADTs don’t help with Non-Discoverable CI Types, CI Instances, and CI Relationships, what are our options?
Build Custom Software Discovery Solutions
One option is to build your own custom solutions to handle Non-discoverable CI Types and CI Instances. While this sounds easy to some people, it becomes complicated and expensive, over time, as more and more CI Types need to be added and accounted for. Even more important is that, if your business is Insurance, Finance, Health, Pharma, etc., building such custom tools is clearly not your enterprise’s core competency. This means your valuable resources will be spending time on problems that have nothing to do with your core business.
Use Seed Files
If you are going to follow the route of building your own custom discovery software, you may want to consider Seed Files to facilitate discovery. Seed Files can be created and updated by people and systems at the specific time a work function is performed. For example, when an Application (or an Application component) is deployed to a set of computing Servers, a Seed File can be placed on each Server to denote that those Servers have that Application deployed to them. Your custom build discover tools can now harvest data from your Seed Files and you can find a way to load that data into your CMDB.
Use Data Compilers for Non-Discoverable CI Types
Another option, and one that is highly recommended, is to use data compilers, which are built and tailored to address this problem. The IF4IT, for example, offers the NOUNZ Data Compiler, which automatically generates CMDB data and even entire CMDBs, directly from any data (discoverable or non-discoverable). These types of data compilers, based on the definition of simple rules, know how to harvest Semantic Relationships from data, in order to inter-relate and connect different CI Instances, regardless of their CI Types, together. This means they can deal with, both, discoverable and non-discoverable data, very easily.
NOTE: If you have already invested in an existing CMDB that you know your enterprise will not move away from, at least not in the short term, Data Compilers can be used to at least generate all the data for Non-discoverable CI Types, which can then be loaded into your existing CMDB. This means they can be used in addition to 3rd Party ADTs, where ADTs help you deal with what is discoverable and Data Compilers help you deal with what is not discoverable.
Summary and Conclusions
The above yields the following observations and conclusions…
- It is important to understand the differences between and value of Discoverable CI Types vs. Non-discoverable CI Types.
- Most discoverable CI Types and CI Instances can easily be handled by 3rd Party Automated Discovery Tools (ADTs).
- Non-discoverable types require a tremendous amount of maintenance to create and maintain semantic relationships between them and discoverable CI Types.
- Most CMDBs rarely get to the point where non-discoverable CI Types are loaded and highly usable.
- Data Compilers are an option for handing Non-discoverable CI Types, CI Instances, and CI Relationships.
You might also be interested in…
- Assigning Owners to all CI Types and CI Instances
- Understanding Configuration Item Types
- Agile CMDB
- The Enterprise Inventory Control Grid (EICG), which provides a list of key CI Types that are commonly collected and managed by most mature enterprises.
- Service Management: Service Categories (because Services will need to be loaded into your CMDB).
- White Paper: Key CMDB Use Cases and Case Studies