Rather than put their efforts into defining groupware, managers might do better to focus on preparing a plan to help their companies grow into collaborative computing. Electronic mail provides a foundation for incrementally adding groupware functions; however, standards must be established before the necessary infrastructure can be built.

The boundaries of E-mail as a distinct messaging application are already blurred by Object Linking and Embedding (OLE), Microsoft Corp.’s Network-aware Dynamic Data Exchange (NetDDE) and the other interapplication data-transfer schemes in the new generation of graphical operating systems.

When messaging is the means for data transfer among different applications, the entire operating system in essence becomes just another messaging system. Traditionally, E-mail services provided the back-end functions of storing and forwarding messages; today, however, some of these functions are starting to move into the operating system.

There is a split between back-end functions — such as transport or physical delivery of mail, directory services, message storage and management/security services — and front-end applications –such as calendars, personal information managers, message-enabled applications and the work-flow applications that route tasks between individuals and the applications they need to complete those tasks.

“You have to distinguish between E-mail and messaging,” said Nina Burns, president of the Menlo Park, Calif., market-research firm Creative Networks. Using OLE or DDE, for example, “every application can do a simple send or receive, although there’s no message management.”

E-mail as a building block

In many ways E-mail is going to form the cornerstone of groupware, because it provides the infrastructure on which other applications will exchange data. “Mail becomes a service just like a network file server,” said Felice Curcelli, marketing manager at Lotus Development Corp.’s cc:Mail division, in Mountain View, Calif.

“Groupware applications use E-mail to cooperate with other applications in a work group or WAN because applications such as calendaring and scheduling need the store-and-forward services,” Curcelli said.

The challenge lies in providing the messaging infrastructure that groupware applications can latch onto to transport their data.

Developers must determine which APIs (application programming interfaces) are necessary to provide services to the emerging messaging-reliant applications of groupware. “One of the major reasons groupware has not taken off is that there is no consensus on how applications will interact with the E-mail store-and-forward backbone,” said Ed Owens, a member of the cc:Mail development group at Lotus and a founder of the X.400 API Association, a group of E-mail providers working on API standards for implementing the X.400 protocol.

Without a standard API, groupware application developers have had to come up with their own mechanisms for tracking the names of users and the rules for routing messages to those users, as well as their own directories and store-and-forward mechanisms for messaging.

“Directories are one of the biggest slowdowns for groupware to move to the future,” Owens said. “There are a lot of address lists lying around, as [software developers] try to solve their own problems. Hopefully, we’ll be able to settle on one directory structure where we will get everyone’s information into one place.”

Several companies have offered their own messaging APIs — such as the Vendor-Independent Messaging API developed by Lotus with input from Apple Computer Inc., Novell Inc. and Borland International Inc., and Microsoft’s Messaging Application Program Interface (see PC Week’s Oct. 12 Special Report, “Network Messaging: The Shape of Things To Come”). In addition, some companies have proposed use of common directory standards such as the X.500 protocol.

Apple, with the support of other companies, has chimed in with its own Open Collaboration Environment to provide uniform directory, security and transport mechanisms for collaborative applications.

While API issues are being worked out, some E-mail providers are making it possible for users to add groupware features in an evolutionary manner.

“Not everyone is going to need an integrated work-group system like [Lotus] Notes to take advantage of groupware as it evolves,” said E-mail market researcher Steve Caswell, of the Electronic Mail and Micro Systems newsletter, published in Washington.

“It might be easier to add some things piecemeal, such as scheduling on top of mail,” Caswell said.

An illustration of this evolutionary path is Beyond Inc.’s BeyondMail. Because the program uses rules to filter messages and provides the ability to automatically start applications and pass them data, BeyondMail is positioned as an evolutionary path to groupware.

“First you use it for regular mail, and as internal corporate developers develop more applications, they will be able to develop new forms and add rules on how to process and route them,” said Eugene Lee, marketing manager at Beyond in Cambridge, Mass.