Our theme was “You Are Here”, or the corollary I like to use to that was (and is) “Where are you?”. In other words, where are you in your project or program to delivering some enterprise value from IAM?  You could tell that there were still many enterprises struggling to some degree with more sophisticated aspects of IAM, e.g. role management or governance-specific concerns. I was a bit surprised, however, by the number that were still getting a start in IAM. They are primarily what you might classify as “mid-range” enterprises, from 2500-25,000 employees, and they do have basic, manually-driven IAM systems to some degree. But the automation isn’t there yet, and the increasing pressures of a more complex environment and more demands for their time and their services drives them to some level of automation.

My favorite parts of the summit were the two user roundtables I was privileged to host on role management and entitlement management. The conversations in both sessions (between 17-23 people in each) centered around role management. There was a small percent in each session (between 3-6 attendees) that had already tackled the issues surrounding role management, and they were questioned mercilessly on how they got started, how they defined certain elements in the project (including a definition of ’role’) and other questions about how to ‘do’ role management. There were no discussions regarding entitlement management, which was telling in and of itself.

These sessions told me a lot about the current progress clients were making in the assignment and administration of entitlements, and what kind of research publication was still needed for Gartner to deliver to help those who had not started. It also told me that role management, in whatever form, is alive and well, and there were increasing numbers of enterprises tackling this issue. They were universal in their belief that it was a “non-trivial task”, i.e. it would require much hard work and devotion to the initiative. Most importantly, it revealed what many of us already knew– it was not so much a technical initiative as it was an enterprise initiative to align policy, controls, process, organization and technology to reach deep into the enterprise with its impact. If I learned nothing else from these roundtable sessions, that was abundantly clear.

Finally, this event helps set the stage for 2010 and beyond– IAM is definitely evolving into something useful to and part of the enterprise. Whether it turns out to be a rich green field of opportunity or a weed-filled obstacle course is up to all of us.

First, it’s important to put the IAM part of the discussion in context with the major decision Oracle made to acquire Sun. In the great tradition of my favorite philosopher Dirty Harry, “a man’s got to know his limitations”. In this context, it means that the role of IAM in the Oracle decision to buy Sun was practically non-existent. Other Gartner research highlights the key areas that made the go-no go decision for acquiring Sun, and if IAM was even on it, it was dead-last. So let’s put the discussion about what Oracle will do with Sun IAM in the “oh yeah, we got this too” category. I’m not trying to be rude, I’m just trying to highlight the boundaries of this discussion and avoid conspiracy theory.

Second, one has to consider what kind of products we’re talking about and what historical evidence you may have to draw upon to help you do any kind of analysis on what may happen. We’re talking about products (in IAM) that overlap almost perfectly with existing products in Oracle’s portfolio. What usually happens to such products? We could try falling back on other trite sayings like “To the victor belong the spoils”, but what I’m really going to suggest may be counter-intuitive. I actually think that in spite of the overlap, there’s less reason (from historical evidence) to believe that this automatically spells doom or dismemberment of the the Sun IAM suite. Now why might one conclude that?

Oracle’s first mission in life is not to support international standards. It isn’t to consolidate and streamline the market and provide fewer choices for customers. It isn’t even to provide a one-stop shop for most IT needs. Oracle’s first mission is to make money, bluntly. To the extent other things can be done that assist in that (e.g. taking good care of customers) fine, but we are a free-enterprise society. If I look at it from that perspective, and I look at the several thousand IAM customers Sun has acquired over the years, I detect a distinct desire on the part of Oracle to maintain recurring revenue from those customers as one of its main priorities– particularly in an area that I received as a bonus part of a larger deal. This means that any snap judgments about which products to merge, which products to discontinue, which services to consolidate, all are going to take a little bit longer than you might suspect, and the final decisions may surprise you.

Having feature overlap isn’t the only kind of overlap discussion to have. One must also look at the customer profile, and to understand where Sun and Oracle overlaps occur. This means horizontal across industries (i.e. how many more banks has Sun sold to than Oracle, for example, and so on), vertical across customer size (small business, corporate, enterprise) and structure (centralized, distributed, decentralized). There are a number of variables to consider, with one really important question in mind: how much overlap occurs between Oracle and Sun products in potential customer markets, and is there a way to leverage two pretty good weapons to “divide and conquer”? Further, is there a shorter path to taking over competitor customer markets by approaching it with two weapons than with one? Which takes less time? Let’s be pragmatic here, not technologically elegant just to be elegant. There’s little return in that.

