Anatomy of groupware

RELease 1.0, August 31, 1992 by Esther Dyson

In the world of groupware, you have more varied needs for access to less regularly structured and defined data. You can no longer divide files up into neat data records as a database does, nor can you simply assign one large file to one user at a time. You need access controls, allowing some people to change certain items in certain ways under certain conditions, and preventing others from even looking at the data.

In particular, information-sharing groupware supports a variety of users who want to look at and add to data. and share it either broadly or with particular other people. There may be a defined flow for the information, but the basic activities are looking and adding, not sequential changes. This requires a storage system that makes the information widely available and allows easy additions. In practice, Notes replicates its databases on multiple servers.

Workflow groupware is more concerned with managing work processes that involve changing and updating information at an atomic level. Storing plain old files will no longer do: You want object management -- a better way to define, find and manage access to the objects, on a more fine-grained level, and you want to be able to deal with complex, compound objects (like a database, but for objects).

Like information-sharing groupware, workflow needs the primitives to build complex security and access and version control rules, and the ability to find objects wherever they are. Replication accomplishes easy access by putting identical objects in several places, but that's dangerous with workflow, since the assumption is that people who have access to objects in a workflow will change them (as opposed to adding items or comments, as in information-sharing). Thus you're better off keeping a single copy of each object, rather than trying to manage and reconcile proliferating copies. (Certain resources such as directories and software itself may be replicated, usually only one-way, but the default is one data object, one copy.)

Meanwhile, not only do you need to store the data needed by the workflowmanaged tasks; you need to store the data needed to manage the tasks. Who has what? Who should get it next? If Juan doesn't like it, who can override him? Where is the artwork for the fourth chapter and did Alice do the captions yet? In simple workflow, the "state" of the objects is typically stored with the objects; in the object-management model there's only one copy of each object, and so you can get clear, real-time information about each obJect's state. But there's no central repository of control or knowledge about the process as a whole, and no way to monitor process integrity. That's why most industrial-strength groupware, with multiple complex interactions and sequences dependent on each other, keeps its own process information in a database regardless of where the work content is kept.

To workflow groupware, the user is a server. It asks the user to do some work, then takes the results and sends a request for further work to another server/user.