User-Centricity is a Philosophy, not a Solution

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.