Tuesday, April 28, 2009

FUD Swings Both Ways

Salesmen are an interesting bunch. They have to drink the company kool-aid to enable them to sell with conviction. But what happens when a salesperson starts to waver in that conviction? What happens when they start losing their religion? Fear-based selling! Easy peasy!

Since I noticed that my last post on FUD based selling and Vendor Selection was being used to spread more FUD (with Oracle being the victim this time), I decided to do my part to rid the world of keep-the-client-ignorant tactics and try to put the facts out there. It's interesting how fear always finds a home ("they're too small!" vs "they're too big!")...anyhow, here goes:

  • In a solid article by techtarget, Jonathan Penn points out that customers have no need to panic today, and that Oracle will have the resources to support both product lines for a while, noting that it has continued to support the ERP products of both PeopleSoft and JD Edwards following its 2005 acquisition of PeopleSoft.
  • Instead of spreading fear, let's spread facts - namely regarding Oracle's track record with acquisitions. Siebel hasn't gone away. Also, Oracle now supports multiple app servers with the BEA acquisition. (Someone else may want to chime in on this since I'm not an expert, but remember: facts over fear!)
  • Anectodal evidence: a casual conversation with a VP at a financial firm uncovered that in the past years, Oracle has acquired nearly all of their major systems, effectively turning them into an Oracle shop. The result? Fear and mayhem? Not really. In fact, Oracle offered up a free inventory analysis from Oracle Consulting to guide the client to maximize their existing software investment and determine how they might benefit from updates resulting in tighter integration between systems (although the client stated he would have opted for a deal on maintenance).
That's my $.02, and I hope it moves the conversation away from fear and closer to the facts. And although I know I didn't cover all the facts and I welcome folks to chime in with their side, the point should NOT be boutique vs. large vendor, large vs. small, red vs. twitter blue, but simply the product's capabilities to "scratch your itch", as Dave Kearns put it. Remember this, young salesman: Sell your product, not fear, for FUD is the path to the dark side. FUD leads to anger. Anger leads to hate. Hate leads to suffering.

Tuesday, April 21, 2009

A Story About Vendor Selection and FUD

The shocking (at least to me) story of Oracle acquiring Sun yesterday made me think about an experience I had helping a client in the vendor selection process late last year.

The client was seeking an identity solution, and with our help, reduced the vendors to Sun, another large vendor and a small boutique vendor. After their demos/POCs, the vendor scoring matrix we helped them put together showed that the boutique vendor actually ended up with the highest score.

After some great FUD work from the sales folk, the client decided to add a new metric in the matrix for Company Viability. All of a sudden, Sun came out on top...and the solution was purchased and implemented. The whole reason the boutique vendor lost out was because of fear and the likeliness of acquisition or failure, etc.

A few months later...Sun is on the block, and finally inks a deal. Now I'm hearing that the client is worried about the direction of the Sun product line post-acquisition, because of the heavy overlap between the Sun and Oracle product lines. (And also worried about what Oracle will do to Sun's open source initiatives.)

Now the smaller vendors are having their say (and they should). Here is an interesting perspective from a Network World article:

"Figuring out what stays, what goes, and integrating the remaining pieces is going to be an enormous task that will undoubtedly create consequences for deployed customers," says Andre Duran, CEO of Ping Identity, which develops identity federation software. "This is yet one more reason companies should consider standards-based, loosely coupled approaches, as it insulates them from the potential for single vendor lock-in, which is occurring irrespective of how they are selecting their vendors."
...
Blakley says as the deal closes, Oracle management likely won't address identity until the more compelling strategies, such as the database, are worked out. "So there will be a period where not much happens and it is business as usual."

Tuesday, April 14, 2009

Virtual Directory Whitepaper

Oracle just put out an interesting whitepaper on how to use their virtual directory product with Sharepoint. A few interesting scenarios:
  • Allow users to authenticate to SharePoint with Windows credentials but control access based on job codes maintained in a HR database (without having to sync!)
  • Allow a SharePoint workspace to be used by two different business units who each maintain their own AD domain
On another note...sharepoint has been getting a lot of attention from the identity folks, hasn't it? Microsoft was promising a new "Identity Portal" in ILM 2, until they blew their release date by A YEAR(!!). Courion's been marketing their solution for Sharepoint as well, which is basically an attestation/segregation of duties play. Bitkoo has their fine grained authorization management stuff for Sharepoint.

I wonder why the trend? Hmmm....
Well, here's a billion reasons.

Wednesday, April 08, 2009

Some Process Re-engineering Principles for Identity Management Projects (part 1)

I'm in the early stages of working with a colleague on a whitepaper on guidelines for business process re-engineering for provisioning projects, and thought I'd share some of our thoughts to see if I could get some feedback. (If we use anyone's feedback, we'll make sure we reference you.)

1. The first point is to put some parameters around the re-engineering effort. The most common mistake that IDM focused re-engineering efforts make is to overdo it. Once a current state process diagram is put together (preferably in BPMN) - many consultants find way too much to optimize, usually because of complaints from the customer. It's important to keep your scope in mind, otherwise the project can quickly turn into a much larger endeavor than you (and the client) had previously anticipated. It's important to focus primary re-engineering efforts on areas that can positively impact identity data. It may be tempting to re-engineer an inefficient interviewing sub-process of the onboarding process, but will most likely not impact your identity data either way. Furthermore, provioning platforms were not created to solve that problem (more on this later). On the other hand, re-engineering a self-registration process to prevent duplicate accounts will have a significant impact on your identity data. The lesson: pick your process re-engineering battles wisely.

Thoughts?

(to be continued...)

Wednesday, April 01, 2009

Pottery Making, Iterations and Identity Management

I'm a big fan of iterations in identity management implementations. The reason is pretty simple: you can't learn from lessons until you try. (You could learn from consulting firms, but not about your environment.) Which means that you don't get really good at delivering identity management until the 3rd or 4th time. (So take that 9 month project and break it down into smaller 3 month projects!)

Anyhow, here is the pottery making connection. It's a parable a co-worker forwarded to me from Art and Fear:
The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot—albeit a perfect one—to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work—and learning from their mistakes—the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

The lesson: Take on a small, well-defined, low-risk phase 1. Learn lessons. Take on a small, well-defined phase 2. Lather, rinse, repeat.