Enterprise CMDB Requires Unique Solution

Report explains 5 critical technologies required of an enterprise CMDB, and details why so few products today deliver on them.

Franconia, NH, January 22, 2007 --(PR.com)-- A report published by itSM Solutions states that a variation of the multidimensional databases originally used in On Line Analytic Processing (OLAP) is more suited to CMDB functionality than On Line Transaction Processing (OLTP) technology found in relational database engines. 

The report claims that the nature of the CMDB application requires significant new technologies in addition to OLAP in order to handle the unique issue found within IT: data confrontation. 

According to Hank Marquis, CTO of itSM Solutions and author of the report titled “Enterprise CMDB”, selecting OLAP as a technology is just the starting point. “It's not as simple as OLTP vs OLAP. The next step is to realize that even with OLAP, a CMDB architecture has the very unique requirement for federation—connecting with multiple IT and business management systems—and this creates complex data confrontation issues.” 

Continues Marquis, “Unique to IT is the fact that usually more than one system contains the data needed, there are asset management, HR, ERP and other systems. These systems store different aspects of the same resources, and this creates issues when federating.” 

The first major requirement for a dimensional CMDB is federation. Federation is connecting to heterogeneous data sources and resolving which data are definitive. Marquis says, “The major issue with a federated CMDB system is data confrontation. It's common to have multiple applications and systems that overlap and monitor the same IT assets or store similar data, possible data inconsistencies and redundancies arise and require reconciliation.” 

Data stored in federated CMDB systems changes—sometimes slowly, sometimes swiftly. A CMDB system that can successfully federate and reconcile data must also be able to alert when it detects unauthorized changes (if any) and then synchronize its local store to the federated store. 

Finally, a CMDB system has to be able to display data to its administrators. Modeling is mapping and visualizing synthesized relationships that are IT service definitions. 

In summary, Marquis claims, “An enterprise CMDB is not a database, it is a complex software system that has to federate other data stores, manage data confrontation issues, reconcile alternate views of the same data, detect unauthorized changes, synchronize approved changes with its own metadata store, and be able to dynamically represent configurations graphically on demand. This is no small task, and also the reason there are so few true CMDB solutions available today.” 

About the Author:
Hank Marquis is a software industry pioneer with expertise in development of network and systems management platforms, database systems, and knowledge management/expert systems. He combines his software expertise with over 20 years of practical hands-on experience managing, organizing, and optimizing IT infrastructures and organizations. Hank holds the ITIL IT Service Manager certification with Distinction in Service Delivery. He is the author of two books on software development, and “How to Succeed with ITIL,” published by the Nichols Kuhn Group.

itSM Solutions LLC
Tammy Lyons
(617) 264-0946