by Mark Diodati | August 20, 2010 | Comments Off on Consensus on the Future of Standards-Based Provisioning and SPML
I had the honor of facilitating the Standards-Based Provisioning Special Interest Group at this year’s Catalyst conference. The participants believe that standards-based provisioning is at a crossroads and wish to publish the following statement. The statement is based upon our conversation; all of the participants have reviewed it. I hope that the perspectives of these industry luminaries push the industry (and the especially the newly-reformed OASIS Provisioning Services Technical Committee) towards a viable provisioning standard.
Moving Forward on Standards-Based Provisioning
On Tuesday, July 27 a group met at the annual Burton Group North America Conference in San Diego to discuss the future of standardized provisioning and Service Provisioning Markup Language (SPML). The group readily achieved a consensus about two things: the need for standards-based provisioning and the qualities required for successful provisioning standard. The following people participated in the special interest group (SIG):
- Abdullah Haydar (Open Dealer Exchange)
- Andrew Ferguson (e2B2Bcom)
- Anil John (Johns Hopkins)
- Ash Motiwala (Identropy)
- Chuck Mortimore (salesforce.com)
- Jacob Farmer (Indiana University)
- Jonathan Sander (Quest)
- Mat Hamlin (SailPoint)
- Nick Nikols (Novell)
- Nishant Kaushik (Oracle)
- Steven Legg (e2B2Bcom)
- Tony Goulding (CA)
The participants have firsthand experience with the difficulties of proprietary provisioning from the perspective of both vendor and end-user organizations. The SIG meeting was particularly timely, as the Organization for the Advancement of Structured Information Standards (OASIS) is evaluating the need for an SPML v3 standard. Additionally, the SaaS market is at a critical juncture as vendors look for standards-based solutions to the provisioning problem.
The second iteration of the SPML standard was approved in the spring of 2006 and included additional capabilities and operational modes. In trying to address every possible use case, interoperable provisioning services leveraging the SPML v2 standard became impractical. Since the approval, few (if any) conformant implementations exist due to the complexity of the v2 standard. Additionally, vendor participation in the OASIS Provisioning Services Technical Committee (PSTC) has been nearly non-existent since v2 was approved.
Organizations wishing to use SPML must write provisioning services specifically for each vendor’s SPML implementation (if the vendor supports SPML at all). The difficulty in building a single, interoperable provisioning service has made the adoption of SPML by application developers a non-starter. Without adoption by enterprise and cloud application developers, SPML will not be adopted. In conclusion, the SPML v2 standard is broken.
Back to Basics
The next iteration of SPML should focus on solving “the connector problem” and provisioning use cases for cloud-based applications. That is, the next version of SPML should readily enable the development of simple, standards-conformant provisioning services for both enterprise and cloud applications.
The participants agree that a standards-based provisioning protocol is needed, and all concluded (except Chuck Mortimore) that it is best to evolve the SPML standard rather than introduce a new one (salesforce.com has not yet arrived at this conclusion). The next iteration of SPML needs to become simpler. It must support a simple use case for conformant, standards-based provisioning services. Additionally, the SPML standard is too imbalanced; it places too much burden on target applications. The participants assert that the next version of SPML must possess a “simple” profile for to be successful. The simple profile should include the following qualities:
- Provide basic create, read, update and delete (CRUD) operations.
- Focus on the default use case of a single provisioning service point (PSP) and provisioning service target (PST). This use case is the default one for application developers and end-user organizations.
- Eliminate transactional auditing requirements. In particular, the Updates capability places an impractical data retention and performance burden on the application.
- Support a simple search mechanism. The current search mechanism can create nearly infinite search parameters across all known user attributes, which places an undue burden on the application.
- Enforce conformance. Vendor’s products must undergo conformance testing prove interoperability. Conformance likely requires a reference implementation.
- Provide an optional, standard schema. An optional standard schema (like LDAP’s inetorgperson) provides a potential schema for immediate interoperability with other applications.
The Path Ahead
It is up to vendor and end-user organizations to move the SPML standard forward so that the industry can begin to build interoperable provisioning services. If you are interested in influencing the direction of standards-based provisioning and SPML, please consider participating in the OASIS PSTC.
Read Complimentary Relevant Research
Cloud Computing Primer for 2018
Cloud is evolving from a market disruptor to an expected approach for traditional and next-generation IT. Our research offers actionable...
View Relevant Webinars
The 2018 Security Threat Landscape
The security threat landscape has been exciting and surprising. But what is next? Gartner presents the best predictions on how the threat...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.