In spite of the array of confusing opinions, bad press, and general contentiousness that has recently surrounded Configuration Management Database (CMDB) deployments, EMA is seeing a resurgence of interest in both the CMDB and the more federated Configuration Management System (CMS).
Yet providing guidance amidst this storm of confusion is challenging, in large part because the values of a CMDB/CMS are multi-dimensional, evolve over time, and hence often lead to what EMA calls the "blind men and the elephant" syndrome — in which only a part of the beast is understood to the detriment of the whole. This is just as true for CMDB detractors (and there are still plenty of those) as well as CMDB apostles who too often prioritize faith over reality.
A core CMDB might be defined as: a central data store of critical IT environmental information, with links to such information stored in other systems, to document the location, location, configuration and interdependency of key IT assets, both physical and applications. The CMDB can support the change process by identifying interdependencies, can improve regression testing by capturing insights surrounding these interdependencies, and can be helpful in diagnosing problems impacted by changes to the IT environment.
In a book project supporting a methodology for more effective CMDB/CMS deployments currently underway (and due out early next year), we are combining the notion of the CMDB, CMS and to some degree the notion of the Service Knowledge Management System (SKMS) with the terms "CMDB System".
All three — CMDB, CMS and SKMS — are of course concepts and terms created by the IT Infrastructure Library (ITIL) designed to support an environment in which configuration-related and other interdependencies across infrastructure and applications can be captured, reconciled and analyzed in support of a wide array of IT processes and requirements.
One way to view the CMDB System initiative is to compare it to building a superhighway, often at a time when the IT equivalent of dirt roads are still prevalent. As such, a CMDB System does not just require advances in technology, but advances in IT processes and at times even organizational and cultural shifts so that IT can work more cohesively in support of services.
In order to unify these three critical areas — technology, process and organization — EMA has developed an eight-step methodology inclusive of "dialogs" and "conversations" that in themselves can bring huge value to an IT organization. We will revisit this methodology in a later blog.
Technologically, the CMDB System taken as a whole is a means for reconciling multiple "trusted sources" to capture physical and logical service interdependencies. As such, its roots have been in data management and service modeling. This is evolving to become more inclusive of discovery, automation, analytics, and other technologies.
For instance, in some cases, advanced Application Discovery and Dependency Mapping solutions capable of assimilating and reconciling many multiple data sources are serving effectively as First Phase CMDB System deployments. Fortunately, the notion that the larger project should be viewed in terms of a single, physical data store — in which to pour everything under the sun and then try to make sense out of it — is beginning to fade away. In its place we are beginning to se new, more federated, and dynamic approaches.
To emphasize this, I'd like to end with a few paragraphs — from an EMA consulting report with recommendations to one of our clients several years ago:
"It is very important to understand that the CMDB by itself does very little by way of delivering the promised benefits. It is only through gathering, organizing, managing, and using the information and knowledge — taking action — that CMDB benefits appear. This is a critical distinction and one of the single most important items to remember. This is even more important when you consider the requirement for process surrounding the use of the CMDB — something many people take for granted or skip altogether.
"A CMDB is therefore not a thing, but rather a system — and there is no such thing as standalone CMDB regardless of marketing statements made by over-zealous vendors. Rather, the CMDB System consists of a collection of logical and physical constituents. How these constituents come together as a decision support system requires strong process control.
"The scope of the CMDB System, as it evolves, touches all facets of IT, providing benefit to all users of IT data. Like the vendors, users see the value of the CMDB System based on the specific requirements that they have for its use."
EMA also has provided consulting clients with a short list of what a CMDB System, is not. These include:
- A silver bullet
- A single technology investment
- A single physical database for every bit of configuration-related data across the entire IT spectrum
- A software deployment — e.g. put it on a server, get it up and running, read the manual, and you're done
- A generic and hence, pure embodiment of change management processes
- A generic answer to generic problems
- A one-use-case solution
CMDBs have often been called a "single source of truth" — somewhat erroneously, as truth, both poetically and in reality, is often elusive and changeable. I recommend thinking of the CMDB System instead as a "system of relevance" — a more modest but more useful concept, reinforcing the idea that the CMDB System requires "what's relevant" to enable a given use case, from change management, to asset management, to service impact management, among others.
Truth — pure, abstract, and eternal — will invariably turn out to be a bit of an overreach.
Relevance, by contrast, will allow you to phase in what you need as you need it, and optimize the many choices and demands that cloud, agile and other trends are imposing on you and your organization.
This is the first in a series of blogs aimed at looking at the bigger CMDB System picture and soliciting dialog, debate and discussion among APMdigest readers:
CMDB System Use Cases - Part One
Related Links:
