Office 2.0: A Paradigm or a Product?

With plenty of time to get the thinking caps rolling, I'd like to share some of my thoughts on Office 2.0. I'm approaching it from the standpoint of designing a next-generation redefinition of the office paradigm, essentially breaking enterprise collaboration out of the fixed document format into an XML-based, schema-driven world. Here is my first-pass list of key issues in creating an Office 2.0:

Define data formats so that Office 2.0 can do mashup-style integration with next-generation web tools.

Get away from 'document' formats like RTF and instead go to a markup-interpretive model with full support for XSLT, microformats, and schema templates.

Set up schema registrars and data interchange registrars, integrated into a PKI-like system that allows transitive trust in EDI.

Attempts to define functionality, formats, and features from 'on high' are an outdated legacy-- move to a purely data-driven, schema-centric model where 'Office 2.0' is an interoperability suite rather than a suite of programs with a captive user population.

Where Office 2.0 'wants' to go is to a place like where Apache, Mozilla, and Firefox are today; nobody's going to make a lot of money on that, so it's not a popular destination in the business world. Yet I believe that only an Office 2.0 effort that goes there has any real chance of succeeding. Small pieces, loosely joined-- in this case, via the data model.

Being able to mix templates within a document, and interpret them with Office 2.0 gives one essentially embedded application abilities.

Software as a Service and/or ASP model would be revenue drivers, but applications would certainly arise for independent access. One might pay licensing for use of licensed templates, ASP usage (software as service), custom development of schema, proxying/brokering service with escrow of trust, etc.

Establishing Service Level Agreements for levels of interoperability with current tools will assist in driving adoption of Office 2.0. Leveraging today's database-driven dynamic information models and using database as CRM provides the foothold necessary to get traditional enterprise to consider the new model.

For a schema-centric model such as I'm proposing, we might explore the SLA requirements for interoperability and translation between Office 2.0 document templates and traditional office formats such as RTF. A barrier to adoption of Open Office in many environments has been formatting and display problems when going between document formats.

The widespread success of Adobe's PDF as an information transmission model suggests that there is also a requirement for an SLA for document anti-tampering, whether the tampering is benign or malicious.

The beauty of a schema-centric approach is that one can essentially 'skin' an Office 2.0 editing and manipulation environment to suit a wide range of customer experience and preference. Some of the potential user groups have such differing UI expectations that a universal UI design is, in my opinion, a red herring which will only serve to distract attention from the underlying mechanics of building Office 2.0.