Enterprise open source Toolkit

Story: Windows' dominance stifles demand for Linux

• 
• 

It's the business processes that are bound to MSOffice

15 years of workgroup oriented business process automation based on the MSOffice productivity environment has had an impact. Microsoft pretty much owns the "client" in "client/server" because so many of these day-to-day business processes are bound to the MSOffice productivity environment in some way.

Many governments tried to replace MSOffice with OpenOffice on Windows, thinking that over time they would eventually be able to replace Windows desktops with Linux. California, Massachusetts and Belgium launched comprehensive pilot studies to determine the feasibility of mandating the OpenDocument format as the cornerstone of this replacement strategy. It didn't work. The pilots all demonstrate the same costly and disruptive dilemma; replacing MSOffice and the MSOffice formats also means having to re-engineer the MSOffice bound business processes!

Here's another thing the pilots discovered. Conversion of documents breaks these business processes.

For instance, one might be able to convert from MSOffice binary/OOXML to ODF with a very high level of fidelity, expecting that OpenOffice/Windows and OpenOffice/Linux desktops would then be able to participate in a workflow. (Eventually taking over the workgroup). These efforts invariably fail though, (as demonstrated by the pilots), because conversion cannot capture the business process elements reflected in a complex compound document.

These elements are represented by such application and productivity environment specific settings such as macros, scripts, OLE, data and media bindings, line of business logic and security settings.

The good news is that there is a great transition underway. The world is slowly but inexorably moving from "client/server" systems to an emerging architecture one might describe as "client/ WebStack-Cloud-Ria /server.

The reason for the great transition is simple; the productivity advantages of putting the Web in the center of information systems and workflows are extraordinary.

Now the bad news. Microsoft fully understands this and has spent years preparing for a very controlled transition. They are ready. The pieces are finally falling into place for a controlled transition connecting legacy MSOffice bound business processes to the Microsoft WebStack-Cloud-RiA model (Exchange-SharePoint-SQL Server-Mesh-Silverlight).

The key to the Microsoft plan is of course that of first controlling the formats, protocols and interfaces important to the Microsoft Web. The eMail treasure trove, also known as the "Comes v. Microsoft" anti-trust case, is filled with Chairman Bill's insistence on MSOffice avoidance of Open Web stapples such as HTML and WebDav. He insisted on proprietary formats and protocols. Otherwise, the great transition would be based on connecting the MSOffice productivity environment to the Open Web and a world of Open Web based competitors with very advanced WebStack-Cloud-RiA systems.

The competitive advantage of the Microsoft WebStack-Cloud-RiA model is the proprietary integration into legacy MSOffice bound business processes. This binding is protected by proprietary formats, protocols and interfaces wrapped in platform specific API's and easy to implement components.

This is complicated stuff, and it will take years for Microsoft to get it right. With the "format-protocol-interface-application specific process" barriers in place though, they have years at their disposal. For instance, take the MSOffice document conversion chain that sits at the heart of this great transition. The first step is installing the "Microsoft Compatibility Pack". This enables a number of format-protocol-interface changes to MSOffice, without breaking existing business processes and workflows. The "format change" sets up the round-trip sequence of MS binary OOXML XAML "fixed/flow". An important "protocol enhancement" activates the SharePoint-Office collaboration protocol. Perhaps the most important "interface enhancement" is that of the XML panel model enabling such things as Web direct data and media binding, collaboration sessioning, and Web enhanced workflow-routing.

The December 2007 MSOffice SDK beta featured a nifty round-trip conversion component for flipping an ISO 29500 document (the XML encoded binary otherwise known as OOXML) to the proprietary XAML "fixed/flow" Web ready format. Notice that there isn't a nifty "round-trip" ready conversion component for flipping an ISO 29500 to the ever ubiquitous and always advancing Open Web format; "HTML-CSS-SVG-JS". And if there was such an Open Web conversion component, does anyone think Microsoft would be considerate enough to include the "in-process" elements so important to the great transition?

Some people think that Microsoft's ambition has long been to carve out a proprietary "Web within the Web". I would argue though that the numbers are such that what we're really looking at is a breaking of the Web. We may be looking at a "consumer Web", dominated by Open Web Google. And a "business Web", dominated by Microsoft.

