Night of the Living IAM Solution

In which your identity product becomes The Undead

In the last seventeen years, I’ve been at two companies that acquired smaller companies, inheriting technologies that in no reasonable fashion integrated with their existing product line. Both employers practically bent over backwards trying to rationalize why they bought these smaller companies whose products made no sense at all in the acquiring companies’ stacks. In the first instance, both companies shared board members, and the bigger, profitable company was used for bailing out the smaller, failing company. The larger org’s stock understandably took a hit, leading to shareholder lawsuits.

In the second instance, the guys at the top honestly thought it made sense to acquire another company whose product was absolute crap and didn’t fit their strategic direction.

Cisco buys technology that they hope to put on their hardware. They paid $100 million for Securent, then a couple of years later have practically sh_tcanned it and replaced it with Rohati. Rational used to buy things that they actually used, but which simply turned into menu options in the existing product line.

In the case of Oracle acquiring Sun, it actually made perfect sense. Larry gets Java, and bunch of hardware, and of course a whole lot of customers. In some ways, it might have made more sense for IBM for them to get it, given the fact that they obviously know how to sell hardware. But Oracle has had a software/hardware mojo going with Sun by way of Exadata. And the folks at Oracle, unlike some of the folks at Sun, like to make money with the stuff they make.

What sort of got lost in the haze was the fact that both Oracle and Sun had large installed bases of their respective identity and access products. This was not part of the strategy; in the case of Oracle, especially, the identity sector is a fraction of the overall business, although projected to grow significantly. The Sun identity practice came over with the rest of the baggage, and represented an obvious overlap. Sun Identity Manager was a decent product, no doubt. It has a significant base. But now it’s going to be the also-ran, while Oracle Identity Manager is the strategic product going forward.

So now comes the inevitable question, what happens to all those Sun customers?

First off, my big, hairy disclaimer: I have been making a good living for a couple of years flogging the (IMHO) excellent Oracle identity stack.

Oracle supports acquired products indefinitely, which is a good deal if you’re one of those customers, but of course it’s expensive. So nobody has a gun to their head to migrate. Of course, how much development do you put into a product that’s effectively deadended?

Because I’m a morbid kinda guy, I refer to Sun Identity Manager as a vampire child. It’s been bitten in the neck, and therefore while it will never lose anything, neither will it get any older. What it is now is what it will be until 2017, when support is scheduled to end.

Any time you’re talking about migrating from any kind of enterprise solution, it’s not simple. Sometimes these efforts can be at least semi-automated. There are tools that will turn Siteminder policies into Oracle Access Manager policies, for example. But there are no simple ways to migrate provisioning workflows, by contrast, from one solution to another. It’s not just the scripting language, it’s also the architecture, the connectors, the adapters, you name it.

You could say that, if it’s a difficult migration where a lot of the work is manual, meaning less migration than fat fingers, what’s the difference if you go to one solution over another? You’ve got to retype a whole bunch of crap no matter what. So here’s what to consider:

• Microsoft has a repackaging of old stuff and OEM stuff in a dubious smorgasbord with currently limited functionality.
• Novell’s near term future is spooky, given their on-again off-again acquisition status and the many rumors that, if they get bought, they’ll be carved up.
• CA, IBM, and Oracle are all out there with large customer bases and lots of resources.

Let’s boil provisioning down to a couple of components, workflow and connectors. The former walks you through the steps, the latter makes stuff happen at each step. Until the whole world’s talking SPML, everybody’s connectors are proprietary. The workflow, including design interface, encapsulation, delegated admin, and other nuances are where the real value lies. If you decide to POC the effort, consider a handful of use cases, such as “create a user,” followed by “modify, provision, re-provision, de-provision, transfer, and terminate.” In the case of a SIM customer, you might think that Oracle has the leg up, since they now own the folks who have the best understanding of where you’re starting. But again, that’s why Ja invented POC’s.

The best thing about being in this situation is, you’ve got plenty of time. Support for SIM until 2017? In software, that’s an eternity. Of course, you’re running on the Vampire Child product. And also remember this: all those mainframe dummies who were content with a six-digit date format were scrambling when Y2K came along. You've got a lot of time, and at the same time, less time than you think.