Freigeben über

Interoperability: what's in a name?

  • Artikel

Interoperability is one of those words that means different things to different people. We all agree that it means something like "the ability of systems to work effectively together," but beyond that our agreements get murky at best. Consider, for example, the classification of of business products and services into "horizontal" and "vertical" markets, as shown here:

The fundamental concept is that a vertical market encompasses all the business activity within a specific industry (healthcare, say) regardless of the type of system or software, whereas a horizontal market (word processing, for instance) corresponds to a specific type of functionality that is used across multiple industries. This chart shows just a few typical examples, and others might include retail or government vertical markets, email or presentation horizontal markets, and many others.

Now, when you use the word interoperability, which do you mean? Horizontal interoperability -- between competing spreadsheet products, say -- or vertical interoperability, such as interoperability between all of the systems used in an insurance company?

I think the answer usually depends on your perspective, and specifically on what you do for a living. For those of us in the software business, it's tempting to view the world in terms of application types: word processing, spreadsheet, email, etc. So we tend to think of interoperability in that way, as a horizontal-market concept: can these two word processing programs share documents? Can these two databases share data?

But if you're in a business where technology is just a tool rather than your core business (i.e., a vertical market), you probably have a quite different view of interoperability. For example, if you work in an manufacturing company, you probably see interoperability in terms of the ability of your various systems -- ERP, accounting, distribution, logistics -- to effectively communicate with one another.

There may be an occasional need for horizontal interoperability within a vertical market, to be sure. For example, you may have upgraded from one word-processing program to another, and you need to be sure you can open the old documents in the new software without any surprises. That's a very common scenario. But the concept of two word-processing programs sitting side-by-side on your desktop is rare in the corporate world, because most organizations standardize their use of horizontal applications wherever possible, to reduce ongoing support and maintenance costs.

Document Formats and Interoperability

Standardized document formats play an interesting role in this horizontal/vertical view of interoperability, because they can enable interoperability of both types. For example, the Open XML formats enable horizontal interoperability by supporting all of the functionality in existing Office binary documents, and they enable vertical interoperability through custom schema support. The ODF translator project further extends horizontal interoperability by providing a bridge between the worlds of Open XML and ODF documents.

Another concept that is closely related to the questions of vertical/horizontal interoperability in document formats is the difference between technical and semantic interoperability. (Thanks to Vijay Kapur for helping me see this perspective clearly.) Technical interoperability between word-processing applications means that we have a standardized method for marking text as bold, how to indicate font size, and similar issues. Semantic interoperability occurs when we standardize how we represent business concepts such as customers, orders, invoices, and so on. Referring back to the chart above, semantic interoperability enables vertical interoperability and technical interoperability enables horizontal interoperability.

Semantic interoperability is the much more challenging thing to achieve, because the needs of each industry are different. Everyone knows the concept of bold text, but only those in the insurance industry think about policy limits and claim numbers, and only those in education think about test scores and classroom scheduling. So each industry or trading group tends to have its own jargon, and that jargon is often codified and standardized in a schema that defines the structure of the XML documents used in that industry.

Open XML's custom schema support