It comes down to this; there are perhaps 4 billion Open Web documents and 4 billion MSOffice bound "in-process" documents. As MSOffice bound business processes make their way to the MS WebStack-Cloud-RiA model, these "in-process" documents also transition. Microsoft owns the "client" in "client/server", which means near 100% of business desktops protected by the impenetrable barrier of MSOffice bound business processes.

So what can defenders of the Open Web do? How can Google, Cisco, SalesForce.com, and Amazon EC2 intercept the great transition, and direct these business processes to Open Web systems?

One thing the pilot studies showed us is that "replacement" of MSOffice is costly and disruptive because of the bound business processes. But what about "re-purposing" MSOffice?

The exhaustive pilot study conducted by the Commonwealth of Massachusetts is instructive here. They studied the problems of "replacing" MSOffice and determined the disruptive and process re-engineering costs to be too much. This lead to the ODF plug-in effort where Massachusetts IT was basically looking at the Microsoft Compatibility Pack, and asking if the same approach could be used to produce ODF instead of OOXML. They realized that the compatibility Pack was a non disruptive "re-purposing" of legacy MSOffice bound systems, and thought the approach could be cloned to produce ODF.

The problem was not in "cloning" the Compatibility Pack. That actually could be done. The problem was the inescapable truth we now affectionately refer to as "Reuter's Rule"; conversion breaks "in-process" documents.

(Unless of course you own the entire application chain from desktop to WebStack to device).

In 2005, when the events in Massachusetts drove all things ODF, few people understood how impossibly difficult the "in-process" barrier would prove to be. Even more tragic, there wasn't a vision of how important the Web would be to the future of these bound business processes and the documents that framed them.

This is hard to believe, but true. Anyone with a pulse knows that the Web is the future. Yet, look at how much time and effort has been spent on formats, protocols and interfaces that at best would "break" the Web, and at worst, determine to refight the 1995 office desktop wars. In Massachusetts, while the war between ODF and OOXML raged, Exchange and SharePoint servers were showing up everywhere. It was as if the outcome of the desktop office format decision didn't matter to the Web future.

Unfortunately, the forces behind ODF and OOXML were hardly alone in their efforts to either reinvent or ignore of the Web. The W3C also turned away from the core of the Web, the HTML-CSS-SVG-JS document model, to focus on an XML future. Perhaps back in 1998-99, when the shift to XML began, the complexity of an "in-process" workflow-loaded compound document was thought to be beyond the reach of HTML-CSS? Personally i came to work with XML documents because of the extraordinary impact XML had on data. I thought lightning would strike twice.

Today the world looks different. The browser guys stayed with the Open Web, pushing the HTML-CSS-SVG-JS document model to the edge of interactive, intelligent, compound and complex, highly collaborative computing. The WebKit crowd in particular waits for no one. There is no barrier to difficult or frontier to far that these guys will shy away from.

The future of the Open Web continues to be an open question because of the browser push of HTML-CSS-SVG-JS. Sure, it's easy today to see where Microsoft is heading. And sure, they do seem to have an iron grip on the great transition. Encouraged by the browser guys, and the WebKit crowd in particular, i do believe we will soon enough see another round of "re-purposing" MSOffice. This time however, the Open Web will be front and center, competing on an equal footing with the MS WebStack-Cloud-RiA model; with HTML-CSS-SVG-JS the document target, and "in-process" round-tripping intact.

And if we don't successfully re-purpose MSOffice to the Open Web? (And for that matter, OpenOffice). The Web will break. The great transition will be directed to the MS WebStack-Cloud-RiA model. Web enhanced business processes will be entangled with proprietary formats, protocols and interfaces. The barriers to this emerging desktop-Web-device platform of business processes and systems will prove even more impenetrable than the 1995 desktop productivity environment. Linux will not penetrate the business desktop arena. And we will all wonder what it was that we were doing as this unfolded before our eyes.

Hope this helps,
~ge~

• 
• 

• 
• 
• 

Full Talkback thread