Overview – What is a CMDB?
A CMDB (Configuration Management DataBase) contains all pertinent information about all possible aspects of an information technology system used by an organization as well as the interrelationships between all components within a dedicated database.
A CMDB provides a holistic, “single source of truth” view of the aforementioned data, and various means of visualizing the data. Each component in a CMDB is known as a CI (Configuration Item[s]), which can be anything in the data center e.g. hardware, software, user’s, documentation, notes, etc, with many CI incorporating various combinations of the former.
Furthermore, the modern generation of CMDB focuses on automatically, and continuously discovering changes within the data center as they occur, keeping CI and relationship data up to date without human intervention, which has come to be known as “continuous auto discovery”. This is in contrast to the last generation CMDB, which required significant, consistent man-hour investments to stay up to date, and when overlooked, their data often going “stale”.
Why a CMDB?
A CMDB can significantly reduce the risk of IT downtime, MTTR if downtime should occur, and can also lower the associated costs. One of our customers figured that downtime cost them $1 million USD – per minute! They were able to reduce the amount of downtime they experienced, and the associated costs by 70% (!) by leveraging the cohesive view of their environment provided by Device42, and using the insight they gained to reconcile their existing infrastructure.
Investment in a CMDB will pay off only when its information is both accurate and actionable. Consequently, without the associated tools that Device42 offers, such as discovery, inventory and application dependency mapping technologies that enable data center teams to monitor the environments in real time or close to it, the value of a CMDB is limited. Device42 unlocks the full potential of CMDB.
Common Myths – What a CMDB is, and what a CMDB is not
- A CMDB [Configuration Management DataBase] is a centralized, authoritative “Single Source of Truth” on the state of your infrastructure. It will not magically fix all issues related to ITSM in your company, though it can typically integrate with and benefit the ITSM process.
- A CMDB does NOT have to encompass all IT assets and Components ever purchased by your enterprise as well as all ITSM functions, nor does it need to include all its data in one single database. Be clear on your goals as far as what data you are trying to store in the CMDB, and define “good enough” – 100% is not realistic. A CMDB is perfectly useful even when used only to manage a subset of your infrastructure, be it network & servers, but not desktops, or all end-user desktops and laptops, but not servers. Multiple instances of multiple databases are fine [federate, don’t replicate!], and multiple departments can individually utilize a CMDB to hold the data that is important to them. If you already have an ITSM system you love, stick with it – maybe you can integrate it to gain some benefit, but by all means don’t switch products for the sake of centralizing! Though a CMDB becomes more powerful with more data, federated data is more useful than duplicated data, and solving real problems is always (and should always be) the real end goal of any CMDB project.
- A CMDB does not have to be an “all hands on deck”, gigantic project that takes years to plan and implement. The modern CMDB can handle much of the heavy lifting automatically, and a single qualified IT professional or migrator with the right credentials can handle setup and population of CMDB data. Obviously, you will get more value out of your CMDB if more people use it, but that can be allowed to develop organically over time – as people learn of the existence of the data, they will use it. Instead of inventing problems for the CMDB to solve, use it to solve one or two real problems that really exist today, and go from there.
- A CMDB needs to be built by technical people – sort of. If a CMDB has been built right, the programming that was done to create the product will allow, at the end of the day, any competent end user with the right systems credentials in hand and a problem to solve the ability to populate and utilize a CMDB. At most, cooperation from your technical department should be all that is necessary to get a CMDB up and running. Though it takes plumbers and electricians to make the modern building habitable, you don’t need to call one every time you want to adjust the temperature in the building, nor do you need to be a certified plumber to wash your hands; the same holds true for a properly designed CMDB.
Implementation – Getting a CMDB up and Running
CMDB Implementation can be a misnomer, in that a CMDB’s implementation doesn’t have a well defined “end”. Ongoing CMDB maintenance is what keeps CMDB CI data fresh, and therefore useful. Many a project have failed due to CMDB implementation being treated as a one-and-done process, in which the software is installed, populated, and then left to become stale — and therefore deemed a failure.
In general, however, CMDB implementation can be simplified to:
- “Installation” – Install and configure CMDB software in your environment
- “Discovery” – Collect all relevant data
- “Population” – Create CI entries for each discovered entity and populate with relevant attributes
- “Post-processing” – Create relationships and dependencies between the discovered CIs.
It’s worth noting, though, that individual CMDB vendor’s offering can differ (a little or monumentally), depending on the step.
Comparing CMDBs – From one vendor to the next
CMDBs tend to differ from vendor to vendor in a few big ways. The first is how they’re delivered to the customer, while a second big one is how they’re populated:
Installations tend to fall into three main categories:
- On premise software that is installed on a server
- An on premise appliance, which may be either physical or virtual
- SaaS – Software as a Service, where the vendor hosts the software instance on your behalf, and you do little to no software setup.
Discoveries, likewise, tend to also differ greatly between vendors.
- “Manual Discovery” – Discovery and populate all CI’s manually
- “Partial-automatic Discovery” – Certain CI types can be discovered, and others must be manually populated, as above.
- “Full Automatic Discovery” – The vendor supports most or all hardware in your environment, both on premise & cloud, and supports custom discovery definitions that allow discovery to be ‘taught’ (programmed) to discover custom CIs.
Population of the CMDB tends to be a bit more homogenized, being more dependent on the level of discovery supported. Most all systems allow for manual CI entry, and the discovery methods (see above) will typically populate their respective databases with discovered data automatically. One main difference, however, exists among the more enterprise-class CMDBs that support custom discovery. They may or may not feature a RESTful API, or any API at all, forcing any customization to happen within their provided toolset. In contrast, when an API is available, truly custom modules can be programmed to populate & manipulate the data within the CMDB.
Post processing ability is another large differentiator. Aside from API’s offered by the more advanced systems discussed prior, which allow truly custom manipulation of CMDB data, standard offerings otherwise vary among their out of the box ability to associate collected data intelligently. More advanced systems can sort and associate collected data automatically, and can create extensive inter-dependency and impact lists and charts. More advanced systems still vary in their abilities to display this data, some offering simple list views, while others offer advanced visualizations. The ability to produce reports of varying complexity is another differentiator when it comes to post processing, with some systems offering no reporting whatsoever, while others offer comprehensive, schedulable and customizable reporting functionality.
Common CMDB Challenges – Ask your vendor about each of these
CMDB challenges, by and large, can be broken down into three separate problems:
- Getting all the relevant data into the CMDB
- Collecting all relevant data that should be in the CMDB
- Creating entries for every CI (Configuration Item)
- Creating relationships, dependencies, etc.
- Maintaining the data in the CMDB
- The previously collected data changes regularly, and sometimes quickly
- All CI’s must be kept up to date as they change, move, new ones are added, and old ones are retired.
- Maintenance of the relationships and dependencies to account for changes detailed in (a) and (b). This tends to be the most significant undertaking.
- Making the data useful
- Many CMDBs are just databases
- Complex tools are necessary for advanced discovery and useful visualizations. These traits by and large differentiate products, as these are included with modern, enterprise grade CMDB’s, whilst those that may appear to be bargains require you to create these tools yourself.
- Integrating other tools with your CMDB, leveraging the data to enrich other processes like ITSM and automation via Webhooks & a Powerful RESTful API. These are also features not found on many run of the mill, entry-level CMDBs.
Benefits of a CMDB: The value they bring to your organization
Gain Application Intelligence
- Know all applications deployed within your environment, their manufacturer or owner, the version number, and their function
- Associate Applications with clients or business units
- Associate Applications with Servers
- Application dependencies – hardware or software based
- Know what ports applications are communicating on and with what protocol
Breeze through Audits & Ensure Compliance
- Device42’s audit rectification functionality provides a very efficient means for handling audit rectification on the fly
- Detect prohibited software and generate alerts
- Track License agreements and expiration dates
- No WiFi connection needed with Rack Audit Sheets!
- Reduce audit time up to 7-fold
- No massive time and manpower investments to get a single use point in time snapshot
Capacity Planning
- Ensure you’ve got the capacity for future growth
- Balance peak load capacity with idle infrastructure to minimize costs
- Automatically locate space with available power for new equipment
Dramatically Reduce Data Entry
- Device42’s continuous auto-discovery is always watching for new changes to your infrastructure
- Along with auto-discovery, Included import tools and 3rd party integrations do the majority of the hard, manual work for you
Facilitate Successful Migrations
- Get a clear understanding of where applications are running and the interdependencies involved
- Confidently migrate to a new facility or to the cloud
- Ensure all dependencies are accounted for when updating platforms
- Avoid embarrassing, potentially costly downtime!
Manage Asset Life Cycles
- Record lifecycle from the day of purchase to the day it’s retired
- Associate service contracts with the assets they apply to
- Automatically generate SmartPhone-readable QR codes for managing physical inventory
- Track software licenses & ensure compliance
- Confidently retire or consolidate assets by understanding dependencies & business impact
Reduce risk and downtime / potential outages
- Most downtime is caused by botched maintenance
- Understanding interdependencies between hardware and software is the key to forming a cohesive plan and avoiding mistakes
- Understand all connections interdependencies, physical and virtual, between servers and applications
Support and Drive Automation
- Give automation tools access to data about all your IT assets and their interrelationships
- Quickly integrate scripts with Device42’s well documented RESTful API
- Webhooks can trigger an action for nearly any event in your infrastructure
- In concert with tools like RunDeck, Puppet, Chef, StackStorm, and Zapier, a DevOps team has everything they need to fully automate IT Processes
Get all of the above, and so much more: Test Drive Device42 Today!
Now that you know what a CMDB is, let’s talk a bit more about Device42! Simply put, Device42 was conceived as a next-generation CMDB. So much more than the previous generation offerings, Device42 was conceived by and is built by data-center engineers — both for IT engineers, other IT folks, and non-engineers alike … in many roles! It truly has something to offer just about everyone.
Conceived with the cloud, automation, virtualization, infrastructure as code, and containers in mind. It not only helps you to manage, document, and track your entire infrastructure, but it also plays vital role in helping you to make decisions, orchestrate changes, and drive efficiency.
What are you waiting for?!
