This was a great illustration to me of how far our little industry segment needs to improve. None of these customers were trying to do anything fancy. They had fancy plans originally but they were failing on basic provisioning or password management and were never able to progress further. It also further reinforced my view that there’s a great opportunity for a solution that doesn’t require a couple of busloads of consultants to get it (and keep it) running. A solution that delivers immediate value. A solution that customers are happy to have. A solution that is my dream
The question that I'd like to pose is, where does the cause of the failure lie? Is it a lack of IAM product capabilities or IAM services?
In my take, IAM products have evolved (and continue to evolve) quite rapidly. Due to my profession, I am present when customers are shown IAM products from vendors and even when they get to test-drive them. Some of the stuff out there now is downright impressive...from visual drag-n-drop workflow capabilities to wizard-like setup of connectors, all in all, the innovation I've seen on the product side is impressive. Furthermore, most IAM project failures that I've seen occur are rarely due to the lack of a product feature.
I think the problem lies in the services side of the IAM house. I suppose that statement is a confession of sorts, since that's the industry I've lived in for the past however long. Anyhow, the IAM services game is anything but impressive. To pull from one of Brad Feld's quotes, IAM services companies typically win deals because 'they suck less' than the next guy. Definitely nothing to be proud of! The services models are pretty much stagnant with limited innovation over the past decade. Every consulting firm has roughly the same implementation model (discovery, design, implement, test, blah blah blah). Replace those words using a thesaurus and you have the next System Integrator's methodology. That's why I believe there needs to be a shift in the IAM services paradigm.
What's your take? What's the culprit? IAM Product or Services?
Posts
4 comments:
Ashraf,
I just stumbled upon your blog and found lot of interesting and new things. I work for a large retail organization.We have built our own SSO product based on Java. This product has been serving the business needs for past 10 years but lately we started seeing influx of packaged products with which we are finding it real hard to integrate. The management has made up its mind to replace this homegrown product with an commercial SSO product. The problem here is that we have 450+ application (Java/J2EE) which already use our SSO product. I wanted to understand how easy or difficult it is to migrate to a new solution since our SSO solution is heavily customized to the needs of a retail setup. Do you have any thoughts about thi ?
Does your SSO product handle authorization as well? For example, does it make decisions regarding what a user can see/do once they have authenticated to an app?
If it does NOT, then you should look towards ESSO products. Gartner has a magic quadrant for ESSO, so take a look at this paper: http://www.gartner.com/DisplayDocument?doc_cd=160413
If it does, then you might be interested in web access management products. Gartner also has a magic quadrant for those, here's a link to an older one: http://www.sun.com/software/products/opensso_enterprise/2h07.pdf
If you have a gartner subscription, they could get you the latest and greatest.
In terms of a methodology for migrating them in an efficient and intelligent way, research papers probably wont be of much help. You need real expertise from specialists who've done this before. The company I work for, <a href='http://www.identropy.com/Services_identity-management-workshops>Identropy</a>, could provide some help/guidance on this matter. You could email them at info at identropy dot com and they'll set up a complimentary session with an Architect.
Just one opinion but . . . our purchased IAM product was a little clugy to set up but after 5 years was and still is able to do everything we want. Our implementation vendor was and still is very good at providing guidance when we are stumped technically. Where the heartburn was and still is would be the issue of coordinating the business rules and the technical rules. The 2 most common questions we've experienced over the duration is "why did this account get disabled?" and "why did it get created?" The answer, because the business rules say these criteria cause this action. Then IT learns from the business unit that the business rule was changed. After. If ever. The missing link, for us, is an in-house "account executive" who constantly meets with the business units and translates that back to IT. So I think IAM failures are at least partly precipitated by lack of involvement with all of the business. IAM is not an IT thing, its a whole organization thing.
Great point!
Another approach is to establish a governance team that is responsible for laying out policy. No change can happen to the system without going through them first. Here's some details about how such a team could look:
http://identropy.com/blog/bid/34592/4-Steps-Towards-Taming-your-Identity-Management-Initiative
Post a Comment