Third, play the scenarios out and estimate the timing. Let’s assume scenario 1 is “keep the Sun portfolio intact and sell– to different market segments or sectors, but in any case continue development and support” and scenario 2 may be “begin systematic review and integration of products wanted by Oracle, discard the rest”. (There are several other logical variations, but this is a blog, not a research note, so let’s be– pragmatic.) If scenario 1 does occur, it buys Oracle time to review what they have, build a long-term integration/migration strategy, and implement that over several releases of the product — say at least five to be safe. Assume one major release a year, it buys them 5 years to settle the existing customer base and offer continued opportunities for new Sun customer acquisitions. Scenario 2 is a much longer, more involved process (that is, if it’s done right) to align architectures, styles, approaches, workflows to a common future architecture, or to systematically gut the Sun product (or the Oracle product, for that matter) and do “best of breed” selection. Again, this takes a long time to do, and I would still estimate at least 5 years to reach a viable final roadmap state.

This means that Sun customers have a fairly long planning cycle– if these assumptions of future movement are reasonably accurate or logical. It also means those potential customers who have chosen Sun or are considering Sun aren’t automatically discouraged from doing so. As an analyst, I’m keen on seeing the process by which vendor selection is done not be unduly influenced by uncertainty. It is logical to be careful, methodical, and even conservative in product selections. But do not let undue uncertainty about futures that really are futures affect what may be a good choice for your enterprise. I find it a bit disturbing that consideration of Sun identity solutions is affected more by the length of time this acquisition is taking than in the real factors customers should use in such a decision process. Sun’s solutions are good ones, the people providing the solutions are very good at what they do, and it distresses me to see the company caught in the limbo of uncertainty and suffering for the wrong reasons as a result. This would be the case for any vendor caught in such a situation if the solutions they offer are viable and are likely to remain viable for a long time. I am not showing favoritism to Sun (just ask them, they’ll tell you they get bashed plenty when we perceive they’ve earned it), just stating a fact applicable to any vendor in this situation. If you must consider the future in your vendor choices (and you must) make them based on risk and informed likelihood, not artificially induced uncertainty.

Please let us know your views on this topic either way.

It was a privilege being there– the depth and variety of customers and vendors was much more extensive than in specific security and identity management events that I normally attend. But the context such variety provided gave me some new perspectives on the identity concerns of clients more than ever. Below is a comment or two about those perspectives:

1- IAM is still relatively new to the big scheme of “infrastructure management”, and it’s multi-faceted solutions (some for infrastructure, some for business management) demand more rigor than we afford it today. Have you ever experienced the problem with memory when you try to think of the correct answer, but an incorrect answer “gets in the way”, i.e. you keep thinking of that same word or phrase you know is wrong, but can’t clear it to get to the correct answer? The thinking about IAM is like that today– we have essentially an answer for what it is as perhaps a set of utilities for IT administration, or a set of reports for compliance needs, when it has grown past that. The youth of IAM prevents us from exercising a solution’s full potential, and is something we must correct. The wrong answer must be cleared out the way to make room for the correct one;

2- There should be NO discussion about “IT and the business”– IT IS the business, is part of the business, has always been part of the business, and should act like they’re part of it. This is why we consistently see IAM treated as some kind of plumbing first for IT administrators and others to get their IT job done and/or to make the IT job easier for IT—– NO! First, it’s more than that, and second, we consistently cede a valuable seat at the table of business decision-making when we perceive IAM’s value as merely that of a utility. Certainly, I’m the first to say that we as IAM professionals must know our place in IT and in IT security, but by the same token we have gradually reached a level of recognition as a contributor to accountability in the enterprise– knowing who can do what and how, and being held accountable for those actions (i.e. accesses). IT is the business– and IAM is not just IT.

3- Simple is hard. The means by which we in IAM can summarize this value of the discipline to those who want problems solved for them still eludes us. The 3×5 card, the elevator pitch, the 2 minute value statement– we bury decisionmakers, stakeholders and budget holders in PowerPoint minutiae, and as my college John Pescatore says, describe the problem very well without providing an answer to it. While describing the problem can sometimes be hard,  describing answers to it that are effective can be harder. When IAM professionals get that one shot to justify their budget requests and do so on behalf of the business, they have to be succinct, to the point, and —- well, be the business people we know we are and can be. Talk like it. And bring some answers, not some problem statements.

