There has been an interesting discussion recently about the practice of application developers wanting to use SQL as a means of querying identity information rather than LDAP. You can read Kim Cameron’s thoughts about this here and Dave Kearns’ response here.
I don’t want to get into the whole LDAP vs SQL debate. Really what’s the point? LDAP has been declared the COBOL of identity and obviously SQL is the COBOL of data query languages. Since they are both really just COBOL, why argue?
But I would like to point out one application where issues behind this debate play out in the real world. That is the Configuration Management DB (or CMDB). The term CMDB really means two things. First it is the conceptual term in ITIL for the DB that stores the configuration for the infrastructure that is needed to deliver services. Second, it is the term given to a wide range of products from companies such as BMC, CA, and IBM, as well as a variety of smaller vendors.
The CMDB is intended to be the central data repository for ITSM applications such as Configuration Management, Change Management, Incident Management, and Capacity Management. A CMDB is a collection of Configuration Items (CIs). While each CMDB vendor defines CIs differently, they typically contain the following types information:
- configuration data
- Ownership (who is responsibl for this CI)
- Relationship to other CIs
If you are interested in IdM, number 2 should jump out at you. Identity is an important part of a CMDB. Not only is the ownership part of a CI identity, identities may indeed by CIs themselves. For instance it’s not uncommon for one CI to represent a Unix system that is related to CIs for each account on that system.
As a general practice, CMDBs are implemented as relational DBs with associated management software and APIs (even though relational DBs are really the COBOL of data storage). Some CMDB vendors that are also IdM vendors have products that synchronize their CMDB with their IdM products. BMC has just such a product that pulls accounts from their IdM system and populates them into their CMDB as CIs.
Which is exactly what this discussion is all about.
In theory one could develop ITSM software that used a Virtual Directory approach to access the CMDB data and identity data. I think that would be an interesting and novel approach to the problem. But to date I am not aware of any ITSM vendor that has taken that approach.
Today if you are in the ITSM world you will either have a disconnect between your CMDB and your live identity data, or you will synchronize them. That’s not to say that won’t change. It likely will change, and the change may be something called CMDBf, but I will leave that for another time.
[Full Disclosure: my current employer, SunView Software, sells an ITSM system that includes a CMDB.]