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.
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.
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.
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 tampabay.rr.com, it won’t reach me. If you do the same at yahoo.com 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.
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.
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.
Posted in Authentication, Change Management, CMDB, Identity, Identity Management, LDAP, Software, Standards, Virtual Directory
Tagged Authentication, Change Management, ChangeGear, Identity, Identity Management, ITIL, ITSM
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.