Public Folder Strategy

Exchange is relatively new, and most deployments focus on email. So far, few installations are considering the implementation of other groupware applications, such as making travel authorization requests via email based on Exchange. The market has not really seen a mass of groupware products appearing to complement Exchange, either (remember, the product is only a year old).

That situation is changing as third-party vendors come to grips with Microsoft's Messaging API (MAPI) and realize how best to integrate their products with Exchange. For example, both Fulcrum FIND! and Verity SEARCH'97 are excellent full-text search and retrieval engines, and both are available in a nice integration for Exchange. Full-text retrieval engines help you retrieve information very fast, in most situations, in a couple of seconds. Fast access to data is important, and from experience I can tell you that this point becomes more important as users begin to use public folders in their work. Public folders let users put items (a message is an item, as is a Word document, an Excel spreadsheet, and an electronic form­e-form) into containers to share with other users throughout an Exchange organization. Microsoft is also adding functionality to Exchange. For example, Microsoft enhanced Exchange's document publishing capabilities in 5.0, with the introduction of anonymous Web-based access to public folders. You can now make public folder content available to anyone who has a Web browser.

Even before Exchange had officially been released, public folders were sometimes proposed as the universal groupware panacea. Suitably furnished with an appropriate e-form, a public folder could host a discussion forum.

With a different e-form, a public folder could be a repository for workflow documents. The range of applications that public folders could handle was (apparently) enormous, and the only limitation was the skill of the programmer who created the e-forms. Microsoft used public folder capabilities as an offensive weapon in its ongoing battle against Lotus Notes. The situation is somewhat different now, and public folders are perhaps less of a focus as Exchange moves to fight new battles, most recently embracing Internet protocols and standards in Exchange 5.0. Instead of expanding the existing e-forms capability, Exchange 5.0 permits access to public folders via Web browsers, the first indication of how HTML e-forms might be deployed in the future. I expect Microsoft to re-emphasize the e-forms capability of public folders in the future, as outlined below.

The strategy of using e-forms and public folders for custom groupware applications has faded as Exchange matures, for two reasons: First, because of platform dependency, the current implementation of e-forms inside Exchange is flawed, perhaps fatally so; and second, Internet-based technologies are set to take over at least some of the role that had been envisioned for public folders.

Exchange e-forms are built with a dialect of Visual Basic (VB), so they are easy to construct and bring into production. However, the e-forms are 16-bit applications, and you can execute them only on platforms that support VB (for example, UNIX and Macintosh users cannot use these forms), a gap that has become apparent as Exchange begins to support more and more client platforms. Groupware applications aren't much good if they eliminate large potential user populations because of software incompatibilities. Although the Outlook WebView client and Active Messaging have introduced Web-based forms, we're still not at the stage where all clients can use the same forms.

Microsoft has incorporated support for all the important Internet protocols in Exchange 5.0 and promises to keep up to date with new developments as messaging protocols mature in the Internet community. We can, for instance, expect the next release of Exchange to support the IMAP4 messaging protocol. The Internet has not embraced groupware applications to date. But, applications that let you build discussion forums using Web technology (Digital's AltaVista Forum is a good example) and early versions of workflow applications are appearing. JetForm's recent announcement of support for Microsoft's Active Messaging component is a good pointer for the future. Active Messaging is, of course, the part of Exchange that supports Web client access to the functionality Exchange servers offer. JetForm is building software to let Web clients participate in workflow applications, so you can now have workflow documents circulating around a much wider user community than before.

JetForm's software is still proprietary technology, albeit something that you can use now to develop workflow applications. If you can wait, developments in the wider Internet world might provide a set of protocols that workflow applications can use. The continuing development of Security MIME (S/MIME) is important because it will let you encrypt information enclosed in documents exchanged between business partners. Extensions to Simple Mail Transfer Protocol (SMTP) to incorporate some workflow commands are also important because they will let SMTP-capable systems, such as Exchange, participate in platform-independent workflow applications. We don't know when all these protocols will settle down and be incorporated in mail servers. Several years might pass before true platform-independent workflow is viable. Microsoft might decide not to wait and go ahead and introduce an Exchange-specific workflow engine in a future version of the server. Certainly some rumblings coming out of Microsoft indicate that some workflow developments might happen sooner rather than later. No one can wait for the future to arrive, so if workflow is important to you now, consider using technology that exists today rather than waiting for the future to arrive.