Collaborative Advantage: What is interoperability, really?

1/30/2013 9:00 AM EST

When industry leaders collaborate to create a standard, the reason always cited is “interoperability”.  Yet do we really understand what is meant by this seemingly simple term?  Because there is sometimes confusion about the nuances of this concept, let’s explore its meaning in greater depth.

The first point is to be precise what must interoperate at the outset.  Tool-to-tool interfaces are most often assumed, numerous library-to-tool interfaces are essential, and user-to-tool interfaces are also very popular (such as with any design language).  Sometimes, a request for tool-to-tool interoperability also requires specifying an associated library-to-tool standard for the interoperability benefits to be realized – this should be clearly understood up front.

The next choice is to define the appropriate architectural level of abstraction for the task at hand: data-based versus file-based interoperability.  This is a tradeoff of “what versus how”, and is critical to comprehend, and apply, in the proper context.  Data-based interoperability ensures that the information (semantics, data, and their relationships) is preserved across tools and/or libraries.  Since this is where the most effort is invested in our electronics industry, and represents the actual IP content, it is by far the most important asset to protect and typically the true business goal behind “interoperability”.  File-based interoperability represents a common implementation format, and is also very convenient; however it emphasizes syntax for one single format, sometimes in lieu of clear data semantics.  The main problem with file-based interoperability is that it may not be practical when multiple formats are already well-ingrained across the ecosystem (and unlikely to change).  The ideal case is to enable both data and file-based interoperability when feasible, but data can be automatically mapped into multiple syntaxes if the semantics have been well-defined.  For interoperability problems where proprietary file formats are solidly entrenched (for any number of reasons), data-based interoperability is the only practical, widely-adoptable solution.  As Albert Einstein famously stated, “The significant problems we face cannot be solved at the same level of thinking we were at when we created them.”

The architectural decision for interoperability must also be based on the expected “use cases”.  For example, an API provides the most efficient protocol of communication between running tools or between a tool and a library, especially for large / complex data, however files are still necessary for persistence and transfer.  Also, not all file formats are the same: some may be simple parameter-value pairs, while others may represent a full (human-editable) “database” incorporating self-checking features within a formal XML/XSD structure.  Furthermore, business constraints may require special handling of IP protection and encryption that must be included in the architecture.

To be clear, an interoperability challenge may demand more than one type of interface or one abstraction level.  Designing chips requires complex flows among many teams and tools, and for any given use case, a combination of the above choices may be necessary.

The business goals of “interoperability” are almost always driven by economics, efficiency, and quality.  In some cases, an emerging technology or market will require interoperability to enable that commercial market opportunity to be realized.  While 1:1 partnering between customer and supplier remains essential, an array of differing and confusing formats is sometimes insufficient to hit the “economic threshold” when information must pass across a supply chain.

Finally, I will note that a standard only has value once adopted.  The true measure of interoperability value is not the number of logos on marketing slides, but by how well it has actually solved the problem once it has been released.

I’d like to hear other thoughts on how you define interoperability – feel free to comment!

Steve Schulz, President and CEO, Si2

More Collaborative Advantage blogs