provided by: 
Originally published at Internet.com Last month I introduced the idea that the IT management industry is at a tipping point in which Lego-like integrations of management investments are forcing new architectural innovations as well as adaptations in IT processes to support more collaborative, cross-domain environments.
I also suggested that this is not occurring at lightning speed. Profound transformations of this kind-more significant than the shift from mainframe to client/server and distributed computing-evolve over a number of years and sometimes require more than a full decade to see them in perspective.
Last month I also suggested the growth in CMDB systems (configuration management database) is arguably the most significant bellwether in this transformation. In this column I'll explain why and provide a few pointers on how to take advantage of the "CMDB Tidal Wave."
What's It All About
Okay, so what really is a CMDB System, is it really a tidal wave and, if so, why? Answering the last two questions first: Over the past several years EMA has been actively involved in both researching CMDB adoptions and working actively with CMDB deployments to help organizations plan their strategies and set appropriate first-phase goals.
Our data shows that about 30% of our respondents were not interested in CMDBs, and the other 70% divided almost equally between those who had specific plans or deployments in place and those who had interest but no specific plans.
This year's research has targeted actual adopters and we see a parallel ratio where about 50% are in active planning and 50% are in deployment. Most are in relatively early stages with about 15% showing two-to-three year deployments.
Given the fact that just four years ago the acronym CMDB would have been affiliated only with ITIL with far fewer than 10% in planning or deployment, I would say what we're seeing is indeed a tidal wave.
Now tackling the first question: What is a CMDB? Well, in ITIL's Service Support library, 7.9.1, it states: "The CMDB contains details about the attributes and the history of each CI (or configuration item) and details of the important relationships between CIs."
(Note: "Configuration Items" and their attributes are the critical infrastructure and service components-from critical servers and network devices to application services and their various interdependencies-relevant to the CMDB system.)
In Service Support 7.3.7, it states: "The CMDB should hold the relationships between all system components, including Incidents, Problems, Known Errors, Changes and Releases. The CMDB also contains information about Incidents, Known Errors and Problems, and corporate data about employees, suppliers, locations and business units."
Throughout its libraries, ITIL presents an enlightened vision from its process-centric perspective on how a common set of resources providing visibility into service to business to infrastructure interdependencies could enable virtually any process to become more efficient, consistent and responsible. As the next version of ITIL becomes published this "system-like vision" will become even more explicit.
However, ITIL itself is not the prime driver for CMDB adoptions. EMA research shows that reasons for going forward are the desire to integrate data from multiple solutions (58%); whereas support for ITIL best practices as a driver was only at 23%.
This is because CMDB systems really have two parents: ITIL is one (the formal and perhaps more legitimate parent). But the second parent is architectural; finding a way to integrate and reconcile management solutions in a manner that actually works.
This is not a new. It is age old, but we are finally reaching the "tipping point" when technologies, business objectives, best practice and process awareness, and the increasingly dynamic nature of designing, deploying and supporting IT services are leading towards new ways of thinking and working.
The centricity of the CMDB in all this is so pronounced that even last year awareness and interest in CMDBs was a good 10-percentage points ahead of awareness and interest in ITIL itself.
Whether the ascendancy of CMDB awareness over ITIL is a good thing or a bad thing is to some degree a question that misses the point. The two are still inextricably intertwined, and no CMDB deployments that EMA has worked with or researched have succeeded without attention to process; usually a mixture of ITIL with COBIT and sometimes Six Sigma.
The real point to make is that both CMDB and ITIL are themselves enablers to achieve greater operational efficiencies, better business alignment, and improved services.
Foggy at Best
But the CMDB tidal wave remains confusing. Not only because of its secret, "other" parent, but because successful real world adoptions reveal the term CMDB itself can lead to significant confusion.
Just for starters, configuration management in ITIL doesn't refer to making configuration changes in the sense that most of the industry defines it, that's ITIL's "release management."
In fact, the most common business objective for early and near-term CMDB systems is to unify processes with Change Management and Control with ITIL's Incident Management so that important IT services are not negatively impacted by change.
However, longer-term, many IT managers aspire to unify real-time service impact management, SLM and BSM, across an array of different management sources as an extension of the CMDB System.
In this way, they seek to achieve trusted, cohesive insights into discovered reality to compare and contrast with desired state or approved versions of software levels, devices and device configurations as they map to application services.
In other words, the CMDB becomes a federated integration of carefully defined "trusted sources" to provide dynamic insights into "things as they should be" versus "things as they are."
The power of this can be enormous. Changes can be managed, controlled and validated with accompanying savings in operational costs, and mean time between failure (MTBF). In one instance, a CMDB reduced MTTR (mean time to repair) 70% when downtime was costing a financial services organization a million dollars a minute.
Still, the confusion remains. How can all this be summed up by the curious phrase configuration management database? The answer is it can't. In trying to compress a very long discussion into three terms, EMA has evolved the following CMDB taxonomy:
Core CMDB - A repository in which desired-state information resides.
CMDB System - A system which allows core CMDB data to be contrasted with discovered information about CIs and their attributes via a metadata directory.
Citizen CMDB - A constituent component of a broader CMDB system that is not core, either by virtue of its being focused exclusively on discovered "truth" without support for process control and review, or by virtue of its being domain centric (e.g. focused only on release management and control for key servers ).
Of these visions, it is the CMDB System that reflects the true CMDB tidal wave. Such a system is absolutely federated, absolutely multi-brand, and absolutely revolutionary in its implications for how IT will operate, how it will evolve as a culture, and how it will adopt technology in the future.
Dennis Drogseth is a vice president and leads Enterprise Management Associates' New Hampshire office. A driving force in establishing EMA's New England presence, Drogseth is also the Network Services practice leader.
Author: Dennis Drogseth
Read article at Internet.com site