Earl Perkins

Well, it’s funny what a couple of days will do to blog news– information ages fast. The first webcast has occurred regarding what will happen in the post Oracle+Sun world (Orasuncle? Oraclsun? Probably will settle on Oracle). What can we deduce from the news and the impact on our predictions Gartner has made about Sun IAM’s future?

1- The prediction (regarding coexistence of suites for some time)  holds up pretty well, though there are no specifics regarding how long this may take. The comments regarding “integrate into” or “incorporated into” set off some red lights, mainly because there are different forms of integration and different ways to go about it. At first glance, the product architectures of the IAM systems aren’t that similar, and the question inevitably arises “why integrate them”? Sure, you don’t want Sun customers to run if you even discuss “Sun-setting” the products, but by the same token there’s quite a bit that can be done simply with pricing and marketing, rather than going through the technical pain of merging feature sets into the Oracle products. Perhaps this is the kind of integration Oracle is considering. In any case, we’ll need more information, not just from a timeline perspective, but as to the type of integration and incorporation occurring;

2- The naming of Sun Role Manager as Oracle Identity Analytics appears to be confirmation that Oracle recognizes the current value of the original Vaau acquisition and is “incorporating” it into the overall Oracle IAM suite immediately. More importantly, it’s confirmation that an evolving, more distinct function set within IAM is appearing that focuses on “intelligence”, i.e. the logging, correlation, analysis, and reporting of identity information to constituents who “subscribe” to it. Gartner has identified this area as IAM intelligence for IT management and support. Both Gartner and Burton believe the product to be a participant in the identity and access governance area, which expands IAM intelligence into a broader responsibility to include business users of IAM. IAM intelligence has been embedded predominantly in the administration and access products of IAM up to this point. It now appears to be coming into its own, and Oracle is positioning itself to move into an aggressively competitive role in this area;

3- Having any kind of ambitious strategy to realize integration or alignment of two company IAM strategies involves one key point– getting existing IAM customers to buy into the upgrade opportunity. Integration and incorporation are in name only unless an existing Sun or Oracle IAM customer takes the necesary steps toward that integration or future state Oracle wishes to provide. There will have to be an extensive incentive to get those customers moving in an economy like this, and a practical incentive that offers compelling functionality. This doesn’t count the marketing dance necessary to tell the tale of two suites to potential new customers to encourage them to buy, though Oracle has made it clear that the Oracle suite remains the flagship. In any case, such incentives will likely put pressure on the general IAM market prices by pushing them downward as those incentives go into play– possible good news for old and new IAM customers alike.

I think the bottom line of all of this that we’re living in an exciting inflection point and period in IAM. While I would hold the champagne until we know more about this integration and consolidation work (and its viability), the outcome of this acquisition will have relatively profound effects on the market, realign competition and affect pricing and available options for solutions. Buckle your seatbelt.

Our apologies for the delay since our last blog– much continues to happen in our part of the IAM world, and sometimes it catches up with you.

The European Commission put its final stamp of approval on Oracle’s bid for Sun Microsystems. While a lot of work was in process between the two companies in preparation for that day, doing it is almost a certainty–there are still a couple of other approvals needed from other countries. Let’s review again just what this may mean for the IAM industry, as time has passed since the first announcements in April 2009 and the market continues to evolve. Now that this acquisition is all but a certainty, what does this mean for IAM choices?

1- During the 9 months since the announcement, there have been some defections from consideration of Sun as an option in projects (that clients have spoken to Gartner about), but not as many as might have been expected. In fact, I was more impressed by the number of projects that went forward in spite of the uncertainty as a result of the original European Commission concerns. There have been very few defections by customers of existing Sun implementations to other systems of which Gartner is aware;

2- The reaction by competitors in IAM to April 2009-to-January 2010 has been surprisingly muted. Yes, there have been programs established by leading competitors to woo potential and existing Sun (and Oracle) IAM customers away, but again not as many as we expected, considering the scope of this acquisition. When HP left the IAM market in 2007, Gartner research emphasized the need for IAM vendors and customers to establish and/or augment a formal migration plan to take advantage of the growing disillusionment in many IAM solutions, preparing themselves for a consistent approach in migrating existing or custom implementations to other vendor solutions. The volatile nature of the market continues to exhibit itself here;

