The Complicated History of CMDBs
The one thing all Configuration Management Databases (CMDB) have in common is that for them to be of any use, they have to be populated with Configuration Items (CI). And there’s only two ways to populate any database: have people do it, or have technology do it.
The history of CMDBs is littered with organizations hiring people to manually populate it. Some companies spend millions of dollars on full-time salaried employees to fill in Excel spreadsheets in a fruitless attempt to get their CMDB in a “working state,” and in the end, all they had to show for it was a CMDB riddled with inevitable human errors, which are the cause of 80% of outages. If only there were an alternative.
In the modern data center, where virtual machine (VM) instances come and go on demand, asking people to manually keep a CMDB accurate up-to-the-minute just isn’t feasible. Technology is the only viable solution. But that too has had a history of misfires.
It seems pretty straight forward: have technology automatically discover CIs in real time and populate and de-populate the database in response to what’s happening. Here’s been the problem with that up until now. No single tool could discover everything, which meant to discover your entire infrastructure, you needed more than one, and often more than not, a couple of different tools.
So, all you had to do was acquire all the tools to discover all your CIs. That’s not as easy as it sounds. First, not all the discovery tools talked to a given CMDB, which meant you needed some ad hoc way of getting the data each tool discovered into the CMDB. Second, not all discovery tools talked to each other. That meant there was a good chance there would be overlaps, with multiple tools discovering the same CIs, resulting in a CMDB with duplicates, triplicates, name variations, all of which had to be cleaned up manually.
There was also a good chance using multiple discovery tools would result in data gaps with no tools discovering some CIs. And it wasn’t always clear where the gaps were, which meant that you were right back facing a variation of the original problem – these inconsistency have to be searched for, and rectified manually.
So, while discovery with multiple tools might automatically populate a CMDB with CIs, it wasn’t always clear how accurate that data was. And even if you did somehow patch together a combination of tools and scripts and manual labor to make sure you got every CI into the CMDB, you were still missing a great big piece of valuable information: the interrelationships.
Standalone discovery tools tend to perpetuate data silos. They grab the data and populate the CMDB, but even in the best cases, have no way of knowing or mapping the interrelationships between CIs discovered by other tools.
In the modern data center, understanding the relationships between CIs is every bit as important as understanding what those CIs actually are.
Technology Has Transformed CMDBs
It’s easy to see why in the early days of the CMDB (circa 2002), both users and their employers alike had given up on the CMDB. If the goal was an up-to-the-minute single source of truth, the reality was an up-to-the-minute unknown collection of unrelated CIs. And if that wasn’t bad enough, for CMDBs to be really useful, the information within them must be actionable – and the output those legacy tools produced simply wasn’t.
Furthermore, for a CMDB to succeed, its information should be available to other tools and processes. An ideal CMDB would do more than simply hold information; it should also be able to trigger events and automate tasks. Plus, it would be great if it were integrated into other applications like IT Service Management (ITSM) so it can also initiate actions. At the end of the day, the purpose of a CMDB is not to hold data, it’s to solve problems.
The biggest change in the modern CMDB application is that it went from being a data repository to a problem-solving tool. A a single source of truth that can be used to improve operations, track assets and manage inventory.
Modern Use Cases for the Modern CMDB
The modern CMDB supports modern use cases.
Use Case: Simplify Audits and Ensure Compliance
CMDBs with built-in audit rectification functionality provide a very efficient means for addressing audit discrepancies. To ensure compliance, modern CMDBs can detect prohibited software, track contract agreements and expiration dates. They can also send alerts in response to unauthorized network access (e.g., WiFi).
In short, a well-designed CMDB offers the opportunity to reduce the time and manpower required for standard operational processes.
Use Case: Capacity Planning
Do you know if you have sufficient capacity for forecasted growth? Modern CMDBs can help you with that.
Today, the data found in CMDBs can be used to balance peak load capacity, locating idle infrastructure to minimize costs and eliminate waste. They can also be used to ensure you’ve got the capacity for future growth by automatically locating and suggesting space with available power for new equipment. The modern CMDB is an essential tool for managing the capacity of growing enterprises.
Use Case: Facilitate Successful Migrations
At some point you may have to move part or all of your data center to a new facility, or even to the cloud. Wouldn’t it be nice to be able to use the CMDB to make that happen painlessly?
Today, CMDBs can be used to get a clear understanding of where applications are running and what are their inter-dependencies. That’s a necessary first step in planning for any migration. With that information in hand, you can confidently migrate to a new facility or to the cloud while ensuring all applications and dependencies are accounted for.
Use Case: Manage Asset Life Cycles
A modern CMDB is the perfect vehicle to manage the life cycle of your assets, from the day they’re purchased until the day they’re retired.
CMDBs can be used to associate service contracts with assets to ensure you’re covered for the life of the product. They can also automatically generate QR codes for tracking physical inventory and manage the life cycle of software licenses.
Use Case: Gain Application Intelligence
Do you know all the applications deployed in your environment? Their function? Their manufacturer? Their version number? You can with today’s CMDB.
Modern CMDBs can associate applications with clients, business units, servers, etc. It knows what ports applications are communicating on and with what protocol. More importantly, it can understand and display their dependencies to hardware, OSes and other applications.
New Challenges for CMDBs
The modern data center is constantly evolving. It started on premises, moved to the cloud and evolved into hybrid. It took advantage of virtualization, then containerization and now it’s moving to server-less computing. That means there will be new classes of data and new sets of inter-relationships among that data. And that means modern CMDBs are tasked to keep up. To do so it will have to address three challenges.
Challenge #1: Total, Automatic Discovery
The modern CMDB must be capable of total, automatic discovery. It must be able to automatically collect entries for every CI and establish the relationship and dependencies between them. But, it must also allow for manual updating in those one-off situations with unique security constraints which make auto-discovery impossible.
The modern CMDB is built with the cloud in mind. It has native support for virtualization platforms and native support for public and private clouds. It uses agent and agentless auto-discovery with support for multiple protocols (e.g., SNMP, WMI). Working in tandem, agent and agentless auto-discovery ensure every CI can be discovered with the least amount of human intervention.
Challenge #2: Continuous Discovery
The modern CMDB must be able to capture a moving target. The life cycle of data is short and changes quickly. VMs come and go; mobile devices hop on and off; and software gets installed and updated, often without notice.
The same capabilities that are used for total, automatic discovery are also be capable of continuous discovery. And that discovery is capable of being scheduled, across the enterprise, according to needs, resulting in a system that is always audit ready.
Challenge #3: Making the Data Useful
Perhaps the most important attribute of the modern CMDB is its ability to make its data useful. To make CMDB data useful you have to be able to analyze it, display it and share it with other applications. In other words, it cannot just be a database.
The modern CMDB natively includes the ability to generate complex visualizations and custom reports. It is also able to seamlessly integrate with third-party tools. It can do automation via webhooks and RESTful APIs, which allow for custom integrations and special use cases that go beyond the capabilities provided out of the box.
Perhaps you’ve tried to use a CMDB in the past and it didn’t go so well. But that doesn’t mean it isn’t time to give it another try. The fully-integrated, modern CMDB has gone way beyond just a database. It’s now an essential tool for management and control in the modern data center. Don’t you think it’s time to give the CMDB another chance?
To learn how Device42’s CMDB elegantly handles all the challenges to provide your with an up-to-the-minute single source of truth, try it free for 30 days right here.