An interview with Mark Thompson, Director of Product Management & Marketing
How would you define CMDB Data Quality and what types of data are important?
The answer, in some ways, is dependent on what the customer brings to the equation. Our customers’ typical enterprise environments consist of 40 to 50 million records. ALL types of data are important, which is why we handle over 230 sources of data. So CMDB quality, in these cases, is ensuring that all 50 million records, regardless of their type or source, are 100% accurate.
More specifically, the heart of CMDB Quality is that all configuration items (CIs) populated into the CMDB are validated and non-duplicate and their corresponding CI elements are accurately maintained; that reference structures need to be constrained lists whose integrity is maintained; and that CI-to-CI relationships are populated and maintained appropriately throughout the lifecycle of the configuration item.
CMDB Quality is a tough term to define because it encompasses people, process and technology. We believe the core principles of current, accurate and complete data must be adhered to in order to achieve the highest probability of Service Management success. During my years in the industry working with many different customers, the mature companies realize that there’s no “easy button” for anything as important as data accuracy and they have to embrace it as a continual service improvement process.
When it comes to data, I recommend utilizing as many different data types and data sources as possible to obtain multiple viewpoints for the CIs under configuration management. While many people think Discovery and Dependency Mapping is the Holy Grail, the hard fact is that no discovery or dependency mapping tool is flawless and therefore will never cover the entire, ever-changing landscape of software, custom applications, relationships and infrastructure devices. Many customers fail to account for the fact many items in the environment are not discoverable. More importantly is the fact that discovery and dependency mapping tools are not designed to address issues and challenges with data quality or data accuracy. Blazent has proven, time and time again that we can handle as many data types and sources as the customer can provide and ensure the data is complete and accurate before it’s populated into the CMDB.
That said, mature customers also realize that just because you can populate or hold accurate data in the CMDB, it does not mean it should be in the CMDB. The CMDB is not a dumping ground and should only store the important data needed to properly support the configuration management process.
When is the right time to think about data quality — before, during or after implementing a CMDB?
Of course the earlier you get started, the less overall effort is required to achieve appropriate data quality levels. But it is never too late to adopt a continuous improvement initiative around data quality, because at the end of the day, the overall value of your Service Management platform is dependent on it. We always recommend beginning the data quality process before the CMDB is implemented, as this will provide the smoothest glide path to achieving a world-class data quality for your CMDB.
A CMDB that is current, accurate and complete is the linchpin for success in a Service Management deployment. Without it, all of the other processes linked to the CMDB will certainly not achieve their ultimate value. If you’ve already implemented a CMDB, don’t worry: it’s never too late to tackle your data accuracy issues. Blazent can certainly help remediate data issues after CMDB implementation, but it does shift the focus of resources and can be a more time-consuming exercise than addressing it prior to implementation.
How does Blazent look at all of those 230+ sources of data?
Each one of those source systems has attributes. We atomize the data, breaking it down into a granular level. Then we do comparisons to make sure we’re dealing with the most accurate data possible. Our second step is called identity management – that’s aligning data for comparative analysis. We look at attributes like serial number; asset tag, host names, and IP address which are replicated across the IT environment. Our Data Evolution Process enables us to look at all of those to determine this one’s accurate, and that one’s not.
Individual names are not always unique. A database instance, for example, may not be unique, nor is the database it resides on unique. The name of the server or cluster it resides on may not be unique, but we make sure every element is truly, uniquely identified. We analyze the data for foreign keys – relationships that exist between different systems. Then we go through the purification process. We’re able to create a single record based on the knowledge acquired from all the data sources. And, finally, with our fifth step, we have a historicity process. We are taking and maintaining all data from every source across time and storing it in Hadoop. This enables us to provide the foundation of quality data that every enterprise needs for predictive analytics.
At Blazent, we understand the principles, technologies and processes of Data Quality Management better than any other company in the industry. The CMDB is only one area of our expertise, but with the explosion of Service Management market we chose to intensify our focus on this area to elevate our presence and provide the domain expertise that our customers expect in a partnership with their vendors. With over a dozen years in the industry and many successful customer deployments across various industries, sizes and maturity levels Blazent is committed to continually innovating our approach to tackle new challenges in data quality management.