Project Management

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