Article: Multi-Vendor Infrastructures: Do Standards Help?

Many large companies have e-mail systems that are a patchwork of different proprietary e-mail products. At the same time, most organizations are looking to groupware and Intranet for competitive advantages, increased functionality at the desktop, and for a more tightly integrated IT infrastructures with common servers, collapsed clients, and common APIs across applications. Widespread support of Internet standards-based messaging technologies on the part of vendors complicates this situation. The promise of interoperability across vendors seems compelling and messaging customers are tempted to mix and match proprietary e-mail and groupware clients and servers by taking advantage of standards-based messaging technologies. However, for several reasons, the introduction of standards-based messaging technologies where there are multiple proprietary messaging systems already in place tends to make a bad situation worse.

Messaging and groupware cannot be completely separated. If you have groupware, you have messaging. It is important to clear on the point that groupware is not a technology or a product, but rather a category of functionality analogous to the category "food." Historically, companies that have started with messaging-only products have reached towards groupware functionality, calendaring and scheduling or business forms for example, in the form of messaging-reliant e-mail add-on products. The latter approach has proven limited in the level of integration with the e-mail system both on the client and server side, as well as in scalability. In general, managing multiple e-mail add-on products will require more administrative resources than integrated groupware solutions.

E-Mail and Groupware

The relationship of e-mail and groupware is complicated by the trend towards Intranet technology. Stimulated by the competitive threat of fast-growing Netscape Communications major e-mail and groupware vendors have been falling over themselves in their rush to add support for Internet standards to their proprietary e-mail and groupware products. This invites customers to mix and match clients and servers. However, there are several considerations.

E-mail does not justify a groupware infrastructure. Financially, technically, and administratively, rolling out groupware servers just for e-mail is not best. Implementing proprietary infrastructures for the purpose of standards-based messaging is impractical at best. With Lotus' Notes/Domino, for example, the benefit of the server infrastructure, in terms of ROI, can only be realized by implementing groupware. Theoretically, there is a payoff ratio of e-mail-only user accessing e-mail via standards-based messaging protocols to groupware users running Notes against an all-Domino infrastructure. In general, though, running non-Notes e-mail clients against a Domino back-end is a poor use Domino and breaks integrated groupware functionality.

Standards-based messaging proponents may wish to standardize on Internet e-mail protocols such as IMAP4 and LDAP. Domino, Exchange, and GroupWise, however, were not originally designed for standards-based messaging and it is not clear at this point how committed Lotus, Microsoft, and Novell are to standards-based messaging solutions. The risk is that 'hybrid' solutions will be slower, less scaleable, and one step behind the technology as compared with natively standards-based products while vendors may be less responsive to customer concerns where standards-based technologies, which exist in parallel with native proprietary functionality, are involved. For example, performance and numbers of simultaneously active users (scalability) can be expected to be worse for products like Domino and Exchange under IMAP4 than for natively standards-based messaging servers. Exchange 5.0, which is a messaging, rather than database technology like Notes/Domino is superior to Domino as a messaging server. In general, hybrid servers like Domino and Exchange cannot be expected compare to natively standards-based solutions in terms of performance and scalability.

Standards and Standards-Based Messaging

While it is important to standardize and to have enterprise-wide standards, this is not the same thing as implementing Internet standards-based messaging technologies. In general, the best solution is a single messaging infrastructure. In practical terms, this means:

From an architectural perspective, Internet standards-based messaging technologies are best utilized for new systems, wholesale migrations, and as a long-term strategy. However, introducing standards-based products alongside the patchwork of proprietary e-mail systems common in large corporations only increases complexity and administrative overhead.

Messaging customers should recognize the value of what works in practice today rather than what should work in theory or with what will eventually work, regardless of the claims of vendors. For companies with multiple proprietary e-mail systems, the best use of Internet standards-based messaging technologies is to facilitate migration to a natively standards-based solution. Where messaging is a high priority relative to groupware, the proper role of hybrid products like cc:Mail R8 and Domino is to facilitate full migration.

