Is SPML the Rodney Dangerfield of Standards?
By Nishant Kaushik on Mar 27, 2006
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.