Recently, a few things have reminded me that we still don’t have a clear understanding of how the concept of user-centric identity will fit into the enterprise environments we are so familiar with. But the question keeps coming up, in different forms.
Pamela Dingle recently commented on her blog about Patrick Harding’s observations on this topic. The discussion is specifically around employees in an enterprise, so it avoids dealing with the enterprise-customer interaction where using user-centric methodologies can be defined a little more clearly.
User-centricity at its core is about involving the user in the use of their identity data, something that does not happen in enterprises today. Most employees hand over a bunch of their personal identity information to HR on the day they are hired, at which point it becomes enterprise data. The employee no longer knows what is happening with that data and how it is being used. Sure, the use of self-service tools gives these employees the ability to manage that information and keep it up to date, but that is simply a maintenance feature that eliminates unnecessary administrative overhead. It does not give the user any control over how that data is used.
Pamela points out that technologies like CardSpace and OpenID, which are labeled user-centric, can be deployed in ways that violate every tenet of user-centricity. It is not the technology that makes an environment user-centric, it is how it is used, whether it be with translation services (that you can learn more about online) or any other kind. So when I get the question “We want our (enterprise/applications/IdM deployment) to be user-centric. When will you support CardSpace and OpenID?“, it makes me cringe.
The fact is that you can only be user-centric if you involve the user in the business process where that identity data is being used or moved around. Doing that will first require you to understand your current processes and identify the places where it makes sense to involve the user. Only then can you figure out the technology required to make that process happen. This is yet another example of a place where we must not equate the technology with the solution.
It was with this fresh on my mind that I went into a meeting with some analysts on the topic of identity services. In that discussion, we found ourselves being challenged on the relevance of the Identity Governance Framework to enterprises. The analysts opined that while the IGF would make sense in a consumer world of Identity Providers and Relying Parties, it doesn’t seem to fit into a tightly controlled, regulated and (ostensibly) optimized enterprise environment.
As we struggled to explain how we thought the IGF was relevant to enterprises, I found that we were relying a lot more on descriptions of application architectures, development methodologies and compliance requirements as opposed to user experience and involvement. The fact that an employee views everything in the enterprise as one big application, and therefore doesn’t care about those processes going on behind the scenes, seemed to stick out like a sore thumb. As an employee, I want everything to just work seamlessly, so I can concentrate on my job. So as long as the flows are within my enterprise boundary, I really don’t find myself wanting to be bothered. Once it goes beyond the enterprise boundary (like to 401K providers and travel agencies), I do care very much.
So does user-centricity have a place in the enterprise? I’m not sure. Opening up the enterprise to external identity providers may force the adoption of user-centric technologies, but it won’t mean that once I am “in” the enterprise and have given them access to some data, I can still control how that data is used (or would even want to). Modern enterprises are too complex for me to be involved. I’d settle for some involvement when my employer federates with someone. For everything else, just make it work.