Microsoft Outlook as a Standards-Based Client

Standards-based e-mail clients are proliferating out of control. Lotus messaging customers, for example, should not allow Office 97 to be deployed with Outlook. If the Outlook client on the desktop, users will try and want to use it. Adding more different clients to the e-mail mix is not best. Having fat Notes and Exchange clients side by side on the desktop is not best. Microsoft's messaging strategy involves giving customers virtually free, tightly integrated software that is automatically installed and that directly competes with non-Microsoft products already on the desktop. This tends to produce migration to Microsoft's solution, not because the solution is good but because it is there; its installation can't easily be stopped nor can it be conveniently removed once installed. The pressure is on customers to allow users to use the Outlook client and it comes from users who just want to use what appears on the Microsoft's desktop.

Client-Side Issues, "New Functionality," and Vendor Claims

The temptation is to open up the e-mail infrastructure standards-based e-mail access. However, using diverse e-mail clients breaks add-on products that work with one e-mail client or another resulting in an overall reduction of functionality at the desktop. There are no widely implemented open standards for groupware functionality today, although there are proposed standards such as vCalendar. E-mail products do not all support or equally support the same APIs and standards, therefore, mixing clients from multiple vendors is inherently problematic where e-mail add-on products are concerned. Mixing clients from multiple vendors can be expected to result in an overall reduction of functionality available at the desktop.

From the client perspective, Internet standards-based messaging technologies do not add new functionality. The functionality of standards-based products is merely different from a technological standpoint and not new or better. Technical analyses of specific capabilities, feature-by-feature, such as off-line and dial-up functionality, data security, file attachment handling, protocol support, and directory services, show that proprietary systems like Lotus Notes and Microsoft Exchange offer more features and functionality than any standards-based e-mail client available today.

Since proprietary products provide more features and functionality than currently available standards-based products, support for an Internet standard is clearly not equal to a feature or new functionality. Such claims on the part of standards-based product vendors amounts to the empty charge that the way a feature is implemented constitutes "new functionality" simply because the feature implements a standard not supported by proprietary vendors whose products, in fact, provide equivalent and more functionality as compared with the functionality provided by the Internet standard in question through proprietary mechanisms. It would be naive to believe the 'religious' claims of vendors who assert that standards-based products are inherently superior just because they are standards-based. The claim that support for each Internet standard represents a 'feature' or that non-standards-based products 'lack functionality' because they do not support the standards in question is ludicrous. Equally absurd is any claim that adding standards-based e-mail clients to a system where multiple proprietary e-mail products are already deployed somehow 'adds functionality'. Such claims are not supported by the readily available data regarding e-mail client features and functionality.

The main advantage that standards-based e-mail clients offer to corporate customers is interoperability, especially for file attachments, across servers and e-mail systems. However, interoperability through standards-based technology is simply irrelevant where a single e-mail architecture has been implemented. All of the major e-mail systems, for example, handle attachments as well as any MIME-capable client within their own system and every major e-mail system supports the MIME standards when communicating with external e-mail systems through an MTA or gateway. For small and medium sized organizations that can easily standardize on a single-vendor solution, standards-based clients have little, if anything, to offer outside of the fact that they tend to be thinner than products like Notes and Exchange.

After stripping away the hype and separating theory from practice customers are still better off today with single-vendor e-mail infrastructures. The promise of interoperability has little practical value if the e-mail infrastructure remains a patchwork of proprietary servers with bolt-on Internet standards support. All of this implies that vendors who are rushing to the standards-based panacea are running scared. Most messaging customers are still better off with single-vendor solutions. The historical inability of large organizations to standardize their e-mail platform is not resolved by the introduction of Internet standards-based technologies. For companies that cannot standardize on a proprietary messaging technology, the benefit of standards-based technologies lies in the fact that legacy e-mail systems can be extended to the Intranet as a preparatory measure enabling wholesale migration to a natively standards-based messaging solution.