By webmink on Jul 10, 2006
Back in 1997, I was working to evangelise XML as the data format of the future. One of the common questions I was asked was "where should I use XML". I explained back then that XML was ideal as a language for describing data in transit between two groups of people of systems that were not under the same management. What you used in your workgroup or department was up to you, but pervasive networks meant you would increasingly be working with people well outside your authority umbrella. In those cases, a format would be required that minimised the technical coupling encountered during attempts to collaborate.
Use of binary formats led to a need for tight coupling of the parties consuming and creating them as well as of both parties to the entity controlling the format. I asserted back in 1997 that XML promoted the same loose coupling for data as the use of the Java platform allowed for programs. This was a recurrent theme of my keynotes in the late 90s.
Fast forward nine years and it seems we're entering the stage I forecast back in 1997, but for documents. I've been using the term "workflow" recently in discussing the way ISO 26300 OpenDocument (ODF) fits the way people are increasingly working. We've already seen that the concept of a "Service Oriented Architecture" is intellectually appealing (even if it's been hijacked by complexity fiends), and I see no reason why the desire to have organisationally loosely coupled entities co-operate should force them to become technically interdependent.
Best Tool For The Job
Hence my overloading of the term "workflow" (and search for a synonym I can use instead). The truly great thing about Microsoft's flawed announcement last week is that it takes the product and vendor dynamics off the table as obstructions and allows us to focus on what really matters - working together efficiently in a connected, participation age. Everything is going to be able to open and save ISO26300 OpenDocument files in time. Everything. Now we can distinguish between the policy decision about what's flowing between and the pragmatic decision of what's being used within. Loosely-coupled workflows are the answer.
For example, I may choose to use the very promising browser-only Zoho Writer [thanks, Robert] which promises to be able to both open and save OpenDocument files and thus, by giving me the freedom to leave gives me the confidence to stay. Or I may be a writer with special interface needs because of a disability, locked into some version of Microsoft Word because the accessibility device I paid a fortune for only works there due to a lack of accessibility standardisation (which, by the way, is getting fixed fastest on GNOME). Or I may use OpenOffice.org or NeoOffice or something. Who cares. That's my choice, and whatever you have chosen you have no right to dictate what I use.
Meanwhile, the networks-of-purpose within which I participate can still mandate the format I have to use to exchange documents with other network members. Those networks will choose OpenDocument simply because it opens up the widest range of choices, from the crustiest version of Word to the newest, most exciting ideas like Zoho Writer. They will choose OpenDocument because it offers a baseline that will still be readable for decades yet will also provide a baseline on which innovation can be built. And they will choose OpenDocument because it is transparently in the stewardship of a truly open standards process and licensed in a truly no-strings-attached way.
So when you hear me talking about "loosely-coupled workflows" in this context, this is what I mean. I can choose the best tool for the job to do the work, but when the work flows between loosely-coupled partners in my network it won't make us technology-dependent on any given platform, tool or vendor. If loosely-coupled is good enough for SOA it's good enough for documents too.