This blog has been published in partnership with Cherwell.
Managing IT infrastructure today can feel like a game of Tetris. Operations staff are constantly managing the addition of new pieces, trying to quickly determine how to best position them while the clock is ticking before the next round drops. Ultimately, decisions made early on impact what comes later and vice versa. Unfortunately for IT pros, keeping track of all “the pieces” (aka assets) is infinitely more challenging in the real world than it is in Tetris -- and it all happens much faster and at much greater risk to your business.
Many enterprises struggle to fully understand all of the IT assets they own and operate, which can negatively impact a bunch of things, including the mean time to repair issues (a.k.a., MTTR), change management, and service delivery. Technologies like cloud, virtualization, containers, and micro-services have further compounded complexity.
Back in the day, early IT pros created the Configuration Management Database (CMDB) to help counteract the challenges of tracking and managing ever-changing IT assets. However, the CMDB has had its share of well-documented headaches, as well. Let’s explore why.
A Brief History of the CMDB
The CMDB first came into vogue when IT service professionals realized that part of the process of repairing devices needed to include documentation of how they were being fixed, along with any potential impact to other components.
It wasn’t initially called a CMDB when the idea first emerged in the 1980s as part of the IT Infrastructure Library (ITIL), which the UK government established as a best practice framework to help facilitate IT services. The early framework simply called for a generic database to maintain records around IT service management (ITSM).
The term CMDB was officially introduced as part of ITIL Version 2. IT pros realized that inventories for assets weren’t sufficient, particularly when it came to change control. Today, the CMDB is still considered to be part and parcel of ITSM at its core.
With Progress Comes Challenge
While the idea of the CMDB was championed, the implementation was rather dicey, to say the least. The CMDB fell victim to its inherent complexity and bulkiness. Having to maintain a CMDB manually meant that it was pretty much outdated by the time the last keystrokes were made.
Maintenance protocols weren’t well enforced either. When a new piece of equipment was installed, the installer would update the CMDB… and then someone else would come along and install a piece of software and then they would update the CMDB record again… and then a new application service required yet another set of hands to make updates – and so on. In the early days of the CMDB, there wasn’t effective governance or trust in place to back it up. There was also a lack of knowledge around where subsequently dependent components were located and who owned them.
Understandably, a lot of people started lamenting the demise of the CMDB. Even as recently as 2016, this Cherwell blog questioned whether the CMDB is dead. It also notably points to the significance of discovery and dependency mapping in ensuring a successful implementation to save your CMDB from an untimely death. (More on that in a moment.)
Rocky history aside, the idea of the CMDB is fundamentally a good one. When executed well, the CMDB should be a trusted source providing an updated view of IT devices and relationships. However, when not executed well, inaccurate information can proliferate and data redundancies can run rampant, which then creates a dangerous basis for decisions and introduces unnecessary risk. Essentially, the CMDB follows that old adage of garbage in, garbage out. An inaccurate CMDB amounts to a major waste of time and resources. And what IT enterprise today can afford that?
Next-Gen Problem Solvers
As enterprise IT grows increasingly more intricate in the face of mounting demands for improved efficiency, so does the need for robust auto-discovery and automated dependency mapping. However, it’s not an any-tool-will-do kind of solution. There are many legacy ITOM/ITOA discovery tools, but many lack flexibility and inclusivity. They also can’t handle complex IT environments with diverse tech stacks comprising a multitude of vendors, domains, and technologies. Meanwhile, many elements of ITSM are contingent on effective discovery.
You might ask why auto-discovery of the diverse data and devices across hybrid IT environments is so crucial? Quite simply, because it helps IT pros assemble and maintain a reliable, updated inventory of assets and their relationships. This information empowers teams to make the best possible decisions when it comes to troubleshooting, incident response, change management, budgeting, capacity planning, maintenance, asset management, and more.
With modern auto-discovery and dependency mapping solutions, IT pros can finally realize the true promise of the CMDB. These tools not only yield an accurate, up-to-date CMDB, but also provide deep visibility by generating comprehensive visualizations of the network and the devices on it, applications and services, and the relationships and interdependencies between them. With detailed visual maps of the application landscape and all of the underlying components at their fingertips, IT pros can finally do their jobs more effectively, with greater confidence and speed.
An updated CMDB is also critical for organizations looking to embrace new technologies like AIOps. These tools deliver predictive insights and execute preventative, automated actions on the path to self-healing IT. Clearly, getting your CMDB in order should be a top priority – one that delivers value both immediately and in the future.
Learn more about getting your CMDB right and laying the cornerstone for ITSM success on our upcoming webinar with Cherwell: “Slay Your CMDB Demons and Climb the IT Operational Ladder,” hosted live on March 19, 10am PT/1pm ET/6pm GT.