3- Gartner research published immediately after the Oracle-Sun announcement predicted that any change for existing Sun customers will be a long time coming, and by the time it does it will represent less of a trauma than a discontinued product set or a major migration initiative. In fact, Gartner believes it will be at least 5 years before anything of significance is seen, in spite of the overlap in product coverage. This isn’t knowing rocket science or being psychic, merely an observation on (a) the degree of overlap in products and targeted markets, (b) past Oracle acquisition history, and (c) the fact that the IAM suite wasn’t on Oracle’s radar in the decision process. Remember, Oracle had their eye on Sun for Java and other non-IAM offerings– Sun’s IAM solutions were swept up on the decision. This doesn’t mean Oracle left out IAM in the decision-making, but it was pretty far down the checklist. This can mean that a number of early decisions about the future Sun (or Oracle) IAM products will likely be tactical in nature, rather than a suite-or-no-suite decision;

4- Both Sun and Oracle have good IAM products in their suites. Not all products in either suite are the absolute best (that would be a marketing challenge, hmm?), but the cycles of maturity that have defined the IAM market have resulted in solid “core” IAM products (e.g. directory, web access management, user provisioning) and the still-evolving other components will likely have the most decisions to be made about near-term futures (e.g. role lifeccycle management, entitlement management).

So what’s the bottom line? Potential and existing IAM clients should not look at this acquisition as a major shift either in choices or futures, rather as a another step in the “cycles of maturity” IAM must go through to achieve its real place in the IT infrastructure, cycles that include market consolidation, completeness of market coverage, and (ultimately) the technology changes required for the next generation of IAM.

If you were like me, you were surprised at the announcement this past week of Gartner’s decision to acquire the Burton Group– if you weren’t surprised, you were either psychic or worked on the acquisition. In any event, it was truly welcome news to my colleagues here in the Secure Business Enablement team at Gartner and the Security team in general.

The Burton Group has been a well-respected name for many years in the identity and access management market. Jamie Lewis and his team were “doing” IAM long before it was cool to do so, and the company has gained a solid, well-earned reputation as a group of professionals with depth of experience and deep engagement with the client.

The business model Burton uses provides an evergreen approach to knowing what is happening in the IAM industry and how IAM is used within the enterprise. Their depth of research in chronicling that approach also provides an excellent view into customer progress and the use of technical IAM standards. The company fosters the ability to connect and communicate with the technical audiences at several levels.

And of course, there is Catalyst– their annual conferences that became a bellwether and institution in the IAM industry.

No, I’m not talking Burton up because Gartner acquired them– we have recognized them as formidable competitors in IAM and respected them over the years. For myself personally,  at least two opportunities have arisen to allow my direct communications with them. First, I count Gerry Gebel as both a colleague and a friend. We meet and speak together over a cup of coffee whenever we attend common industry summits and vendor analyst conferences. Also, during my employment at Microsoft, I have had the opportunity to read and use the impressive range and depth of Burton research freely.

You may be thinking “oh great, a big long commercial for a Gartner acquisition”, but there is a point to make here. This industry, for vendors and clients alike, must address a spectrum of need– from standards to practices, from architecture to market analysis, from budgeting to policy. The research industry must be prepared to polish the crystal ball and try to “see” as much of the future of IAM as possible to provide all clients with some sense of the market, the technology, and the ultimate impact this critical area of security and IT has on their enterprise and their business. A decision that brings together a spectrum of talent to address this spectrum of need is a win-win for most clients.

There are always concerns by clients about IT research company choice and culture, of traditional reasons why you can’t or shouldn’t deal with a single vendor for such needs. All I can say at this point is that the proof must be in the delivery– if the new Gartner delivers a consistent, quality solution set for customer needs, the rest will work itself out. That’s the idealist in me.

In any case, we are excited about the prospects and the opportunities that this decision has provided to us, and we look forward to the future exchange of knowledge that will make Gartner IAM solutions even better than they are today.

 Season’s Greetings to readers– I hope this ramble finds all of you safe and healthy for the holiday season. Let me start by making an apology– there will be a lot of  phrases in quotes below (”like this”) since one of the main topics of discussion is word usage to describe things, so be warned. I welcome any responses regarding this rambling on what remains a confusing topic for many of Gartner’s clients.

