More evidence that the theoretical critique of current CMDBs is reflected in people's practical difficulties:
It's been reported to me that a large firm in my area that uses a prominent CMDB tool has determined that its conceptual flexibility is very hard to manage. They've had to lock data entry down to a very small group of configuration management "black belts."
This is a natural consequence of an overly generic data structure; what these people are essentially doing is building a more precise, de facto consensus information model ("metamodel," if you will) which they are enforcing through their group process and joint understanding. This is IMHO an unsustainable approach. They are forced into this because the tool does not allow this to be done automatically through declarative constraints, which is how one ought to manage complex data, according to well-established data management principles.
The scale of the configuration management problem is huge, and to capture and maintain such a mesh of data in a cost-effective way, one needs a tool that will enforce sensible data relationships when being used by a variety of staff (e.g., offshore resources).
Again, the fundamental issue here is that CMDB tools vendors have taken the ITIL requirements literally as data schema requirements, and are basically delivering simplistic graph metamodels. From discussing the situation with longtime ITIL thought leaders, it's clear to me that this was never intended by those who built the standard. See my TDAN article for more detail on the metamodel question.
Usual rant: I don't think that Configuration Management will ever meet its goals without adopting much more explicitly defined metamodel semantics, such as those the OMG has been painstakingly building.
