The following is an excerpt from a cross-posted email, summarizing some of my concerns around current CMDB practices...
My major concern is the consolidated topological model of complex IT systems, and the semantics for describing it. I believe that major enterprises should maintain only one of these models, supporting multiple views. To the extent that ITIL and ITSM specify the CMDB as the container of this topology, I object to current CMDB vendor practice and advocate a standards-based approach.
The major premise I have is that 30 years of data management, the development of the relational model, entity-relationship modeling, and object-oriented class modeling, needs to be reflected in current CMDB practice. Instead we're getting simplistic tools that store generic graphs. As I've noted in my articles, I have sat in front of tools that would let the operator create a dependency between a database trigger and a RAM chip, and in fact provide no means for preventing such nonsense. If it's a CI (Configuration Item, the fundamental unit in Configuration Management) and you are working with any of several tools claiming to provide CMDB services, you can have an any-to-any relationship with anything else.
The any-to-any relationship is a standing red flag among seasoned data architects--subscribers to dm-discuss will know what I'm talking about. Many data professionals have encountered the eager developer who has just figured out that all they need is two tables:
Thing Relationship Type
for the deluxe model :-)
Such concepts certainly have their place, but when you start working with them IMHO you are officially running with scissors, moving into concepts more familiar to tools and systems programming. Decades of data management practice show that the careless use of such architectures in business systems is a Bad Idea. (I've seen the pain firsthand.) That's why one can make a career out of business data architecture, and why well designed large scale databases often have hundreds or thousands of tables -- not just four! Surely IT is a complex enough domain to merit more than four tables...or metaclasses, for the OMG folk among us...
More precisely, the DBMS engines themselves are based on any to any semantics with declarative constraints, and the whole point of data modeling is to use this generality as a basis for building sensible, problem-domain oriented models.
But building such models is a LOT of work, particularly hard in the IT domain, and what I see the CMDB vendors doing is short-circuiting this careful analysis. (Of course, there are standards, but they might prevent the customer from being locked in...)
The fact that the ITIL section on configuration management does not discuss the issue of information modeling or declarative constraints has not helped matters; while I realize that ITIL was not intended as an architectural specification, that is in fact how it has been read by more than one vendor. In turn, since ITIL tends to be driven from the ops side of the house, the unsuspecting customers may not understand data architecture principles nor have much contact with colleagues who could provide an informed opinion on the subject.
This is why a black belt team emerges when such tools are purchased: a consensus starts to build that, "yes, this service (as in SLA) is a CI, and yes, this hard drive is a CI, but we are not going to directly link the two - instead, we will put the drive in a SAN cabinet, allocate it to a mount point, deploy a database to it, assign the database to an application system, and finally create a dependency between the SLA service and that application." But no automatic constraints enforce such relationships; they are simply embedded in the group consensus that this is the way to do things. Automating such a group consensus is exactly what data architecture (or OO class design) is all about!!
See https://www.tdan.com/i025hy04.htm for a more detailed analysis.