One more time: Why the CMDB is not a 'thing'

Revisiting the notion of a configuration management database

Industry analysis by Beth Schultz, plus the latest news headlines.

Having written in more than one column that a CMDB is not a tree but a landscape and that a CMDB is not a “thing” – I feel compelled to revisit this discussion. No, I don’t intend to change my mind or recant, or attack any skeptics or critics of this notion. My concern is that since CMDB adoptions are on the rise the real value of a CMDB system is becoming obscured by, ironically, too much industry attention … of the wrong kind.

There seems to be a lot of attention on defining what these systems should do and contain, what is the magical checklist that separates a true CMDB from its faux counterparts, and a focus on data schema that is potentially good, as long as it’s not taken too seriously. The danger in this is a precious, Academie Francaise of the worst kind – a formal and ultimately rigid notion of something that is embryonic. To exaggerate (a little) let’s imagine the proud parents-to-be looking at a sonogram and immediately deciding what school the fetus should go to, what career it should follow (should it be a doctor or a lawyer) and what sort of spouse it should marry. In the CMDB we are dealing with embryonic, albeit metaphorically so, conditions so that it’s premature to try to create a platonically perfect formal structure around them.

Having said this, I’m going to put in my two cents on a few points that seem to be so far rather empirically borne out:

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Having written in more than one column that a CMDB is not a tree but a landscape and that a CMDB is not a “thing” – I feel compelled to revisit this discussion. No, I don’t intend to change my mind or recant, or attack any skeptics or critics of this notion. My concern is that since CMDB adoptions are on the rise the real value of a CMDB system is becoming obscured by, ironically, too much industry attention … of the wrong kind.

There seems to be a lot of attention on defining what these systems should do and contain, what is the magical checklist that separates a true CMDB from its faux counterparts, and a focus on data schema that is potentially good, as long as it’s not taken too seriously. The danger in this is a precious, Academie Francaise of the worst kind – a formal and ultimately rigid notion of something that is embryonic. To exaggerate (a little) let’s imagine the proud parents-to-be looking at a sonogram and immediately deciding what school the fetus should go to, what career it should follow (should it be a doctor or a lawyer) and what sort of spouse it should marry. In the CMDB we are dealing with embryonic, albeit metaphorically so, conditions so that it’s premature to try to create a platonically perfect formal structure around them.

Having said this, I’m going to put in my two cents on a few points that seem to be so far rather empirically borne out:

* For all of my ambivalence about the industry legislating what a CMDB should be too soon - the CMDB is nonetheless critically important. It is a foundation and enabler that will soon stand the entire IT management industry on its head.

* The CMDB is on the other hand not a “thing” – it’s a system in which politics, culture, organization, technology and products all come together. I would argue that you can’t buy a CMDB. You can purchase software that may be strategically useful in creating a CMDB system, but it’s not a matter of opening a box on Christmas morning and plugging in a new model train. To create even a phase one CMDB system, in most cases you need to engage multiple brands and multiple investments.

* CMDB systems cannot be achieved in binary fashion. They demand a phased approach that requires crawling rather than running. But intelligent crawling can net huge ROI. This means setting objectives that are both operationally and business aligned in incremental phases, each with its own agreed-upon criteria for success. And it requires executive buy-in, because the process will demand resource and organizational commitments, and ultimately a willingness to leverage a CMDB system for organizational transformation.

* The discussion of data schema comes next – but more as a logical idea than necessarily as a completely objectified system for managing data in a database. IT Infrastructure Library (ITIL) is moving towards a set of schema that are logical – and as such represent, shall we say, the “realm of recommended possibility.” But it would be a drastic mistake to assume that all CMDB systems should, in phase one, map specifically to these ITIL “schema,” just as it would be suicidal to initiate a CMDB based on ITIL’s overarching definition in its “configuration management” library. It would be, in the memorable words of one skeptic, “a Utopian vision that will collapse of its own weight.”

Schultz is a longtime IT journalist. You can email her or find her here.