Category Archives: CMDB

It’s the model stupid

William Vambenepe has a great write up on past and current IT management standards efforts here (and rifs on the famous Bill Clinton internal campaign motto):

I wish that rather than being 80% protocols and 20% models, the effort in the WS-based wave of IT management standards had been the other way around. So we’d have a bit more to show for our work, for example a clear, complete and useful way to capture the operational configuration of application delivery services (VPN, cache, SSL, compression, DoS protection…). Even if the actual specification turns out to not make it, its content should be able to inform its successor (in the same way that even if you don’t use CIM to model your server it is interesting to see what attributes CIM has for a server).

It’s less true with protocols. Either you use them (and they’re very valuable) or you don’t (and they’re largely irrelevant). They don’t capture domain knowledge that’s intrinsically valuable. What value does WSDM provide, for example, now that’s it’s collecting dust? How much will the experience inform its successor (other than trying to avoid the WS-Addressing disaster)? The trend today seems to be that a more direct use of HTTP (“REST”) will replace these protocols. Sure. Fine. But anyone who expects this break from the past to be a vaccination against past problems is in for a nasty surprise. Because, and I am repeating myself, it’s the model, stupid. Not the protocol. Something I (hopefully) explained in my comments on the Sun Cloud API (before I knew that caring about this API might actually become part of my day job) and something on which I’ll come back in a future post.

I can sympathize with William. I wish that in the SPML effort we had spent more time working on the model up front. The plan had always been to finalize the protocol and then work on the model. As a result the model work never really got properly addressed, although there is a possibility it might someday.

ChangeGear 4.0 is now released!

I haven’t been blogging much lately due to being in the final push on the ChangeGear 4.0 release. This release is quite an achievement for the ChangeGear team. In addition to the release, SunView Software has rolled out a great new web site.

If you are interested in Service Desk, Change Management, Release Management, or Configuration Management (CMDB) you should drop by and take a look. I’ll think you will like what you see.

If only, if only

I like skeptics. I like to consider myself one. I also thoroughly enjoy reading the IT Skeptic. But this borders on pure fantasy:

Then there is the question of the pace at which this beast is moving. Although the document referenced here is dated October 2008 the changelog ends in January 2008, and it is certainly the only output we have seen this year other than one(?) multi-vendor demo. There are zero commitments from DMTF or from the vendors for any sort of timeline for delivery of anything. As I have pointed out in the past,

“WARNING: vendors will waive this white paper around to overcome buyer resistance to a mixed-vendor solution. For example if you already have availablity monitoring from one of them, one of the other vendors will try to sell you their service desk and use this paper as a promise that the two will play nicely. “

All I could think of when I read this was “If only”. If only the vendors cared enough about interoperability standards to make it a selling point. Then you might eventually get real interoperability, even if it started as vaporware.

But the reality is the front line sales guys usually don’t know or care about standards, past checking boxes in an RFC. William Vambenepe sum’s it up nicely in this rebuttal:

Has anyone actually seen this happen? I am asking because so far, both at HP and Oracle, the only sales reps I have ever met who know of CMDBf heard about it from their customers. When asked about it, the sales person (or solutions engineer) sends a email to some internal mailing list asking “customer asking about something called cmdbf, do we do that?” and that’s how I get in touch with them. Not the other way around.

Also, if the objective really was to trick customers into “mixed-vendor solutions” then I also don’t really understand why vendors would go through the effort of collaborating on such a scheme since it’s a zero-sum game between them at the end.

I don’t mean this to be critical of the sales guys. They care (as they should) about the requirements the customers care about. Until the customers start making support for interoperability standards like CMDBf (in the ITSM space) and SPML (in the IdM space), these standards will never get robust implementation. And the customer will continue to get stuck with siloed solutions.

Reconcilable Differences

Having worked in both IdM and ITSM I am constantly struck by the similarities and how the same problems get reworked  over and over again in the two industries. For instance William Vambenepe has this to say about configuration item reconciliation:

Whether you call it a CMDB or some other name, any repository of IT model elements has the problem of establishing whether two entities are the same or not.

Which is exactly the same account reconciliation problem that provisioning vendors have struggled with for years. When a provisioning system discovers a Linux account with user ID jbohren, does it belong to me, or my father Joe Bohren? BTW, if you email to my first initial and last name at, it won’t reach me. If you do the same at it will.

It’s also the same problem that role management software is dealing with when trying to determine if roles in different systems represent the same logical business duty. Does the role named Accounting Manager represent the manager of the accounting department or is it the IT guy who manages the account software system?

Reconciliation is a big scalability problem in IdM and ITSM systems. Often there are too many orphaned items (items that can not be unambiguously matched to a known entity) for the IT staff to handle. Also determining what to do with orphaned items can be very difficult.

