The Business of Interop

Walking around the show floor of the Interop Las Vegas show I was struck by the fact that, at least within the context of that show, interop was all about connectivity. The focus of the companies presenting on the expo floor was all about the switches, routers...networking solutions of all types. Within that context the focus for interop was absolutely on standards. Standardized hardware interfaces, standardized communications protocols, standardized, standardized, standardized. Ok - so to my posting of yesterday, and Sam's comment to that posting, standards are important. No argument here. But is that enough?

The answer is no, not for any industry, company, or technology. At the most simple level, a standard is a description of a technology. The whole point of standardization is to create a common understanding of a given technology so that many organizations may create an implementation of the technology. There is nothing that says the implementation should not also have value associated with it.

When people go and build their implementations a world of other factors come into play. Just look at the IBM Workplace ODF vs. OpenOffice ODF implementations. Both are fundamentally based on the same spec, but are there differences? How about the implementations of MPEG, or X.500...or any one of hundreds of specs where this is true. So why is that things work together at all if there is so much diversity when people start to actually build things?

The answer is that everyone in the inudstry then looks to other ways to acheive the interop that their customers are demanding in their solutions. The most common method is in partnering with other vendors or software producers who have synergies with their solutions. Even if there are competitive elements to their relationship, the best way to demonstrate interop is to have some really strong examples that have been brought to market. In many cases, the interop may be limited to a subset of possible parties due to business drivers, testing resource constraints, or any of a hundred reasons.

Or, there are other pathways that technology producers go down just within the archtecture of what they build, or the extent to which they open the door for others to work with their stuff with simple things like software developer kits, documentation of interfaces, sample code to show how to interop, etc.

And, all of this can be augumented further via the IP arrangements that are part of the discussion. Standards bodies themselves are in fact houses built on IP terms. Yes a standards body is there to provided an engineering forum, but the house in which the engineers are working is built with walls made of IP agreements. The collaborations between companies have IP components to them. The result of innovation within a company and the technologies an org may decide to utilize from others to augment their work are also tied up with IP. So, this is an important part of the interop discussion as well.

I am re-hashing my discussion of yesterday, but I run into this all the time and am unsatisfied with the simplistic argument of interop=open standards. As an industry we should look a the success of the discussions in the Identity space where players representing many different development and business models are looking to the full spectrum of opportunity to deliver inteorperability.

I think we are even capable of doing this in a more contentious space such as doc formats.