Talking Identity

So it seems that someone finally slipped up and gave me an outlet for my ramblings. One can only hope that this will lead to something useful. Fostering a community takes time, but maybe this will give me a way to finally harness the raw knowledge that I experience in my job every week.

At the end of another customer council meeting, one thing was abundantly clear -  our customers have no intention of being faceless names on a list somewhere. They have opinions, they are vocal, and they would very much like to be a part of the development process.

Hot button topics were support, roadmap visibility and role management. The last was particulary interesting. Having participated in many one-on-one discussions about it over the last few months, it was fascinating to see how the topic exploded in the meeting into a cacophony of thoughts, rants and ideas. Everyone had a different idea of what roles are, how relevant it is to their identity projects, and what they would like to be able to do. Some people were candid enough to admit that they had no idea where to begin, while others (surprisingly) said that they couldn't care less. And the number of people who talked about failed role management projects was a little disconcerting.

Talk about jumping out of the frying pan...

One thing that I found surprising at the CAB was the lack of discussion around SPML. Admittedly, the standard hasn't made enough progress, and is nowhere near the maturity that (for instance) SAML has achieved. But I would have thought that the need for it would make it a hot issue for those who haven't seen enough being done on it.

And yet, discussion about SPML was noticeably absent during our session on standards. And the feature/functionality prioritization discussion had it almost at the bottom of the list. Now, one dream scenario would have us crediting the success of the Adapter Factory as the reason for this disinterest. But that would be a little glib. It would be interesting to figure out why SPML gets no respect.

Is it because the true use case for SPML is not target provisioning, but federated provisioning, and the lack of true federation deployments is keeping demand at a low? Or is it that the investment needed to make SPML a viable standard is not being observed in the marketplace, and customers have all but given up?

It would be interesting to know if companies are putting the development of SPML interfaces on the list of deliverables for their custom-built applications. SPML support exists in pretty much every provisioning product of note today, so the fact that application vendors are slow to incorporate it into their apps should not stop SIs and development teams from using it as their provisioning API interface. We have been working closely with one of our large customers on defining how they can establish an SPML-based development standard within their application teams so that integration into their provisioning deployment is quick and easy. Are there other people out there doing the same?

One thing is sure, SPML needs some impetus. Within Oracle, the sheer size of the application portfolio is proving to be a driver for SPML adoption. As we work on building tighter integrations between our IdM products and our applications, the consensus is that the integrations should be based on SPML. The debate this is generating is interesting. Philosophically, basing the integration on a standard negates any possibility of building a "best-in-class" integration that no one else can build/replicate. However, it does provide (us) a buffer against the integrations breaking as the two sides evolve at different speeds.

In an internal memo last October, Ray Ozzie, CTO for Microsoft, wrote, "Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test, it introduces security challenges and it causes end-user and administrator frustration."

Amen to that! That is why the new focus of the IdM groups should be (and will be) the move to simpler business flows, easier interfaces, and clearer concepts in our IdM suite of products.

Working as I am on the architecture for the next generation of our IdM products, I found the thesis of this article extremely interesting. It basically uses Windows as an example of how the cost of innovation increases dramatically with any attempt to make that innovation backwards compatible. And points out how Apple tackled a thorny problem in a manner that, while not perfect, was good enough to move forward.

http://www.nytimes.com/2006/03/27/technology/27soft.html