Saturday, January 31, 2009

Another Entry into the IdM Managed Services Space

I just read an interesting press release this morning from Watson SCS, an IBM Identity Management SI. They've announced an off-premise managed service offering offering called Identity Management On Demand, bolstering the following:
implementation of a simple Identity Management program can be executed in twelve weeks – about half as long as the quickest deployment of a customized solution.
I have special interest in this area. (Last week, Identropy announced the expansion of its off-premise managed identity services offering (iMIS) by adding support for Novell Identity Manager.) What's interesting about Watson SCS's play is that they're opting to offer a fully managed service, hosted off-site. A few days ago, I was speaking to a colleague at another integrator who recently pulled the plug on their off-site offering, for reasons I've already discussed.

Anyhow, it's great to hear more offerings in this space. It validates what we've been hearing from our clients: Why is this stuff so painful to implement and manage?

Welcome to the party, Watson SCS...looking forward to seeing you out in the field.

Tuesday, January 06, 2009

On Identity POCs - From a Vendor's Perspective

I pinged Joe (Nobody?) on Twitter last week regarding Identity Management POCs. Joe put up a lengthy post on his blog regarding some of his thoughts from the perspective of the vendor (so it seems). It's always great to get thoughts on the topic from another vantage point...some great points, with my $.02 in-line:

"a POC is that they are a dangerous sales activity used against a vendor rather than for it (I used to be a customer and did just that)"
I've witnessed that before. So Joe, how do we make sure the POC stays on the right track?

"But a POC is should not be a repeat of a demo in a customer's environment. On the flip side, a POC should not be an installation exercise based on the customer's demands.
A POC should be a onsite installation to show at a minimum, key use cases for the defined phase 1 and 2. Self service, HR feeds, provisioning into the key systems and de-provisioning for exmaple. Which means Phase 1 and 2 should be defined prior. How do you know what to show if the customer doesn't know where they are going?"

Use cases. I like. Tell me more...

"Prove the concept. Prove the process. Prove the business improvements and solving of business needs rather than proving when you hit this button this technical thing happens."
Completely with you.

"Don't prove installation, don't prove configuration, don't prove how many components it takes to do it. "
Hmm....not so sure about this one. A POC should prove business use cases as well as allow the technical team understand how it works in order to judge integration efforts and
"Another reason why POCs are often an embarrassing cluster is the customer's environment. I generally require, based on the customer's hardware, that I have sterile servers, patched specifically, nothing else on them and require the pre-req software installed on them before I walk in the door...What GPOs are set that is locking down a service and takes you 2 days to find it. Regardless on the cause, any delay is bad impression on you and the product."
Fantastic point. I've seen POCs blow up because of a misconfigured DC, DNS problems, etc. And the vendors end up spending time troubleshooting environment problems rather than working on the actual POC.

"If, as a vendor, you drive the use case creation with the customer you will show your knowledge and leadership. You will have a controlled flow from start to finish they will make you look successful and show the customer their needs. Your time will be shorter and cost less for you. The success rate will be higher. You miss these things, the customer will push you into a hole of broken knowledge. We are the experts, not them."

Well said, Joe. Nobody.