* Revisiting the notion of a configuration management database
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.”
* I believe that the single most defining thing in creating a CMDB system today is identifying trusted sources of information, or sources of record. This is the next step, once you’ve created a sense of objectives and scope – and it’s the one above all that brings you immediate, intrinsic value. You don’t necessarily have to purchase anything to do this, though it may lead to purchases once you’ve understood what you’ve got and what you need to get going.
By defining a trusted source for, say, network configuration, system configuration, Layer 2 topology, asset information, service impact, or system/network/application performance, you’ve begun a radically new way of thinking. You’ve declared that across all of IT, not just within a single silo, a certain tool or solution will be the “trusted source” for a given aspect of a certain configuration item. To do this you have to identify an owner who is responsible for maintaining and supporting that trusted source. Think what this brings you, with or without a fancier set of CMDB-related initiatives! It eliminates redundancy, stimulates collaboration, and forces debates that have been swept under the carpets for decades in many cases. And in doing this – watch the power grab as IT individuals duck and cover when faced with the notion of sharing and responsibility.
* CMDB systems are just that – systems. Rather than a hub and spoke view, I would suggest that as CMDB systems evolve, they will more closely resemble the human nervous system. They will include a number of “intelligent” clusters, as information about assets and accounting, change and configuration, service impact, performance and … (fill in the blank) come together. This would be based on pragmatically determined vehicles for reconciling and accessing information, and only in some cases actually integrating information into a single, physical data store. While this may seem overwhelming at first, it should be viewed as just the opposite – liberating. It means that you should feel free to start anywhere where you can see real value. And it means that you can tell all those pundits with their checklists about what a platonically perfect CMDB system “is” and “isn’t,” to come back in 10 years – when they may just know what they’re talking about.
