A Few IdM Vendors Responding to the Market

Courion put out a press release today around their Jumpstart program for Password Management deployments. Undoubtedly not a coincidence given the market conditions. It's worth a look - 4 target systems, ROI in 30 days, fixed-price delivery. Not too shabby.

Also, Symplified has a webinar coming up entitled 'Scary Economic Times Heighten The Need for SaaS Security' with Jeff Kaplan: "With the current economic downturn pressuring enterprises to freeze capital spending on software and quickly find ways to lower spending on IT, the move to SaaS has never been more compelling. This has accelerated already rapid SaaS adoption in an effort to save costs and reduce IT spending."

I'm sure more to come....

More on IdM in the Economic Downturn

Over lunch with an NYC VC, conversations inevitably turned to the economy and it's impact on startups. A telling takeaway was that cost cutting in IT budgets is going to be deeper than previously expected. Gartner and Forrester until just last week stated that IT spend will grow less than expected (Gartner placed it at at 2.3% and Forrester at 6.1%). On the other hand, the gentleman I had lunch with stated that those predictions will most likely be changed dramatically, and that the number on the street is that cuts will be in the ballpark of 20%. Now given that typically 65% of IT budgets are dedicated to maintenance and upkeep, that leaves about 15% on the table for new initiatives. Ouch is right!

In my opinion, if IdM projects are to survive these cuts, it has to be positioned around 2 areas simultaneously: 1. The project has to be linked to core business and 2. Cost cutting capabilities. If the project can't rally around both, it's probably a gonner.

A good case in point is how salesforce.com made it through the 2000-01 scenario. It provided an easier way to do CRM (critical to core business) in a more cost effective way.

So the question is...who's going to be the salesforce.com of the identity world? Or from a project perspective, which initiatives will be able to survive?

A few random thoughts: I like SSO/Context Management in healthcare. Great impact on the business (especially for clinicians) and cuts cost. Password Management is pretty good, except impact on the business in most cases is negligible. The same goes for provisioning and role projects, although a better case could be made for impact on core business. Unfortunately, I think the new kid on the block, privileged access management is in trouble because of its positioning as primarily a security play. I'm still noodling this, but I'm sure this scenario will bring about some interesting innovations in our space in the coming year. Nonetheless, the forecast is pretty cloudy from where I stand.

Selling Identity in an Economic Downturn

Rough week. And it's Tuesday. In the wake of the current financial crisis, I've received 3 phone calls in the past 3 days from potential customers (who were almost surely moving forward with an Identity Management deployment) to tell me that the project is in serious jeopardy. All three happen to be in the healthcare sector. One of them was given a mandate to cut $1m from his budget. Another simply stated that all new initiatives that haven't been inked yet are frozen indefinitely. The third stated that their organization's revenues were deeply impacted because of cuts in Medicare/Medicaid, and any and all projects not directly related to core business will be cut.

I've been able to position the projects to be possibly salvaged by quickly shifting drivers from compliance to ROI and cost avoidance opportunities. Thank God we're in an industry that supports multiple and varied drivers! I think that trying to sell Identity from a compliance and security angle in this environment is just a lost cause, which will probably impact the types of technologies that will be deployed. Any thoughts on other business/tech drivers that might be used? Which types of identity projects will live and which will die?

How to Make a Better Identity Management POC

Mike Trachta responded to my previous post about lackluster POCs by highlighting the difficulty posed to SIs to live up to the fantastic show presented by the POC folks.

"...the customer remembers more about the POC than you think. They remember how pretty the screens were. They remember how seamlessly all the pieces fit together, and how quickly each task executes. What they don’t realize is that all of the data is massaged and simplified. Of course the POC could do these things! It has 3 users with 4 roles to choose from, and doesn’t include any of the “exceptions” often found in the customer’s environment. When it comes time to actually implement this feature with 30,000 users things can (and do) get quite a bit more complex."

Jeff Bohren put together an eloquent post as well, pointing to his experience as the developer in the background helping out both the POC folk, as well as the SI who has to make this happen for real. It's a great read and provides insight from both ends of the spectrum.

