Anatomy of groupware

RELease 1.0, August 31, 1992 by Esther Dyson

We recently attended GroupWare '92, the commercial kick-off of the field. Miraculously, it had more buyers than sellers -- something many exotic new fields never achieve. Maybe the reason is that groupware is ultimately a set of tools for practical tasks -- using a variety of hardware and software technology to inform and coordinate people -- rather than a technology looking for applications. (Applications of, say, expert systems do exist, but they're properly being sold at vertical market trade shows rather than AI conferences.) The basic goal of groupware is tools normal people can use to assist or automate business processes they understand.

In the end, groupware uses fairly simple technology, bur it requires people to think about their business activities in new ways. As with expert systems (a programming approach used in some groupware, by the way), builder/ users must explicitly represent their information and processes in order to program them. Once groupware tools are good enough, the obstacle to adoption and implementation will be the user's business understanding -- or the consultant's. The adoption of groupware provides the opportunity for people to re-engineer their businesses, bus it won't do the thinking for them.

Finally, modularity in all things: Groupware tools should be integratable with each other and with legacy applications, but not necessarily integrated. Previously "groupware" war either embedded deep and inexplicitly inside mainframe or mini applications or, more likely, in a set of business processes represented in procedure manuals, business forms, buck slips, interoffice memos and the minds of Juan and Alice, who always explain things to newcomers. Now it can be exposed in inspectable modules.

Modularity for us

Indeed, modularity works even for newsletters. This issue of Release 1.0 is the first half of a two-part exploration of groupware. In it, we explore these points with reference to the varieties and modules that comprise the broad field of groupware, and then focus on the platform offerings/promises of Lotus and Microsoft. We also describe two new examples of information-sharing groupware that elegantly extend a field led by Notes. In our September issue, we will look more deeply at workflow and scripting tools, with some examples.

Pardon us, but these are serious distinctions...

The whole concept of groupware has been subject to widespread confusion, the flip side of the success it owes to Lotus Notes: People tend to consider Notes the embodiment of groupware. Notes is only a single, albeit important, example of groupware (Just as 1-2-3 is only one example of singleware). Now that there's a multiplicity of purchasable, installable systems out there that do more than calendaring and e-mail, users are beginning to understand the distinctions among them. In previous issues we've posited a framework for groupware (see Release 1.0, 11-90): information-sharing tools such as Lotus Notes, va. transaction-oriented workflow tools such as FileNet, WorkNAN and Action Technologies' The Coordinator.

Basically, you can effectively build a modifiable, integrated system only after you have properly modularized it into its different components. That's why we're such a stickler for the separation of groupware into two kinds: As with client/server systems, until you've separated the parts, you can't put an arbitrary selection of them back together again. What is confusing is that most people consider it more natural to separate hard and soft content (data va. text/image), or client and server. But the appropriate separation is active workflow va. passive information-sharing 'whether that information is "hard" or "soft." (You may even use the same data storage for both workflow and information-sharing, which only makes it all more confusing.)

Thus, in this issue we divide the groupware world into three broad areas: workflow, information-sharing, and traditional applications that accomplish "work" -- database transactions, say, or a user's work with spreadsheets, (compound) documents, sales reports, etc. The first two are both considered "groupware," but are actually quite different.

The third is what you might call "legacy" applications: From groupware's point of view, a spreadsheet is as foreign as a mainframe reservation system. Legacy applications are what workflow groupware manages, and their contents (task data) can be made available to users by information-sharing workflow as well as traditional applications or query tools. (Finally. there are a few genuine groupware applications that involve information transactions between users -- primarily scheduling, negotiation and delegation. This is the province of Action Technologies, in our next issue.)

Platforms for groupware

Groupware has different data storage and management requirements from more traditional applications. In mainframe days, the assumption was one file, one user; and that user was generally some monolithic batch application that chunked and clanked away all night (unless it abended). When on-line transactions and multi-user access appeared, developers created databases to manage access and concurrency control to data elements on a more atomic basis. But at least the data was regular and transactions were fairly quick; the problems were mathematically elegant and the solutions precise.