So, let’s get right to it. Entitlement management needs a new name, and role management too for that matter. “Management” is too broad to denote useful differences for customers, since management can mean anything from the administration of entitlements to the enforcement or resolution of them. Think of it as a “plan, build, and run” discussion, as is often the case in IT. The “run” part of a lifecycle is most often associated with management, but there are planning and building aspects to entitlements as well that are often classified as “managing” the entitlement. So is this merely an argument about the use of certain terms, or is there a reason for all of this?

Well, yes. The market itself for managing entitlements has existed for some time now, and understanding that market and what vendors offer in it is vital to knowing where those offerings may fit in IT for the enterprise. Whether we like it or not, vendors have created market definitions of entitlement management, and we need to correlate this with the more academic discussion of entitlements to know what kind of design and process is to be used in the enterprise for “managing” entitlements.

Today many would agree there is a market for role management solutions and a market for entitlement management solutions. Are they the same market? No. Do they address related issues? Yes. Role management solutions as we understand them today could actually be classified as “entitlement engineering and administration solutions”, but it’s too long to put on a product box.

Role management solutions provide a means to understand and design your entitlement situation in the enterprise—what applications have what entitlements, how those entitlements might be assigned to the appropriate people when they wish access to those applications. Role management provides an environment to allow you to “discover” what you have in the form of entitlements and to associate them with some kind of construct (call it a role) so it’s easier to manage the administrative task of assigning them to the right people. There’s still some debate in the industry whether the role is actually the best way to do that assignment and administration, but right now it’s the primary method we use.

 Entitlement management solutions are mainly “entitlement resolution and enforcement” solutions. This is a bit trickier, since some of those solutions have some basic role management capability, or at least basic entitlement administration capability. But the heart of entitlement management is a processor for entitlements, i.e. they receive an entitlement request, process it, make a decision, and either allow access to occur or not. In many instances entitlement management solutions are self-contained software “engines” that receive access requests, process them, and produce a result on behalf of the application, platform, or service.

 In entitlement management solutions, you’ll hear much discussion about access policy, or the structured rules that guide how entitlements are resolved and enforced. Role management solutions are also guided by the business and technical access policies defined to ensure that the roles are structured to reflect that policy and the entitlements are assigned to also reflect policy requirements. This is something both role and entitlement management share. Entitlement management functions today are buried within the applications themselves, i.e. the application does the entitlement request processing itself in its own unique and proprietary way. Entitlement management solutions propose that as much of this as possible be externalized for “management’s” sake. This is an issue for older applications, since it is what it is and you’re not going to go ripping up code just to externalize a function like entitlements processing. This is mainly a developer concern for newer applications and services, regrettably. It is one reason why the market for these solutions is still quite small, with only the brave at heart (and strong of need) tackle the issue.

That’s my view of this world. One is primarily a preparation and administration function set (role management), the other is primarily a processing and results function set. They have different audiences when it comes to the “run” part of the lifecycle, but share many “plan and build” concerns. Maybe it’s time they were given new names, perhaps under the umbrella of “entitlement lifecycle management”. And no, please don’t make another acronym—just spell it out.

As the year begins to draw to a close, I have been talking to a number of IAM vendors about their plans for the future. They in turn have been talking to me about Gartner’s view of customers future IAM plans. We often compare notes on what their customers are saying vs. what Gartner hears customers from everywhere saying. All of this information is funneled into the planning process for roadmaps for 2010 and beyond.

These kinds of talks are intriguing for me, because they not only reveal what IAM vendors think are the ‘next big thing’ to conquer in this market, it also forces analyst and vendor alike to really think outside of the box on how to solve them. This is a classic example of trying to determine whether there is another way to address core customer concerns rather than the way we have been addressing it. Maybe a little heresy is needed here: sometimes you don’t give customers what they want, you give them what they need– IF you can be relatively sure of the real need vs. the perceived need.

Take a look at the history of IAM. What are the key problems that have been around for decades that are constant, even though there may have been two or three different attempts by vendors to address them? What has changed to (a) make new problems or (b) make the old problems worse? What is available now that can address the new face these problems present without layering or adding on a new application to the IAM portfolio or a new series of services yet again for customers to buy?

Some IAM vendors believe that one constant problem is ensuring secure access to important data– period. In their view, data is the atomic target, i.e. the smallest building block IAM must address as a distinct element when delivering services to access it securely. They also believe that the changes in business that have caused that data to be so ‘dispersed’ and so varied from its original starting point (e.g. extracts of databases, content created from different data elements) and how it can be accessed in so many ways (e.g. mobile, desktop, laptop) that this mission of securing access is more complex than ever.

