Hi Matt,

Right on! You nailed it. Although i tend to think in terms of an information processing chain where EOOXML is both the file format and the transport. Microsoft gets the portable document model, where content, data and streaming media traverse in highly exchangeable XML document containers.

The Microsoft chain runs MSOffice > EOOXML > VSTO > IE 7.0 > the Exchange/SharePoint Hub. From the E/S Hub, it splashes out into a galaxy of server and device side services such as MSLive, MS SQL Server, and things like MS ERP.

The core of the chain is that everything speaks EOOXML, even applications written with VSTO 2005, (they dropped MSXML in favor of EOOXML).

What most people fail to understand is that there are two barriers to entry/migration from MSOffice. The first barrier is that of the billions of binary file formats bound to MSOffice.

The second barrier is that of MSOffice bound business processes, and it's near impossible to overcome. Most people don't even get this far, giving up in frustration with non interoperable file formats and lossy conversions that plague the first barrier. However, for those who do get this far, which they did in Massachusetts, the second barrier is near impossible. The barrier of MSOffice bound LoB's (Line of Business), business processes, and assistive add-ons seems impregnable.

Since 1995, MSOffice has evolved to become the platform of critical day to day business processes. You can't replace these workgroup – workflow processes with OpenOffice. Nor can OOo "participate" in existing processes unless there is perfect fidelity of file conversions - otherwise known as perfect roundtrip fidelity.

The good news is that in the very near future every one of these MSOffice bound business processes is going to migrate to an Internet "XML ready" Hub of some sort. The bad news is that Microsoft is killing everything in sight with the MSXML-EOOXML E/S Hub. Including Lotus Notes.

As you might guess, the E/S Hub has great "integration" with the MSOffice desktop productivity environment. A level of integration that can't be touched by any other vendor, be they Oracle, IBM, CA, BEA, SalesForce.com, JBoss, or Apache OSS. What makes the migration of business processes to E/S Hubs inevitable is the incredible bump in productivity any process gets when moved to an integration Hub.

Interestingly, the MSOffice point of integration in this emerging processing chain is that of the XML file format; EOOXML. Because the portable document model is so critically important to these Internet enabled processing chains (you can't do this kind of sprawling data binding - workflow routing with binaries), many governments are seeking an ODF plugin for MSOffice.

The idea behind the ODF plugins for MSOffice is to turn MSOffice into an ODF pump instead of a pump for EOOXML. The advantages are twofold - both the first and second barriers to migration are broken. And broken without any disruption to the current business process flow, or cost of re engineering to an MSOffice alternative (if that were even possible).

Once MSOffice is converted, and an ODF pump is in the anchor position, those MSOffice bound business processes can be migrated to anything that can speak ODF. All the server side services (hello IBM and Oracle) that get cut out of the Microsoft chain can cut into an ODF one without a problem. To get "great" integration and perfect interoperability though, applications in the chain have to break with the long standing traditions of being information "end points", and become routers of information - adding value but not breaking the flow.

Sadly, few application understand the emerging processing chains and the new demands for "routing" information. For instance, Google Writely supports ODF, but only as an "end point". Information might go into Writely, but it doesn't come out in a useful ODF structure. The law of these emerging processing chains seems to be that of perfect "roundtrip" fidelity on transformation. Applications must assume that the information flows they link into never stops. Even enterprise publication, content and archive management systems must keel to the law of interoperability if they are to compete against the MSOffice > EOOXML > E/S Hub Juggernaut.

So what i think we need most at this moment in time is ODF ready Hubs; where content, eMail, scheduling, workflow management, data binding, workgroup management, and project management merge with the ODF – XForms document model.

If we can intercept the migration of MSOffice bound business processes, using ODF plugins and ODF ready Hubs, the final step to breaking the monopolist grip is within reach. Once the business processes are in ODF and residing at the Hubs, where all kinds of server and device systems can integrate as needed, it's easy to replace MSOffice on the desktop with an OpenOffice – Mozilla one two punch. Yes, the desire of the plugin makers is to eventually replace themselves with OOo. Before that can be done though, we have to work through a period of mixed applications whose only point of interoperability is that of speaking perfect ODF.

You are right about the longterm lockin. I watched this happen last year with the real estate industry. It's a good story, but too long for a blog comment. The take away point however is that the real estate industry bought into the E/S Hub big time, and many vertical applications of extraordinary productivity swept into the marketplace. The E/S verticals quickly replaced near every desktop productivity shrinkwrap app, even those with over fifteen years of dominant marketshare. Vertical vendors fought to replace their own shrinkwrap stuff with their own E/S products. It was the only way to survive. The E/S Hubs automagically converted binary bound documents to MSXML, making them unreadable with anything other than MSOffice 2003 and IE 7.0. Every Windows 2000 desktop was EOL'd one fine Friday afternoon last year when the mothership sent out a security upgrade to E/S. An upgrade that required IE 7.0, for which there is no W2K version available. A Friday afternoon in real estate. Fry's was hopping.

The Realtors moved to E/S Hubs en mass because the productivity gains truly are extraordinary. One could easily argue that that industry is locked in for the next 15 years.

Even though Massachusetts was mandating ODF, they were buying E/S servers, thinking perhaps it's just an easy to administer eMail system. Right. The Commonwealth is just one court docket system written to E/S away from having to convert all those ODF docs back to EOOXML. Oh wait, with the MS Translator, E/S will automagically do that for you :)

Thanks for bringing this issue forward,

~ge~

Matt-

Perceptive post!

However, what file format do you propose to work in if not ODF? Microsoft Office Open XML?

I find your conclusion about the formats to be defeatist.

It's the application-centrism that smells of 1995, though I grant you everything you observe about the shift and SharePoint.

Unequivocally, our view is that ODF is the centerpiece -- the enabler -- of SOA and the whole set of alternatives to the locked-in chain you so correctly point out.

That's why it's critical that Alfresco, Plone, ansd Zimbra -- to suggest the obvious candidates -- speak 100% ODF and become enabled with 100% file fidelity for roundtripping documents originating from ODFPlugin-enabled legacy MS Office source. 468 million of them.

(You're overdue for a chat with Gary Edwards out there.)

Matt, there are those of us who are ready to help push Alfresco and similar products into the SMB market, but we need the ODF compatibility and a consultants' training sign-up location.

Sharepoint... Firstclass is better!