There are a lot of other perspectives, and they will no doubt make up some future comments in future blogs on lessons learned at Symposium. Many of these were not new lessons, but hearing them from countless customers who face them on a day-to-day basis brings focus to your purpose as an analyst.  It’s not enough to try to be a ‘prophet’– you also have to be a good problem solver, and/or recognize solutions when you see them and spread the word.

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.

The keynote at the summit is titled “The Death of IAM and the Loss of Identity Innocence:   A  Review of Program Maturity, Services-Driven Change, and New Era Threats”. That’s a whopper of a title (sorry about that) that tries to be a little more provocative about what many have considered infrastructure “plumbing”. Why? It is an attempt to garner the attention the issues deserve.

By death, we mean the passing of the “early childhood” of IAM and the move into adolescence, with all of the drama and volatility that comes with it, whether human, animal, or market. Looking at the general slate of basic offerings in IAM (web access management, user provisioning, single sign-on, etc.) we see a level of maturity being reached in terms of technology that requires a matching set of best practices (I still like calling them “success practices” when my peers stop laughing at me) processes, and organizational requirements to be considered truly mature. We’re learning, but it is a painful process, involving ROI calculations, skills inventories, benchmarking and contract restructuring, among other things. We’re attempting to structure what was a complex planning and implementation activity into an operational activity with lifecycle characteristics, while introducing yet another layer of technologies and processes to prepare for the next phase of IAM that addresses true business requirements in a direct fashion.

In this respect, I keeping thinking of the concepts of formal program maturity and of  ‘access accountability’. For program maturity to be truly successful, it takes more than a product or a good set of workflows in provisioning– you actually need a structured approach involving an IAM program maturity model. This model can work with some quantitative or at least rational qualitative measures to know where you are in the progression to maturity. I believe that the primary driver in compliance is actually going to become part of a broader approach to making access accountable, whether coarse-grained, “net-grained”, or fine-grained. This accountability achievement can be done in part by a more robust identity intelligence and reporting framework that overlays basic IAM. Such a framework could provide analytics, forensics, and historical aspects of the act of access, and use that information to hold the proper stakeholders accountable for that access.

That’s but one of the topics of our discussions this November, basically good, old-fashion meat-and-potatoes production IAM. I can’t wait to understand what customers think and what they know about these topics.

Our upcoming IAM Summit in San Diego in November gives rise to reflection on the state of IAM technology and design, and will be discussed there through a number of venues. In this blog, I’d like to introduce one of those reflections. It may seem obvious to many of you, but I tend to document the obvious just to be sure. In this case, let’s take a brief glimpse at the boundaries of IAM.

While there may be some disagreement about the definition of IAM still, many would agree that the market of products consists of a “core” of products that address access, administration and ‘intelligence’ and then a more nebulous set of technologies that are currently considered to be IAM but are also still evolving, but still addressing those key areas. In the core is directory services, user provisioning, web access management and enterprise single sign-on. Most IAM suites today have at least these solutions as a basis in one form or the other.

The other IAM solutions inside the boundary are role (lifecycle) management, entitlement management and different kinds of analytics solutions for correlation, analysis, forensics of IAM information. Identity proofing is often considered in the IAM boundary as well. If I have not mentioned your favorite technology, by all means let me know. Most of these solutions are in the early stages of development when it comes to feature sets, scale, audience and the like.

At the boundary of IAM are what I term “adjacent technologies”, those products and services that complement, supplement or otherwise share something with those products and services inside the IAM boundary. This includes governance, risk and compliance management (GRCM), network access control (NAC), security information and event management (SIEM), privileged user management (PUM) and data loss prevention (DLP) to name a few. Some IAM suite vendors have acquired some of these products and are developing a tighter form of integration between them and IAM. I even think some of them would prefer to expand the boundary of IAM to entirely include them.

In any case, the boundary is volatile, porous, even unstable. It is not possible at this stage to say with any measure of reliability which feature sets of adjacent technologies may even be incorporated into IAM products permanently, resulting in overlapping functionality. It is important, though, for customers to be aware of the progression of IAM up to and past the boundary to ensure they align their strategy properly when using these solutions. You may already have one or more of the adjacent technologies in-house and in operation and will be interested in knowing how they may help you with a future IAM implementation– or vice versa. Knowing the boundaries of IAM today helps plan more effectively for its use tomorrow.

I was looking forward to doing some alliterative but also (I hope) meaningful observations about IAM, a challenging task but infinitely rewarding for an organization like Gartner that works hard to bring specific meaning to words. I thought I would express a view about identity and access management that might not be immediately obvious unless you step back some from the pipes, pumps and process nature of IAM to see a bigger pictures. Let’s look at it from a hypothetical historical perspective.