Other vendors believe that the key to really effective IAM is knowing everything about the access event, i.e. having the pulse of identity and access events so that assessing secure access is straightforward and thorough, that reporting who has access to what, when, where and how can be done and done quickly, that finding bad guys doing bad things faster and stopping them faster is true IAM strategy. They obsess over how their products and services might create monitoring and reporting capabilities for identity actions to address such concerns. And doing that while making money too and while customers don’t go bankrupt buying the solutions. 

So are these both truly chronic problems? I think the answer to that is easy– yes! And these aren’t the only old problems that remain unsolved– I’m sure the conversations on how to solve these and others will continue.

I have one last musing, if you don’t mind. My colleagues and I were discussing the results of these vendor conversations and comparing them with our research, and we noticed how much alike the IAM market is to other IT markets. You see folks with specific ideas about how to solve specific IAM concerns (a “problem-let”?), and out of that arises an IAM startup that produces (with its solutions) one view of solving those specific concerns. If enough of them try to solve the same concerns, a market is born. Eventually a consolidation occurs where those concerns may be combined with related IAM concerns and an IAM suite is born. You can use whatever analogy suits you (e.g. big fish eating small fish, cells that combine into organs) but you see this cycle repeated quite often. This is free enterprise at its finest.

But vendors and analysts alike also think perhaps there is a limit to how this model serves the ultimate goal of solving long-term, chronic core problems that IAM is supposed to address. Are we really being efficient (or effective) in the way we solve chronic problems by being so focused on specific concerns that we fail to uncover a more elegant means to solve the larger problem? I’m not coming down on the side of suite vendors, and I’m not advocating some kind of monolithic think tank to bring entrepreneurs together to discuss how their particular solutions fit a broader picture, but as a customer it wouldn’t hurt next time you talk to any IAM vendor to get their opinion on the “grand vision” of IAM as delivered by their solutions. The answer may surprise (or scare) you.

And now that I’ve probably depressed everyone, Happy Holidays!

I hope everyone in the U.S. had a good Thanksgiving holiday, and I wish everyone globally the best of holiday seasons.

I have been speaking to a lot of companies (something this job fortunately gives me the opportunity to do) regarding the topic of entitlement management again, mainly because they bring  the topic up. Some of those discussions give rise to a couple of thoughts that I wanted to share with you. They may be obvious to many of you once I describe them, but writing down the obvious is good therapy for me.

Thought #1: Identity management systems need identity management. When we first developed super-user privileged management systems, they focused on platform environments (e.g. the sacred “root” user) and database systems (e.g. database administrators). But as I’ve watched identity and access management (IAM) systems evolve, I’ve become convinced that this the IAM application is worth protecting from IAM administrators, i.e. not so much from threats from the outside as from threats within. I’ve noted that many times those administrators and enterprise users who use IAM have the simplest of authentication/authorization credentials/entitlements  protecting that access; this worries me. Think also of the budding market of cloud computing-based IAM systems, or even enterprises that want access to software as a service (SaaS) applications which in turn are managed by enterprise-based IAM. Is your head hurting yet? OK, let’s throw into that mix the ”meta-IAM” coordinators that will manage multi-tenant IAM operations while coordinating between multiple private clouds and plain old enterprise-based application environments.  Do you really, honestly believe that we will automate all of that in our first round through federation and delegation, or will good old-fashioned manual process be involved as well?

So what does that have to do with entitlement management, you ask? The same architectures, feature-function sets and approaches being contemplated and performed today for enabling granularity of access to applications will play a key role in enabling that same granularity to the IAM application on behalf of its users. And I really don’t think we want to duplicate the same mistakes as the past, when we took our time in bringing together provisioning, delegation and entitlement assignment for customers that make up the IAM suite today. This gives rise to another thought….

Thought #2: I don’t think the brave new world of cloud computing and fine-grained access to the services within will be possible unless we finally “solve” the entitlement assignment and resolution issue. Some of my analyst colleagues in other research firms referred to this as “dynamic authorization management”. This is the basic idea of coding applications and services in such a way where entitlement decisions are made external to those applications and services, similar to the way authentication as been externalized over the decades.

