Standards are the new (again) bright and shiny objects in the sky. These days, beyond the work that is going on in the formal international standards development organizations, you can’t turn around without tripping over vendor run consortiums or just groups of vendors getting together to develop a “standard” around something that is near and dear to them, or working to get community buy-in for something that has been developed internally by putting a “contributing-it-to-X-to-make-it-a-standard” label on the work.
Since I believe that a Standard without vendor adoption and implementation in products is nothing more than shelf-ware, I am pretty neutral about the variety of processes to get to that end goal, provided that there is opportunity for open participation by all interested parties in the development, and the end-product is open and re-usable to all without onerous licensing and/or IP restrictions attached to it.
Ultimately, standards commoditize the interfaces between systems, so from the perspective of an organization that is seeking to implement a capability to solve a business problem, how do you determine where standards matter and where they don’t? How do you choose between two products that implement the same standard? Where role does agility and innovation play in this decision?
In order to answer all of these questions, the starting point is to properly define the boundaries that will determine where purity (i.e. Standards Compliance) rules, and where pragmatism (i.e. Implementation Flexibility) should be the primary consideration.
Using the above diagram as a guide, one should place a priority on purity at the interfaces between systems deployed across organizational/sphere-of-responsibility boundaries. A concrete example of this would be in the case of an organization seeking to deploy a relying party web site (App B) that accepts federated credentials from an external Identity Provider (App A). It is critically important to use specific standards (or profiles of standards) in the communications between the User (agent), Identity Provider and Relying Party.
At the same time, within the organizational/sphere-of-responsibility boundary, one can be much more pragmatic about implementation. Extending the federated identity example noted above, the ability of the relying party web site (App B) to accept federated credentials will require the internal deployment of a Federation Engine (App B-1) and potentially an Externalized Authorization Manager / Entitlement Server (App B-2) to manage and enforce access control rules. The organization has the option of taking a much more pragmatic approach to how those three pieces talk to each other.
This pragmatic approach allows one to leverage vendor innovation and flexibility. Smart, capable and forward-leaning vendors realize that their products do not work in isolation and build in interfaces that ease integration with complementary products. They also realize that they have an opportunity to distinguish themselves from their peers by offering unique and value added capabilities to the Enterprise in their approach to integration. Some things that I can think of in the area of federated identity are supporting the surfacing of privacy constraints and attribute release rules to the end user, minimizing dependencies on third party products etc.
In short, by balancing purity and pragmatism, you are able to build and support an interoperable system while taking advantage of diversity and innovation.
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.