In Open XML, there are two general approaches for supporting these custom schemas. (By the way, a bit of jargon to understand: the Open XML spec refers to its own schemas as reference schemas, and all other schemas -- such as your industry's unique schemas -- are called custom schemas.)

The first type of custom-schema support is custom XML markup, or content tagging. You can use a custom schema to tag the content in a word-processing document, for example, by inserting customXml elements around chunks of content within the body of the document like this:

<customXml uri="https://MyNamespace" element="MyElement"> ... content that is tagged with this element ... < /customXml>

Typical uses of this approach would be to tag content within a document to identify the customer number or order number for an order-processing system, or to tag the title or abstract of a document for a content-management system. This type of content tagging can be nested as required by your schema, and there are options in Microsoft Word to tag content manually through a simple user interface. Custom-generated documents can also have the markup added programmatically, using the syntax shown in the example above.

Note that your own custom elements aren't added to the document markup directly. Rather, there's a customXml element that is already defined in the reference schemas, and your custom elements (e.g., MyElement) appear as attributes of the customXml element. This simple and flexible approach is also used in microformats, which similarly add semantics to XHTML pages without the need to add new elements or change existing reference schemas.

Another way that Open XML supports custom schemas is through custom XML parts, which can be based on any schema at all. These parts are inserted into a document as a stand-alone island of business data, and the nodes in that custom data can be bound to presentation elements such as structured document tags (content controls). This architecture makes it very easy for custom business applications to read and write the business data in a document without processing (or even being exposed to) the document-related markup itself.

I'll provide some specific examples of content tagging and custom XML parts in future posts, but this one is getting a bit long so I'll wrap it up for now. They key concept I wanted to cover today is that interoperability means different things to different people. Those of us in the technology business need to worry about technical/horizontal interoperability, but most people in other industries need to worry more about semantic/vertical interoperability, because that's the key to integrating disparate systems and business processes.

In future posts, I'll show some specific examples of documents that use Open XML's custom schema support to enable vertical interoperability in various scenarios.

Comments

  • Anonymous
    March 01, 2007
    Nice one.   I tend to identify some activities as diagonal, rather than vertical or horizontal.  This happens with facilities that might be viewed as infrastructural, and might even be out-sourced or facility-managed.  IT itself has this quality, although the example I'm most comfortable with is production printing systems.  The Exchange/Sharepoint stack, with its prospects for customization has a certain diagonal quality in my view. I suppose we might say that an Office Open XML document with custom content has been diagonalized.  The use of templates and profiles (for constraining what gets used in the context of a particular application) seems to fit as well. Thanks. Lots to think about.

  • Anonymous
    March 02, 2007
    Good point, shapes other than vertical/horizontal lines make sense.  As the saying goes, there are two types of people, those who divide everything into two categories and those who don't. :-) I mainly wanted to point out that agreement on things like text-formatting concepts, however important that may be for other reasons, doesn't have any relevance to semantics-based interoperability between different types of systems.

  • Anonymous
    March 02, 2007
    "I mainly wanted to point out that agreement on things like text-formatting concepts, however important that may be for other reasons, doesn't have any relevance to semantics-based interoperability between different types of systems." Except when it does, of course. I thought you made a good point there. And there is an amusing problem when people think <em> is somehow more semantic than <i> but they still show a button with an italic "i" to introduce it.  Heh.

  • Anonymous
    March 03, 2007
    Interesting argument.  I do disagree with the idea that companies are only concerned with the vertical.  Companies frequently exchange data (often in the form of files) with other companies.  So there is also a need for the horizontal interop there.  Sometimes an externally-created document must be utilized in a company's automated processes, with or without locally-added modifications.

  • Anonymous
    March 04, 2007
    "The ODF translator project further extends horizontal interoperability by providing a bridge between the worlds of Open XML and ODF documents." There is no "bridge"; the translator doesn't work.

  • Anonymous
    March 09, 2007
    I just ran across an use of "diagonal functionality" in a great slide deck by Brent Williams.  It is on slide 41 of 48.  Williams also mentioned "Project Green" (Microsoft Dynamics) as an example.  The slides were put up by Stephen Walli on his blog: http://stephesblog.blogs.com/my_weblog/2007/03/the_best_presen.html I recommend this for anyone in the software business, especially at Microsoft.  Matusow should love the part of the pitch on Eclipse at the end.

  • Anonymous
    April 01, 2007
    I have been talking about Interoperability last few months and have to say in summary - for 4 people

  • Anonymous
    May 19, 2007
    I've seen some signs of confusion about custom schema support lately. For example, I've seen a vendor

  • Anonymous
    May 21, 2007
    J'aurais aimé faire un post complet sur ce sujet, mais le temps se fait désirer en ce moment ... à cause

  • Anonymous
    October 16, 2007
    Voici le dernier post sur les 10 questions posées à Microsoft France. Vous vous demandez pourquoi avoir

  • Anonymous
    October 24, 2007
    Voici le dernier post sur les 10 questions posées à Microsoft France. Vous vous demanderez sûrement pourquoi