I believe this is a prerequisite for applications and services truly designed and delivered for cloud-computing existence. Sure, you can rig up something (APIs? file transfers? humans sending emails?) that will allow cloud computing service offerings to work using traditional security architectures for access, but it is neither sustainable or scalable. It will be important to have an architecture by which entitlements are used and reported on that is consistent– that is, if you want to make money as a cloud computing participant or gain consistent access to cloud-based services before you die of old age.  We will have to bit this bullet sooner or later. I vote sooner.

There are other thoughts, but I’ll halt at this point to see what YOU think about this topic.

Please welcome to the IAM Blog my colleague Avivah Litan. She is preparing a research note on the critical topic of when and where strong athentication fails and has provided a preview of that note below.

When and Where Strong Authentication Fails, by Avivah Litan

Criminals are successfully launching man-in-the-browser attacks that circumvent strong two factor authentication that executes through the user’s browser. The fraudsters are also successfully having telecommunication carriers forward phone calls used to authenticate users and/or transactions to the fraudster’s phone instead of the legitimate user’s phone. These attacks have been successfully and repeatedly executed against many banks and their customers across the globe in 2009. While bank accounts are the main immediate target, these attack methods will migrate to other sectors and applications that contain sensitive valuable information and data.

A layered fraud prevention approach that includes server-based fraud detection and out-of-band transaction verification that precludes call forwarding to illegitimate user phone numbers can and has mitigated these threats.

Here’s how some of the attacks have worked:

• Malware sites inside a user’s browser and waits for the user to log into a bank. During the log-in, the malware copies the user’s credentials and one-time-password (OTP) number, sends them to the attacker and stops the browser from sending the login request to the bank’s website, telling the user the service is ‘temporarily unavailable.’ The fraudster then immediately uses the credentials and OTP number to log in and drain the user’s accounts. .
• Other malware overwrites transactions sent by a user to the online banking website. This overwrite happens behind the scenes so that the user does not see the revised transaction values.
• Similarly, in cases where the online bank sends specific transaction information back to the user to confirm, e.g. $10,000 being transferred to Account A, the malware overwrites the transaction values sent back to the bank after user confirmation, for example so that the $10,000 transfer goes to Account B.  The user only sees Account A on the transaction detail display so confirms the transfer by entering a one-time-password generated by a dedicated token, without knowing that malware will change Account A to Account B before the confirmation reaches the bank.
• Authentication that depends on a user’s phone as a second factor is circumvented by a simple technique whereby the fraudster asks the phone carrier to forward the legitimate user’s phone calls to the fraudster’s phone. The fraudster simply tells the carrier the original phone number is having difficulty and needs the calls forwarded, and the carrier does not sufficiently vet the requestor’s identity before executing the fraudster’s request.

Recommendations

• Recognize that any authentication method that passes through a browser can be defeated if the browser can be attacked and compromised.
• Use server-based fraud detection to monitor transactions for suspect behavior.
• Use out-of-band transaction verification to verify user transaction requests and only execute the specific transaction verified or signed by the requesting user.
• Use out-of-band communication protocols that can prevent calls being forwarded to numbers that are not registered for a specific user account. 

My colleagues and I just returned from our 4th annual IAM Summit in San Diego last week. It’s hard to believe that it has already been 4 years since the summit was established. It is summits like these that allow us more concentrated “face-time” during these few days with clients and vendors than a good portion of the year, so we value the events very much from a research perspective. During these past 4 years, it appears that an evolution has occurred in the nature and type of IAM project or program underway in many enterprises– at least based on the questions and concerns discussed there.

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.

As an analyst, I’ve taken a lot of telephone and face-to-face inquiries about what we think will happen when the acquisition of Sun by Oracle is completed (or if it is completed– but that is another blog). We wrote a couple of research notes on the topic and more are in the works that look at the entire company portfolio impact, but being in IAM, I’m going to confine my comments to the identity implications of this acquisition. Let’s see if our line of reasoning about these unfolding events matches, or if you have different views on this very important topic.

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.

Many Gartner analysts (including myself) just returned from our U.S. Symposium event in Orlando, Florida this week. As this was my first Symposium as a Gartner analyst, it was both a new experience and an old one. It was new in the sense of scale and audience type, it was old in the sense that I have participated in many other Gartner summit events and Symposium had similar characteristics in terms of logistics and content.

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.