Project Management

[Gary Edwards <garyedwards@yahoo.com>]

Hi David,

The original request to consider a contact – project management extension to the OASIS schema came out of the OOo Glow-OpenGroupware Projects. The request came out of concern that a single OASIS XML file format be able to cover the needs of a much wider productivity environment than that defined by traditional “Office Productivity Suite” products. While the OASIS XML file format is extensible, the thinking was that a much higher degree of cross application interoperability and ease of implementation could be gained by baking into the spec the fundamental needs of contact-PiM-project management (schedule-calendar-address) information.

I took the request to the OSAF Chandler Project to see if they would be interested. At the time, they were more concerned about the functions and features of Chandler than about an XML file format. I have tried to convince them to write Chandler not as a traditional stand alone application suite of services, but rather to fit into the open source productivity environment most likely to be engaged by their expected user base. With over 400 million Win32 bound users looking for alternative integrated productivity environments (ones that don't require a hardware – OS upgrade to implement), the expected Chandler user base is not hard to figure out. What's amazing to me is that OSAF doesn't seem to recognize how important it is to have the basics of interoperability in place with the core of this Win32 open source environment, OOo and Mozilla. (They still think in terms of a single application doing all things needed.) To me, the foundation of this integration has to include a highly interoperable XML file format. But that's just me.

At the same time i was contacting Chandler, the Standford Research Institute contacted me about the the Glow Project and how the file format would be designed. They had raised $25 million from government and higher education agencies to develop a Java based contact-PiM-project management application much along the lines of the MiT Haystack Project and Chandler. But they wanted to build on Glow in hopes of writing directly into the OOo productivity suite.

Colm Smith from the Glow Project, and Gary Frederick of the OpenGroupware Project both favored the Jabber XML schema. To me that's kind of odd, but it seems to work. Jabber comes at the contact-calendar problem from the viewpoint of wanting to integrate instant messages and web based conversations into the larger picture of an computational consumers informational net worth. They have realized that these conversations are just more scraps that might need be aggregated into different views of much larger information sets to summarize different aspects of ones life.

It's an interesting perspective, but one has to start somewhere.

One of the things that most interests me is that we are moving into a new age of computing, to what has been called by some the age of collaborative computing. An age that follows fast on the first round of the Internet, the age of global networking. One of the more interesting characteristics that's been observed about the collaborative computing age is that information work is made of many applications, on many platforms. A single user deploys many devices and many device specific applications, but the information work is singular and unique to either the individual or the collaborative project. It's no longer unique to specific purpose applications.

Still there is the need to create different aggregates or views of this sprawl of information. Somehow applications must share in the flow of information. applications need to be contributing value rather than sucking up time through the traditions of artificial barriers to information flow and exchange across the platforms and applications. Here's where a universal file format that can be extended to cover the users information needs becomes so important. Aggregate views are valuable only in that they can extend across the full horizon of information.

And how do we create effective aggregate views if some of the information is platform bound and application locked?

Personally i think one of the more defining features of the age of collaborative computing will be that all collaborative efforts are projects. Projects are comprised of people (the work group), resources (information, devices, transaction silos, data silos, and applications), and the purpose (the workflow, the process, the objective, the reason for collaborating).

The Project Management application part of IBM's Workplace is an excellent demonstration of how this works. The information is coming in from many people, using many applications and devices. It's coming in on a time line that is measured against a project schedule. The arena where the aggregate views can be gathered, parsed, studied, and distributed becomes an area of collaboration. A place of meeting and exchange.

IBM has done an incredible job of bringing the project management piece to the hub of all the applications, resources and work group. But it's one thing to enable workers to transparently view information garnered from diverse applications and services. And quite another to imagine how will we save these aggregates so that value added sums of select information can be passed on and exchanged. The original information comes from diverse applications and devices. The aggregates though demands a transformation that losses nothing, yet is universal.

These aggregates are the compound documents of the future. Not “compound” in the sense of the W3C definition where different file formats and types can be placed within a single document. And even beyond the sense of multiple applications contributing services that make up a single document. No, i'm suggesting a broader definition of “compound” that extends to cover the needs of both the productivity environment, (many applications and services) and, the many possible collaborative processes the productivity environment serves. I'm suggesting that one way to handle the management of many on going information processes is through modeling them as “projects”.

There is only one file format that i know of that has any hope whatsoever of capturing both content and context, without loss or compromise, in a structured format, across the broad spectrum of legacy applications, evolving platforms, and computational architectures not yet dreamed of. Enhancing the file format specification with project management aspects is one way through which we might be able to get ahead of the collaborating computing curve.

We have a charge to keep David. Collaborative computing demands are most likely going to push information needs from that of feature specific applications suites, to that of aggregate information intense productivity systems. It will no longer be just about the information. It will be about what we do with information. The information process. We aggregate it. We work on a time line basis. We gather, organize and dispatch resources. We organize workgroups. We integrate workflows. I can't help but think we will need a universal file format that can accommodate the needs of collaborative computing. Attributes that mark, time, people, and resource. Behaviors that reflect process, workflow, intelligent routing, and decision making.

The Jabber spec is simple. But it comes at the issue from the world of collaborative computing rather than the legacy of contact management and PiM's. The OOo Glow Project went dark about five months ago. So there isn't a pressing need to act. But i really think that sooner or later, we'll have to act on this issue. Kind of nice being able to say we've given it some thought.

~ge~

LINKS:

<xmpp.org> : Jabber web page with links to the XMPP specification, and the submission to IETF.

"XML Messaging with Jabber”: Brief discussion of the Jabber XML
http://www.saint-andre.com/jabber/xml-im.html

“XML.com: Getting in Touch with XML Contacts” : Covers vCARD DTD, Jabber XML, and RFD/vCARD proposals. Also discusses the Goldmine Contact Management application which has a robust XML file format implementation.

http://www.xml.com/pub/a/2004/03/31/qa.html