Talking Identity

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

Thoughts?

My previous post on User-Centricity in the Enterprise generated some interesting responses in the blogosphere (see here). One thing that surprised me was the discourse equating (or focusing) user-centricity with user self-service. The message seemed to be that user-centricity is absolutely needed in the enterprise because we need to provide users in the enterprise self-service management capabilities that promote simplicity and convenience.

No one can argue against the importance of deploying good self-service management capabilities in the enterprise. In fact, we (Oracle) have very strong user self-service capabilities in our current IAM suite of products, and are putting a lot of focus on making these capabilities even better in our roadmap. But IMHO, user-centricity and user self-service are two different things.

User self-service is a common sense feature in an enterprise's architecture, not a methodology about data flow and usage. User-centricity is all about what happens after a user manages their identity information using self-service capabilities (though it isn't and shouldn't be restricted to only self-managed identity data). It is about the control we give them over the identity data as it is being used in the enterprise. Managing my user-centric controls should be part of the user self-service features available to me.

Johannes Ernst wrote a very articulate response (as usual) to my post that makes a very good argument for user-centric controls in the enterprise. But he also brings up one of the main issues that I believe holds back the discussion on enterprise user-centricity - the unclear boundary on what is identity information. I'll touch upon that in my next post.

It has been a while since I posted, but not because there isn't anything to talk about. In fact, there may be too much to talk about, especially since all the discussion about user-centricity in the enterprise generated so much food for thought.

No, I have been deeply engaged in discussions on the future of IdM in fusion architecture, a discussion that necessitated an all-too-intense trip to Oracle HQ for some much needed discussions. And since I was in HQ, people took the opportunity to engage in planning discussions for future versions of OIM, leading to a pretty hectic week, and some deliverables that have kept me from going back to the blogs for a while.

So when I finally got back to Google Reader, I saw some responses from Pamela Dingle (who was responsible for kicking off my blog thread) and Dave Kearns. While I always appreciate their perspective, I do have to disagree with some of the points that they are making, maybe because I come from a different point of view (the vendor instead of the implementor/analyst).

First off, let me say that I completely agree with Pamela when she says that an enterprise should consider tools that solve real business problems they have, not imaginary problems they think they have to address because of some marketing kool-aid they have been drinking.

But in her post, Pamela says the following:

"The idea that 'user-centric' has to mean anything at all in an Enterprise context, just makes no sense."

Huh? User-centric has to mean something (unless Pamela is saying that it is pure marketing gobbledygook conjured up to create a market for yet more products), and therefore it has to mean something for an enterprise. What exactly it means is what was being discussed in the blog thread that she labeled "philosophical".

To me, the term "user-centric" has always been about the philosophy (and therefore process) of how identity is handled. It promotes transparency, and empowers the identity stakeholder to exert control over the usage of their identity data. No tool is "user-centric", but there are tools that can help businesses employ identity in a user-centric manner. And to me, that means that the processes that use identity have to be user-centric.

Pamela says:

"If these tools were built properly, the philosophy should be inherent, not resultant - in other words, you should get user centricity as part and parcel, the kernel of the technology that makes it user-centric shouldn't be subtractable - but user centricity doesn't have to be the actual problem that is solved along the way."

To assume that tools will solve issues of process is wrong. Tools give enterprises the means to enact and deploy the business processes and policies that they want to put in place. They do NOT provide the enterprise the processes and policies themselves. Deploying a provisioning system does not solve your SOX problem. Deploying it in conformance with processes and policies that the enterprise defines (independent of the tool) is what provides SOX compliance. I already pointed out that too many enterprises confuse the tool with the solution. And the so-called user-centric tools are the same way. Pamela herself has pointed out that one can deploy these tools in ways that are in no way user-centric (doesn't that imply that user-centric means something, by the way).

Debating and understanding the philosophy (not the tool) is important because that is what will define the processes that the enterprise would put in place, and the processes would then determine the right tools for the job. Pamela is correct in pointing out that tools don't come first, business solutions do. And as tool vendors, it is our job to understand (forecast) the philosophy that will drive the solutions so that we can figure out what capabilities we want to build into our products.

Here is an example that I am dealing with right now.

I am sure everyone that reads my blogs knows that one of the projects Oracle is championing is the Identity Governance Framework that provides a declarative way for stakeholders in identity data to publish rules around how identity data is used and disseminated. It is a direct outgrowth of the need for privacy controls, and as such it has to play in the space we call user-centric identity.

Well, one of the ongoing discussions at Oracle is how the IGF fits into the future of our provisioning product. With a true identity services architecture many years away, and legacy applications going nowhere anytime soon, enterprises will continue to have provisioning products synchronizing identity data from one place (source) to another (provisioning targets) for some time to come. How does the IGF play into this? Does the workflow that dictates how identity data flows from the source HR application to a bug tracking system downstream have to accommodate the IGF in it? Without understanding where enterprises are going to go with this user-centric stuff, it is difficult for us to determine the correct capabilities to introduce into the product. Sure, we could make a few assumptions, even talk to a few of our biggest customers. But the best way for a vendor to succeed is to be aware of the trends in the consumer space, the emerging thought processes (and philosophies), and factor those into our determinations.

Pamela and Dave are clamoring for solutions, as well they should. But what solution should I (as a vendor) be providing? Understanding that is the intent of my discussion. I need clarity on what it means when an enterprise says that they want to embrace this vision of user-centric identity management. I know what my end-goal is: an architecture built on identity services that eliminates most of the problems we are trying to solve. But until we can achieve that, I still need to figure out a whole lot of intermediate steps that will get us there and still solve the most pressing problems we have around privacy, efficiency and integrity.