In the big scheme of things, IAM performs tasks that are very old, dating back even to the Middle Ages and before. Think of IAM as a person with four ‘personalities’: a soldier, a servant, a spy and a sage. Now what does this mean beyond the supposedly clever use of words that begin with ’s’?

As a soldier in medieval times, IAM established a means of protection for access to the keep, a way to control who came into the keep and who didn’t. A guard at the gate had to ‘identify’ those who wished to enter, and either grant or deny their access. One could have considered a soldier an “access manager”, when they were performing guard duties not off in battle somewhere.

As a servant, IAM also established a means of administering access. If new people never before seen needed access to the keep, the IAM servant ‘updated the access scrolls’ for those who were and were not permitted access. If residents left, the servant had to close up their homes and remove them from the access scrolls. If the prince was promoted to king, that had to be noted as well, since kings might be able to use the ‘other’ gate into the keep to avoid the peasant traffic in the main gate.

As a spy, IAM would provide a means to watch carefully the coming and going of residents, note suspicious patterns and report them. They also had to provide the scrolls for resident populations to the tax collector (kind of like a regulator for compliance, eh?), and otherwise provide careful oversight of the populations that lived within the keep. They might even spy on neighboring keeps to determine who had and had not visited their own.

Finally, IAM might have been a sage as well, providing analysis and insight into the information about who came and who went, assessing patterns of behavior, recommending which scrolls of access be combined for collective wisdom about the flow of humanity and goods into the keep. A sage would have reported to the king based on what they had discovered, which could raise or lower taxes, expand the gate or restrict access, and provide an overall view of what was happening regarding the identity of those at the keep.

IAM isn’t a new idea– it just has a different way today of being a soldier, a servant, a spy and/or a sage.

Co-Chair Gregg Kreizman and I have just finished putting the final touches on the agenda for the fourth Gartner US Identity and Access Management Summit, to be held in San Diego in November. It looks to be a pretty good show:  Earl Perkins, will provide the Opening Keynote, followed by security guru Bruce Schneier, who will discuss the intersection of Identity, Privacy, and Security. I’ll be hosting a Pundits’ Panel including some great thinkers on identity, including Identity Blog’s Dave Kearns. These will be wrapped around lots of presentations by Gartner analysts, user case studies, special analyst Q&A sessions, user round tables, the ubiquitous show floor, and a final ‘Stump the Analysts’ session which will include not only stumped analysts but a guest appearance on stage by the attendee winner of our ‘Best Best Practices for IAM’ contest.

The journey to IAM maturity is a long one, and there may be occasions to take stock of where you are as an enterprise. For our theme this year, we chose ‘You Are Here’ –  many organizations find themselves somewhere in the middle of that journey today, looking perhaps for a road map that will give them guidance as to where to go next. This would put us (as a whole) somewhere near the beginning of the third of four phases of maturity. Phase one could be called ‘Blissful Ignorance’ – there was no formalism in the practice of IAM and not much realization that it was needed. Phase two is called ‘Awareness’ – when a problem is recognized and people begin to seriously talk about what it will take to solve it. Our estimate is that we (again, as a whole) were in this phase from around 2004 to 2007-8. Phase three, which Gartner thinks we are in the early part of now, is ‘Corrective’ – a plan is in place and we’re working on deploying an infrastructure in its various forms, including technology, organization, and policy. Phase four is ‘Operational Excellence’ – I don’t think that term needs definition, other than to note that the Operational Excellence phase is not static, but requires continual refinement.

 So, my question to you is, “Are We Here?” What maturity phase is your organization in, and what phase are we in as a whole? Your thoughts would be welcome here, or through feedback to the conference chairs. And, don’t forget to submit your Best Practices at the IAM4 Event Page – you could win a free ticket to the conference and even end up on stage with us in November!

Communicating IAM value is often necessary to get buy-in into one or more IAM initiatives. There’s also the “getting the money” problem, which tends to be a ‘non-trivial event’ as my physics teacher used to say. Whatever reason you may have, this communication really has very little to do with technology at all. Here are some brutal truths you have to face when crafting a communications strategy for an IAM initiative:

