Featured Article
A Cure for CMDB Pain
by Matthew Zito, Chief Scientist

The hype around CMDB is hitting critical mass, as hordes of people convinced they needed a CMDB are now in the midst of implementing one.  The CMDB vendors came in, got everyone excited about the prospect of a single source of truth for every piece of technology in IT, and now the reality is starting to sink in.

The reality is, of course, that CMDBs are really hard to build and manage.  Step 1 is typically to use an application discovery tool to begin filling in the gaps.  However, even software has a difficult time describing all of the complex interdependencies between servers, applications, storage, and network objects.  For example, an application discovery tool might identify that an application server is talking to an Oracle database, but what is that database doing?  What is its schema like?  What patch level is it?  Is it dev, test, or production?  If this information isn’t available to the CMDB tool, it’s up to a human to start filling this information in, database by database, and then maintaining that on an ongoing basis.

So, given that CMDBs are this hard to set up and manage, what’s the value?  Is it worth it?  Implementing a CMDB can be a little bit like an ERP system – lots of pain upfront, but with long-term benefits in terms of productivity and insight into how the business and technology are running.  However, one very specific way of improving CMDB deployment, manageability, and functionality is through implementing a federated CMDB model.  A federated CMDB is one where multiple independent domain-specific CMDBs, like one for desktops, one for servers, one for databases, run independently and provide deep, rich information to those specific users who care about that level of information.  A subset of that information is skimmed off and pushed into a centralized CMDB, which gets to hold higher-level information the business types care about.

With a federated CMDB model, database teams can create their own CMDB, storing the information they need to do their jobs, in as much or as little detail as they care about.  Using a tool like GridApp Clarity, DBA teams can discover and inventory their entire database infrastructure, how it’s configured, what it’s doing, and can add metadata about other areas of interest.  For example, a DBA group might add custom fields for their databases around what application a particular database is powering, or mark what backup server and schedule a particular database is on.

Thanks to a real-time collection mechanism, all of this information is being tracked on an ongoing basis.  This is critical so that DBAs can look not just at what is the current state of all of the databases, but look at how they were, and even compare changes over time.  The other dramatic benefit of a CMDB for databases is that the target users of that CMDB – DBAs – already are experts at dealing with data models, data stores, and generating intelligence out of that information.  That’s why Clarity stores its CMDB data in a plain vanilla Oracle database, with an easy-to-use schema.  Empowering DBAs to directly access the critical configuration data they need only helps drive value.

That’s our CMDB strategy – help ease the pain of overall CMDB deployment (at least for the DBAs) by making rolling out a database CMDB as easy as possible, having it update in real-time, making it extensible for custom metadata, and giving DBAs direct access to that data so they can make their own reports, integrate with other systems, and actually empower them to make better decisions.  Let the other departments deal with manually mapping thousands of configuration items – DBAs can focus on getting things done.

<< back