IGF and LDAP, again

Phil Hunt has some good thoughts here on my recent post about IGF and LDAP. Just to be clear I am not suggesting that IGF replaces enterprise AD. But as I understand the some of the IGF proposals around the Identity Bus concept, IGF APIs would replace LDAP APIs on the client side. At least for new applications. From Phil’s post:

The nice thing about CARML is that it is just a declaration. There is nothing saying a CARML declaration cannot be created by hand for an existing application. Though we are working on an open source implementation, it does not have to be used for applications and infrastructure managers to receive benefits from IGF. The new API is really about creating appeal for developers. Developers want something very different than enterprises. They want to be able to write flexible applications without having to spend 90% of their time writing code to support varied deployment scenarios and varied protocols.

For business, the benefits of IGF are going to be mainly around risk management and privacy as demand to use personal information increases beyond current traditional enterprise directory content. Enterprises wanting to use identity-related information from HR systems or CRM systems already have to worry about legislative and regulatory issues. While manageable today, the processes are largely manual and forensic in nature. It’s a situation that cries out for standardization.

As I said, I wasn’t suggesting that IGF replaces AD. But if you expect developers to migrate to a new way for developing client applications you need to give them a compelling business case.

Let take a concrete example. Suppose an IT shop wants to build a replacement time card application. If the requirements are that the web app looks the current user up in AD and routes the time card to the person in the manager field for approval, we know what the problems are. There could be data integrity issues where the manager field is not getting properly updated. There can also be compliance issues.

So IGF can tell the app developer what the data quality is for the manager field. But what is the business value? They still need the information regardless of the data quality. Yes there is a compliance issue. But again, what is the business value? The manually process of noting the field access by the compliance person only needs to happen once.

Switching to a new identity API is going to require tools and training. That is going to come out of the project budget and schedule. What are you going to tell the project manager to convince him to commit budget and schedule?

We all agree that for enterprise identity data AD is the clear incumbent and that isn’t going to change anytime soon. But on the application side LDAP is also very likely the incumbent. And you are trying to change that.

All I was trying to get across (not well I fear), if that displacing an incumbent technology is very difficult. I personally hope it happens on the client API side. But my past experience working on identity service standards tell me it’s a big hill to climb.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s