1- You need help. You’ll need others with a stake in the initiative to provide input, an opportunity to discuss and describe the issues in specific forums in their areas, perhaps an opportunity to combine your communication efforts with their own initiatives. In any event, seek out those that may be significantly affected by your efforts and enlist their assistance wherever you can. And by the way– don’t even both trying to get an IAM initiative going without an executive champion. It seldom succeeds without one;

2- My ‘enemy’ is my friend. This is related to (1) above, but I’m thinking of a specific friend, and that’s the auditor. The great thing about IAM initiatives is that in most cases it directly benefits the work the auditors must do when called in for audits, particularly in the security area. If you provide them with an easier, more comprehensive and granular approach to who has access to what, you’ll get their attention and you’ll also get their support when the time comes to communicate who benefits to those parties who hold purse-strings or influence;

3- I care– but not that much. This means that while your efforts to communicate the value of IAM to others, you must not become emotionally invested in the delivery. Sure, I know that there may be some job security associated with these efforts, certainly there can or will be productivity improvements for you, but don’t get carried away with this. In the big scheme of things, just knowing that you raised the issue at an appropriate time and delivered it to key stakeholders and decisionmakers should be enough. Such an attitude allows you to be professional and pragmatic;

4- They aren’t thinking about you. Another brutal truth is that what seems like something crucial and absolutely necessary for you may just not be that important in the bigger scheme of the business. You’ll need to be prepared to make a case for tying IAM initiatives to strategic principles of the enterprise, to key policies and practices for getting the business done, and more importantly make the case to NON-technical people (e.g. business), but don’t take too long to do it. View most executives and business representatives as uniformly having attention deficit disorder (ADD) and tailor your pitch accordingly. They really don’t think about you that often, so get in and get out quickly;

5- You’re not that special. Remember the context of your IAM requirements with other enterprise requirements, and remember your role in this in the context of other roles you have. IAM is important and so are you– but not that important. If you keep a pragmatic view to what you’re attempting to accomplish, you’re more likely to get something rather than nothing. I suppose this is a polite way of telling you that you aren’t so special that other enterprise needs can’t supplant you as an IAM technology provider. In fact, you hope that you can create an environment where you gradually work yourself out of a job and move on to more “special” things.

It’s all about perspective.

I’d like to address a specific, frequent question that many Gartner clients ask us. It’s also a question that is asked often by the press as well.

“When are you going to publish an IAM (identity and access management) Magic Quadrant (MQ)?”

I’ll give you a short, succinct answer and will follow up with an explanation.

Short, succinct answer: “Probably never”.

Gartner does have Magic Quadrant studies for user provisioning, web access management, and (for 2009) a marketscope for enterprise single sign-on (ESSO). But we do not publish an IAM suite MQ. The discussion internally about this has been intense, and has been reviewed each year carefully, considering all of those clients that ask. Here are some of the reasons why we still say no to IAM MQ:

1- IAM itself would have to be defined precisely to allow a manageable number of candidate vendors to participate. For example, if we specified only “IAM suite” vendors, we would have to define what constitutes a classic IAM suite, i.e. what individual component technologies make up a suite. That would indeed limit the number of candidates for the study, but it would also give rise to another concern: if one IAM vendor had good partnerships with other IAM vendors to create a suite offering, would they also be part of the study? Let’s say yes. Though the number of candidates may still be manageable, it would still require that specific definition of a suite to know for certain if you’re producing an IAM MQ;

2- What would Gartner do with the ‘other’ IAM vendors, i.e. those that do not have partnerships to create a suite but are definitely identity administration or access management vendors? It would then be necessary to create an “IAM MQ for non-suites” for another study to capture these vendors if we were to be fair. This could include vendors dealing with role management, entitlement management, Windows administration (for Active Directory), or a variety of authentication products. Again, this would still be a very large and almost unmanageable number;

3- There’s also the issue about weighting particular characteristics of different IAM products all in the same way. Would maturity of product, for example, have the same weighting in user provisioning as it might in web access management, or in ESSO? Would one compare and contrast the products as one unit to the competitor unit, or would one compare product-to-product? How would you map that on an MQ chart if it had multiple dimensions? This could be challenging both for the analyst to do and for the client to read and understand it.

It would be nice to have some kind of comparison overview of the IAM offerings in the market, and most clients do talk the most often of an IAM “suite” of provisioning, access management and single sign-on. I believe it’s important to “never say never”, but I also hope this sheds a little light on why we don’t do an IAM MQ and the reasons. In the meantime, you can be sure the basic building blocks of IAM will get the continued coverage it very much deserves to allow Gartner clients and others to make informed decisions in the marketplace.