Genesis 11:1-9 tells a very powerful story: Humans overstepping their boundaries by building the tower of Babel, God then identifying their common language as the key element of their ability to collaborate ("the people is one, and they have all one language; and this they begin to do: and now nothing will be restrained from them, which they have imagined to do.").

The last part (underlined) sounds a lot like a great marketing slogan for any vendor of collaborative technologies ...

Now, equally interesting is of course the act and consequences of divine intervention: "... confound their language, that they may not understand one another's speech ... and they left off to build the city.".

If you are using one technology platform like Microsoft Office consistenly across your enterprise, then one value that you are certainly getting is in the "one language" that helps you to tackle massive projects (not necessarily big towers in the literal sense) by seamlessly exchanging important information. And this benefit extends to others outside of your own walls as well: Microsoft Office is widely used by many individuals and companies, so chances are good that you don't have to worry about persuading them to change their tools and throw away their learned Office skills just because they are collaborating with you (important, because as my good friend Niels likes to quote me "Office documents are business process artifacts").

Yet, while being as efficient and effective as you can be on one set of technologies, there is an incremental value in enabling "good" support for non-core processes and opportunistic collaboration. E.g. likely some of your suppliers or customers and partners are using a different vintage of Office than you do, some might be using completely "alien" technologies. These "edge" scenarios are sufficiently important that many vendors (including Microsoft) are working very hard to close the existing gaps by investing in common industry standards to facilitate as much productive collaboration as possible whenever circumstances require it (it's just too much to expect that there would ever be exactly one version of one software product e.g. in the Office category in all cases).

So if interoperability is desirable (and nobody disagrees), it's intersting to look at the implications if you want to systematically plan for all the possible contingencies. I found IBM's take on the current state of their efforts in implementing support for various file formats very interesting; rather than coming up with an assessment of my own, I would like to share the notes that I took during the AD207 session on January 17th at Lotusphere 2010 in Orlando (the slide title was "Interoperability"):

A couple of things are noteworthy:

• Based on the table above, it looks to be very difficult and expensive to track of all the moving parts in a systematic way. This matrix is vastly simplified as it doesn't consider mixed versions (besides the distinction between Symphony 1 and Symphony 3), and it doesn't even look at what would work and what would break (it just, rightfully, points out that there will be "content or format issues" -- IBM's words, not mine).
• In the absence of predictable behavior (it is deterministic but too complex for users to understand), the file open and save commands (when used with "foreign" formats) maybe should have an option like Google did in the old days: "I am feeling lucky".
• Symphony 3 is going to be based at its core on OpenOffice.org 3. Therefore the compatibility claim could be interpreted as "it can talk to itself". Unfortunately, there are apparently exceptions to this (see my previous blog post), implying that any compatibility claim for OpenOffice.org has to identify a specific build (e.g. OOO320m12 build 9483) and cannot be made for one major version (e.g. "version 3"). Also see Orcmid's blog post on his experiences.
• Likewise, the claim that Symphony (both versions 1 and 3) can export to Office binary formats needs an additional qualifier: This is maybe true for the common subset of elements that both Symphony and Office would interpret in the same way. There are exceptions for sure, just to give you two:
• e.g. create a table with 66 rows in a wordprocessing document (in either Symphony or OpenOffice.org), save as .doc. Trying to open this table leads to an error message in Word (any version, including 2010): "A table in this document has become corrupted". Why? Word only supports 64 rows in a wordprocessing table, OpenOffice.org can do more (but the implementation of the PPT export filter doesn't consider this difference).
• e.g. use a custom date offset in a spreadsheet (in either Symphony or OpenOffice.org, in OpenOffice.org it's in the Tools/Options/OpenOffice.org Calc/Calculate section): e.g. chose "01/01/1990 (StarCalc 1.0)" as base. Then enter a date (1/1/2010), save as .xls. If you open this (with either OpenOffice.org itself or with Microsoft Office!) you will experience a shift in all dates (1/1/2010 becomes 12/30/09).
• to be fair: There is a strong warning message when you try to use the old Office file formats to save a file from OpenOffice.org, so there's full disclosure, it's telling you that you might lose unspecified data or formatting (I am missing a corresponding warning on file open though, that might be a good thing to add?).

So where do we go from here?

It's safe to predict that because technologies are different (and should be, or we are back to all of the planet using just one version of one product), likely some "issues" will always remain.

My hope is that through a  variety of means, for a number of use cases, the practical experience of working with mixed technologies could become less of a headache. There are some innovations, both recent and well established ones, that I would like to point out that could be helpful in making progress in this direction:

• If you are using Office 2010 (be patient, we are getting closer to general availability now), you can store your documents in a free cloud service provided by Microsoft that includes free document viewers and editors. Why is this helpful? Well, either the recipient of a document doesn't even have to convert the documents that you send them (because you are using the cloud to share, and they just have to use their browser to collaborate) or at least they can use the pixel perfect rendition of the document through these Office Web Applications to understand if importing an Office document into their productivity tool of choice has caused any issues that they would want to fix.
• There's a nice add-on for OpenOffice.org that allows you to create so-called "hybrid PDF" files. Anybody with a PDF viewer can open these files, but at the same time there's a hidden file attachment inside that contains the original ODF file so that it can be opened by somebody who has the same version of OpenOffice and the same version of the plug-in.
• of course from a standards (and robustness and security and compliance and usability ...) perspective this could probably be considered a "hack", but I am finding the idea interesting in general to effectively provide an alternate rendition of the full document within one widely supported container format (that itself is standards based).
• Microsoft OLE 2.0 is a great platform technology on Windows systems that was created in the early 1990s to allow content elements to become portable across applications, preserving a rendering layer that would also be available on systems that didn't have the original application installed (e.g. Corel Draw and Visio were among the first 3rd party products to immediately take advantage of that).
• again, not a very "modern" or "clean" standard in this age of interoperability (not using SVG etc. -- we are talking about the days a long time before XML ...). Main drawback in my opinion: Not really "cross platform" (still, OS X doesn't have an equivalent, and this has caused me some hardship, so I shouldn't be too harsh in judging this old but trusted friend on Windows). This would be an interesting area to revisit for future versions of our technologies, for sure.

In closing, I would like to thank IBM for allowing some of their best technical people to openly share some insights from their work on interoperability implementations (the excellent Yue Ma and Erik Ma, who were delivering the Technical Overview presentation at Lotusphere).