Category Archives: Change Management

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.

Talking SPML

Oddly enough the New Year has seen a spate of SPML discussions. James McGovern gets the whole thing kicked off here. Jackson Shaw adds his thoughts here, and makes the point that SaaS really needs federation and provisioning to work well.

Mark Diodotti (who has been following SPML for a long time) has some interesting thoughts about it here. Mark points out that SPML lacks built in authn and authz capabilities. This was an intentional design decision in both SPML 1.0 and 2.0 as it was felt at the time that authn and authz should be part of the web services infrastructure, not the provisioning standard. In retrospect that decision put too much faith in how well authn and authz standards would be adopted. This also points out the unique position that identity web services are in. They must be secured yet they must drive the security as well. It’s a real chicken-egg dilemma. Or to use the WSDM nomenclature, a real MUWS-MOWS dilemma.

Ian Glazer (a former colleague of mine at Access360 and who also served with me on the PSTC) wants to stop talking about federated provisioning. Ian makes the point that federated provisioning is not really any different than enterprise provisioning. Ian is correct in that they are basically the same, although there are some subtle differences in how they play out in deployment.

I really hope that these discussions lead to some real movement around leveraging SPML to enable SaaS services. I am always up for an SPML conversion. If you want to discuss SPML (or identity or change management), my work email is my first initial and last name at and my personal email is the same at

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.