The Evolution of Groupware

At the heart of the information age, or information revolution, is knowledge. A business lives and dies by its capability to use, manage, and share information. It is important to note that data is not information. Application developers are charged with turning raw data into knowledge ”useful information. The term groupware ( group information-management software) is a loosely defined concept that refers to a type of application that enables groups of people to collaborate together to create, share, and use information more effectively.

Groupware relies heavily on networks for the transfer of information among individuals and organizations. Groupware promotes working together in teams. This fits in well with today's business climate, where teams are promoted and heavily emphasized in almost every sector of business. Groupware evolved from two basic models: the share model and the send model.

The Share Model

Applications that work in a networking environment enable people to share data. Examples of this include applications written in a wide variety of languages and database engines, such as C, dBASE, FoxPro, Sybase, Oracle, and PowerBuilder. Some word-processing and spreadsheet software, such as Lotus WordPro, Lotus 1-2-3, and Microsoft Word, enable groups of people to collaborate on a single document or spreadsheet. The author of the document can lock out subsequent editors from certain types of changes and certain areas of the documents, and can support version control.

The share model relies on the document or database application being in an area accessible to all users ”that is, shared ”typically on a file server. If all users have access to the directory on the file server where the file exists, they can all work on the file. Most database applications do not support concurrent access of specific records, but they do support concurrent access to files. This is referred to as the share model.

In this model, a user must go to the file on the server and open the application to add, modify, and view the data. This is perhaps the most widely used architecture today. Examples of this kind of application abound in most organizations and can include accounting applications, inventory applications, and other types of business applications. An application of this type is passive; it does nothing in and of itself. Users must go to it to get any information. This can be a significant drawback because you must rely on the user to perform an action ”say, approval of a requisition ”in a timely fashion and of their own volition. In fact, unless a user visits the database, that user won't even be aware of the requisition in the first place. Although a central repository of all documents exists, the application is not capable of taking any actions based on a change in status.

Possibly as a response to the success of Notes and Domino, groupware features have been added to word processors such as Microsoft Word and even to spreadsheet applications. Collaborative features such as master documents and version control were added to an existing product that was previously standalone. On the other hand, Notes and Domino were designed to enable groups of people to work together.

The Send Model

In the send model, information is pushed , or sent, to the user. This typically involves email. Examples of this type of application are forms routing, requisitions, and document approval. Using email to route forms closely mimics the routing of a paper document in an office. In a typical scenario, you might fill out a requisition form for a new PC and send it to your boss. He then approves it, but because you want a $5,000 laptop and it's over his approval ceiling, the form gets routed to the branch manager, exactly as in a paper-routing flow.

The problem with this model (and its paper-based cousin) is that there is no convenient way to determine the status of your requisition or even who has it. There is no central place for you to look, and there is no shared database containing the requisition. This lack of a central repository for requisitions also means that there is no way to keep and track the history of requisitions. After the requisition is purged from the last mailbox, it's gone for good. In other words, there is no document management.

Workflow: The Integrated Model

Lotus Notes and Domino solve the problems inherent in both the send and share models by merging a shared database with an email engine. In addition, the server has the capability to schedule agents to run at certain times and take actions based on certain conditions independent of any user involvement. A requisitions process is a typical workflow solution. Enabling workflow involves creating mail-enabled databases.

In a workflow solution, after a requisition is composed and saved in the database, the application determines the approver and then notifies the approver of the requisition. The notification usually includes a document link that can be clicked to open the document. The approver assesses the requisition and can approve it on the spot. An agent runs nightly on the server, sending tardy notifications to ensure timely responses.

Although this example has only touched the surface of workflow applications, it is quite apparent that this type of solution can save a lot of administrative headaches and significantly reduce the amount of time to complete a process. If this had been simply a shared database, none of the email notifications or the agents would have been present. A send model would not allow the originator or the administrator to determine the status of a requisition. There would be no automatic monitoring of the process. The process works better, and the company now has a history of requisitions that can be easily researched.