I have a few suggestions that might make your IdM POCs a little better. So here they are:

1. Couch your immediate goals in the context of a larger Identity Management initiative that ties it to your business objectives. Jeff already hit on this point in his post, "Instead of doing a POC of who has 'The Most Magical Bullet', enterprise would be better suited to craft a long term IdM strategy and chose a vendor whose product best aligns with it." This approach voids the notion that phase 1 of the project has to cover everything under the sun. A fantastic way to do this is to engage an SI that understands the game, and can walk you through an Identity Management workshop that speaks to both your business and technical objectives.

2. From your workshop findings, carve out a Phase 1 of the project that is attainable - the best way to do that is to write up a handful of detailed use cases that boils the expected deliverables down to non-technical language.

3. Highlight the top X number of use cases to focus on for a POC. Keep it limited (but representative) of your expected project deliverables. Identify the vendors who might be able to respond, and request a technical architecture document outlining their approach to solving the use cases you have identified and have a Q&A session with them. Filter out the vendors who don't make the cut (yes, I know that's a loaded sentence), and identify the top 1 or 2.

4. Prepare a POC lab. (Another loaded sentence).

5. Bring the vendors in, but don't allow them to touch anything! OK, this suggestion point might be a bit much but I suggest that, as much as possible, have the vendor's experts sit on their hands, next to your techies while your techies drive. If the vendor whips out a canned script, your guys will know it (and document it in the findings). If the vendor has to make a nasty directory schema change, your techies will know it. If the vendor has an ugly hack that inserts pages of code into the presentation layer of the "ultra configurable identity app", your techies will know it.

6. Have a structured way to present the findings.


While I know that the approach above requires a lot of background knowledge and support, it just seems to be a much more valuable experience that actually tells you something that a demo can't. If help is needed, supplement the team with an SI that has strong experience in the space. Either that, or save everyone time and effort and just make your decision based on sales demos and references.

Why (most) Identity Management POCs Suck

For those unaware, POC is an acronym for "Proof of Concept", and consists of a client requesting a vendor to bring their software in to demonstrate ("prove") that their software can perform in their environment as promised ("concept"). The engagement usually lasts for a few days to a week, and typically the vendor foots the bill (if the potential deal is large enough). Most often, POCs are borne out of a conversation between a client and an industry analyst who completed a 2 hour identity management market briefing, concluding that it would be a good idea for the client to host a POC. A few vendors are selected to strut their stuff, and after reviewing which vendor did a better job, a winner is hailed and ultimately awarded the contract.
After being involved in one too many POCs, I've come to the following conclusion: IdM POCs suck. Usually. And here are a few reasons/scenarios that explain why:

1. A typical POC is just a glorified demo. So, wisdom states that if the vendor is integrating their software with your target apps, then it's not just a demo, but undeniable evidence that their software is good for you and your organization. That is both true and false. Just because software can be made to "seem" to work with your apps is not evidence that the integration is robust or production ready. Hacks are very common in POCs, and a lot of what is demo'd at the end of the POC is a lot of smoke and mirrors and doesn't prove that what was completed is production ready, or more importantly, can ever be production ready.

2. The success of the post-POC demo is highly dependent on 2 individuals on the vendor team: the Sales Engineer (the guy who duck-taped together the POC) and the POC-demo-guy. The vendor that has the best duo typically wins the deal, which may not reflect the best software solution for your environment. A good SE can make crappy software work (with his arsenal of scripts and tricks), and a good POC-demo-guy can bedazzle almost any audience. On the other hand, a bad SE can make good software break, and a bad POC-demo-guy can put a lively audience to sleep.

3. A POC is typical technology focused. Most IdM deployments are business process centric. When decisions are made based on the number of out-of-the-box connectors or the long list of supported standards without considering how it all applies to your specific set of business processes, the wrong vendor can be selected.

Well, I'm sure there are more reasons, but I'll leave it at that for now.
But the picture isn't that bleak. There are ways around the problems above, and exciting approaches that will not only make POCs not not suck, but actually make them effective and useful...a topic for another blog entry.