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.

Comments (4)

  1. Jack Johnson says:

    Interop Dynamics ??

    Since your post was on Interop, and I keep hearing MS folks (Muglia most recently) and Novell folks, talking about how core Interop is to the recent MS/Novell patent pact, my question is "Does Interop require payment in the software business ?".  It seems that Oracle does not charge to interop with their DB, or Sun does not charge to Interop with Solaris, or BEA with WebLogic, or IBm with AIX or Websphere.  

    Yet it seems that MS has taken liberty with the term Interop and is trying to use it as the blanket term for other things, and as a sweeping rationalization (almost 3 card monty-esque).

    I just have a hard time with it, and I think others do also. So I would be cautious in how many things you/MS apply the "interop" rationale to. Curious if you can see this, or not, from where you sit.


    Jack J.

  2. jasonmatusow says:


    We don’t charge to interact with our DB either. ODBC, ADO and a wide range of other data access, migration, transformation, etc. tools are available to work with our database products. All of the companies you list go thorugh the exact same process we do when they think about interop. They have to make design decisions about their products, the interfaces they build, the documentation they pay to develop etc. etc. They partner with others (we have partnerships, collaborations, or some form of interaction, for example, with all the companies you list). They license their IP for interop (we pay $ every year to IBM for LU 6.2…never mind other patent cross licenses we are party to with these companies). And, they work on standards as do we and many other players.

    I don’t think we’re taking liberty with the term at all. I think we are attempting to be extremely clear about what we are doing rather than whitewash the topic with a simplified statement. There are presentations I have seen from some of these companies that state that we should have all open interfaces for some parts of the stack (those they are not leading in) yet have complete lock-down on their solutions where they are leading the industry.

    My whole point in this is not to say that everything should be interoperable by default. There is a very good reason we talk about "interop by design." We do it on purpose, but there are places where we don’t as well.  

    Clarity is important to me and I think our position represents what we actually do in our business. I would hope you hold the other vendors to a similar standard.

    Anyway, thanks for the comment.

  3. Wesley Parish says:

    I think the best example of Interoperability is the TCP/IP networking stack.  And that was achieved in spite of, not because of, the standardization work on the Open Systems Interconnect.  The reason?  TCP/IP was already there in the marketplace, and working very well, thank you, not being argued over by a pack of standards committees.

    Which brings us to the contentious documentation standards issue, doesn’t it?  (At least, if I don’t mention it, I’m sure you will. 😉

    I’ve downloaded the OpenXML Writer off, and had to chivvy them into shape re its license.  I downloaded both the binary and the source distributions.  (I’d got a copy of WinXP and Visual Studio 2005 at the local Uni where I’m doing some credit papers in Computer Science, so thanks to Microsoft for that. 😉  The binaries won’t run; the source won’t compile; I have no idea who to contact at to mention this to.

    I can download several different free implementations of ODF, and read and compile the source code.  There are two sort-of implementations of ECMA 376 aka Open XML docx that I know of – one when distributed as a Linux binary by Novell, won’t link with my pre-existing 2.x; the other won’t either run or compile on my copy of WinXP plus Visual Studio.

    You’re absolutely right in saying that interoperability is a lot more than merely open standards.

  4. jasonmatusow says:

    No matter how long I am away from my blog I can always count on you Wesley to be there when I get back. 🙂 Hi – I hope all is well this late fall for you.

    I totally agree about the implementation being more important than the standard. Ultimately, no matter how technically elegant the standard may be – it is all moot if the implementations suck. Moreover, the most powerful "standards" in the market today (Linux kernel, Win32…) are not formalized standards – they are market adoption of implementations that have made them so interesting.

    As for the Open XML stuff – I will send an email internally and see what I can dig up for you on the downloads. The availability of Open XML implementations will take time, but we know that many folks are working them. I’ll see what I can find out from my guys who are much deeper technically than me.