Earl Perkins

I recently completed some interactions with clients who asked the same particular question regarding identity & access management. In one form or another, it can be paraphrased as “are there any business justifications for IAM that we can use as a starting point for developing our own?” Related questions centered around drivers and benefits, communicating the value of IAM to the business, etc. This remains a very common question even in late 2009, which tells me that a real, consistent and reusuable template for IAM business justification remains elusive to most seekers, even within the Gartner customer community.

I say “within our community” because one would assume that IF Gartner had written a definitive piece of research on this topic that the Gartner customer would never or seldom need to ask this question, and that is truly not the case: they still do. Whether I am speaking to Gartner customers or potential customers– even vendors who want to install IAM for themselves (!), the question is a frequent one. I would even dare to guess (based on reading experience and conversations with my colleagues in other analyst firms) that a similar situation exists for customers and readers everywhere.

Sure, I’ve seen press articles with a title that include “IAM business justification”, and they do a decent job at outlining key drivers of IAM and some of the benefits, but those articles usually have two consistent characteristics: (1) they are PRIMARILY about the key drivers rather than benefits, and (2) when benefits are discussed, they are seldom tied to objective, measurable metrics, the type of metrics that business decisionmakers like to see before signing over a couple of million in dollars, euros, or yen to such an effort. So what’s my point here? After all, I’m covering well-trod ground.

I suppose there’s several reasons why I am writing about this now.

1- We need to accept the fact that IAM is not a clearly defined, well-bounded set of applications and services that lend themselves easily or conveniently to a traditional justification model. Rather it is a loosely-aggregated set of solutions and services that can be combined in different use cases to deliver a measurable result, but that result is seldom known until the use case and corresponding solution set is chosen, and the permutations are extensive. That does NOT mean that a justification is fiction, it just means that it’s harder than we would like;

2- If the first premise is true, could we ‘build’ a justification from mini-justifications when we choose the solution set components, i.e. does each component have it’s own justification story? Maybe. We do know that early successes in (for example) single sign-on and password management centered around operations streamlining that did yield measurable savings. I do have a sense from talking to clients who implemented what they considered successful access management solutions (e.g. web access management, strong authentication) that they were able to quantify results fairly well– it was when they tried doing so in higher-level functions (e.g. provisioning, role management, identity audit reporting) that it become a challenge in permutations;

3- Do customers focus too much on operational efficiency to the exclusion of possible justifications in the process or governance area of IT? The answer is ‘maybe’. While we would like to think that IAM has moved beyond its “pipes and pumps” view by our main customers, the fact is that we not produced enough in the way of identity intelligence, risk management and workflow optimization to warrant (yet) a seat at the big-boy table when discussing matters of IT governance or business process improvement. We’re close, though (e.g. compliance reporting), and perhaps it’s important that we include a justification rigor to run concurrent with efforts to deliver these higher-level IAM functions. (I’m actually giving advice to myself to ensure future research in these areas reflects this, so consider this a ‘note to self’ comment as well as one to you.)

Enough rambling for now. It remains an issue. We have a responsibility to either put it to rest once and for all with formal research or declare it to be like the square root of -1: undefined. I’m not ready to do any such declaration. Customers need more than what is available today. That’s the call to action.