One interesting approach account to reconciliation is to let the account owners adopt the orphaned accounts. The adoption process would involve the owner provider the credentials to log into the account in a web page. If the system can verify that those are the correct credentials then, then that person is assumed (or allowed) to be the owner.

But this approach only works with accounts and account based systems. For now reconciling other orphaned items is still mostly a manual process. I would be curious to hear about solutions that other people have found for various reconciliation problems.

Good advice on CMDBs that sounds strangely familiar

George Spafford has this to say about CMDBs:

The truth is that a great many software-led configuration efforts that emphasized the technical merits of the CMDB have failed abysmally because the process requirements weren’t understood and addressed appropriately.

In response to this, tools vendors reacted in an unsurprising manner: they created a technology-led solution called “autodiscovery”. The premise is that by using autodiscovery tools to identify new, changed or deleted configuration items in production the CMDB will be current and accurate thus overcoming all the process problems. Guess what? The results have been far from ideal because it still does not negate the need for processes.

A fairy doesn’t appear at 2 A.M. in the data center and magically change configurations and move equipment. The fact is that someone made those changes and it is to everyone’s benefit to understand why. Simply pumping the changes blindly into the CMDB with autodiscovery is a recipe for disaster.

This should sound very familiar to anyone who has worked on IdM projects.

There are two take-aways from this. First, all of these wonderful enterprise tools require a process to be used effectively; and second it all comes down to people in the end.

Mostly authentication

Ashraf Motiwala relays a statistic that %90 of all virtual directory deployments are used for authentication only. If true (and I don’t doubt it), this really isn’t surprising. Most enterprise software doesn’t support LDAP for anything but authentication, and a lot doesn’t even do that.

As I have said repeatedly, this single biggest impediment to enterprise identity management is that enterprise software seldom supports the externalization of identity. And it’s not really the vendors fault. The vendors are spending their development dollars on the features that their customers are asking for. Until customers start making externalized identity a selection criteria, the vendors are going to just do the minimum, which for many is authentication.

For instance in the product I currently work on, ChangeGear, we support LDAP in three ways. We support authentication and user profiles via either Windows Integrated Authentication or generic LDAP. We also support AD for allowing the users to pick lists of impacted users and groups when creating or processing Change Management Requests (RFCs). Lastly we also support AD as one of the means of discovering assets to populate our CMDB.

There are a lot of other interesting things we could be doing with LDAP, but our customers have not expressed much interest in them.

Configured Identities

Here is an interesting post from Glenn O’Donnell of Forrester that argues the CMDB should contain identities (hat tip to Ryan Shopp):

Well, actually vice-versa! The configuration management database (CMDB) is a hot topic these days in IT. With my arrival at Forrester, I am ambitiously building upon the solid foundation of thought leadership my colleagues have built on CMDB. One topic I wish to address is the notion that people (yes, you and me) are configuration items within the whole CMDB discussion.

I find it interesting that nowhere in the article is the word identity used. I wonder if that was intentional? 

The more I work in the CMDB area (the product I currently work on, ChangeGear, has a CMDB) the more similarities I see with the concepts being discussed as an Identity Bus.

It’s a shame there aren’t more people that work on both the IdM and ITSM sides of the fence. Both groups are trying to solve some of the same problems but with different technologies and standards. I think some convergence between these two areas, especially around Identities, would be a very good thing.

A more skeptical view

I had recently mentioned MyCMDB here and speculated that perhaps this might be an example of what Enterprise 2.0 could really mean. The IT Skeptic, on the other hand, has a more colorful and skeptical view on the matter (hat tip to Ryan Shopp).

There are a lot of parallels to between a CMDB and an IdM system, so it will be interesting to watch how MyCMDB fairs. MyCMDB could be the canary in the coal mine for applying Web 2.0/Social Networking to IdM.

Perhaps a real Enterprise 2.0 application

A lot of what is touted as Enterprise 2.0 is just regurgitating a Social Network concept in a limited fashion. I don’t find corporate Wikis or other collaboration applications any more interesting than Microsoft Sharepoint or Messenger. That’s not to say they aren’t useful, I just don’t see where the real innovation is.  

But here is a possible enterprise 2.0 application that just might be the real deal. ManagedObjects is releasing myCMDB which turns the normal CMDB process inside out and puts managing the CMDB in the hands of the employees via a social networking interface. I haven’t looked into this in detail so it’s hard to tell how much is real and how much is hype at this point. It’s also too soon to tell if the social networking model will really work for managing a CMDB.

But it’s the most interesting Enterprise 2.0 application I have seen so far.

The intersection of identity and ITSM

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.]