Hello everyone. It has been a long time since my last entry. There is no valid excuse– as Bambi’s mom said, if you don’t have anything good to say, don’t say anything at all. But maybe I do have something valid to discuss with you.
Seriously, this has been an interesting period for identity and access management systems over the past few months. I get the sense that we’re at one of those inflection points regarding a market, a method, a discipline– however you as a customer care to define IAM. I just am beginning to get the sense (a perception, Earl– are you talking about a perception here? See my last blog on Novell) that unless we rethink this entire business of IAM, we’re going to make some fundamentally serious mistakes in servicing the enterprise.
The current ‘model’ for IAM just doesn’t appear to work. I put the word model in single quotation marks because it is such an overused term, I didn’t want you to take it literally– I wanted you to think of method, or process, of organization, of approach. For one thing, I’m concerned that we are trying to institutionalize a technology approach to this issue, when technology is not the ‘model’ we should be leading us at all.
IAM really isn’t a technology issue. The roots of IAM problems may be in technology, and some technology implementations have actually caused IAM to be talked about as a separate discipline (e.g. the way we use and handle passwords for access), but many of us miss a fundamental issue with IAM– we tend to seek an external answer to what is essentially an internal issue.
What in the world do I mean? IAM has been part of our technology solutions all along. The problem is we have too many of them, clever and kludgy, diverse and standard, existing at all layers of IT infrastructure and software. Everywhere we look, some application is making an authorization decision, or some operating system is making an authentication decision, some non-IAM software is printing an IAM report or monitoring an IAM event. IAM is everywhere– and nowhere, particularly if you’re wearing your technology glasses.
Well, take them off for a minute, and put some other types of glasses on. Your resource planning lens may look at this as an issue of knowing who is using a resource, proving that you know, and making sure it’s the right resource for the right person to do their job– and no more. Your organizational lens may reveal how much time, money, and effort it takes to find out who is accountable and responsible for handing out access entitlements, for reporting, for enforcing. Your compliance lens may want to align what you know about all types of people (employees, contractors, partners, customers) and their access based on what laws and regulations say they can and cannot access.
Just like in architecture there are different slices and views of the same issue, there are many roads to a decision about what IAM should look like for an enterprise. IAM isn’t that much about delivering the technology to achieve that look– it’s the journey to get to the look itself. Formalize that journey, make it a consistent, measurable, quality journey, and you got yourself IAM. Incorporate it into mature processes, organizational structure, and operations, and you have yourself effective IAM.
So what– I’m not really saying anything new here. It has been written about over and over. What I am trying to expand on is that the current technology-driven approach the market takes to ‘delivering’ IAM is flawed, and needs a rethink and a fresh approach. Some companies and institutions have already done this, with promising results. I’m also a believer in the minimalist approach to solving issues like this, mainly because that approach allows a multi-staged journey to complexity— if it’s needed. Starting out with complex, heavily-featured products and endless discussions about integration are a sure sign that you better hide your wallet.
This has just been some rambling observations (perceptions) about the state of IAM. I’d like to hear your own ramblings as well.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.