Contents

  1. Development Topic: Integrated Mail for xTuple ERP
    1. The Problem
    2. The Solution
    3. Requirements
    4. Options
      1. Client Proposals
      2. Server Proposals
    5. Other options:

Development Topic: Integrated Mail for xTuple ERP

The Problem

No matter how slick and functional CRM systems may be, in practice it is difficult to implement them so that they are actually used in a real world enterprise for one main reason: People hate maintaining duplicate information. Due to this basic problem, stand alone CRM systems often fail to deliver because of fundamental weakneses in two main areas: lack of integration with the system of record (ERP or Accounting system) and poor or no integration with e-mail. With CRM embedded in xTuple ERP, we clearly have the first base covered. But e-mail integration is another matter.

For most people in the business world today e-mail is the primary means by which they communicate with the outside world, and their e-mail client is the most heavily used piece of software on their computer. E-mail clients today are the result of years of evolution. They are highly polished, versatile and well-suited to the personal needs of the individual. E-mail clients typically include or are tightly linked with local contact lists, calendar systems and task lists which, because they are seamlessly and conveniently integrated with the mail client, are typically preferred over nearly identical utilities that may be found in a CRM system.

People keep their e-mail stored in dozens of sub folders that can be easily searched when necessary. Few people have the discipline to copy and paste all their correspondence and contacts into a CRM system. It is simply too much work with no pay back for the individual. Yet, the enterprise pays the price as it is stuck with a database of contacts that is often incomplete, out of date, and lacking meaningful communication history between its employees and key accounts.

The Solution

xTuple should implement a solution that allows for integration between e-mail and xTuple CRM to such an extent that critical information in the xTuple database including contacts, calendars, task lists and e-mail correspondence are readily available in the mail client and vice versa. The solution must keep in mind that it is unreasonable to expect users to make great (if any) personal sacrifices in usability "for the good of the whole." This means the solution must be polished and include niceties people have become used to having--such as spell checkers, auto-completed names, names automatically stored in an address book, signatures, and off-line access to history to name a few. Synchronization with the ERP system should require little to no effort.

From the CRM/ERP system users should be able to launch e-mail from various records such as Incidents, Account, Customer, Sales Order and such and expect those e-mail records sent will be linked as a permanent correspondence record with the document they were launched from so that any employee looking at history can see the correspondence.

Requirements

Proposals listed below will include the assumption that an ideal solution will:

Options

From the broadest possible perspective there are two approaches to this solution. One is to develop, modify or extend an e-mail client that is able to attach to and integrate with an xTuple database.

The second is to develop, modify or extend a proxy IMAP server that e-mail clients can connect to or through that manages communication synchronization between the e-mail server and xTuple. This IMAP server would primarily serve to fetch mail and store it on an intermediate server in a database that can be synrchnoized with xTupleCRM. It is in fact a requirement that any server side solution be able to attach to an externally hosted e-mail server rather than force users to manage (and xTuple to support) their mail service in house and deal with all the headaches that accompany that including domain management and spam filering.

Client Proposals

In general client-side solutions offer the benefit of being relatively simple solutions for users that are implemented locally on a PC. By working with the client, we have ability to control the interface and add options. For example, a user may want to have a "Private" checkbox option they can select when they don't want e-mail or contact information to be visible by the enterprise.

The downside is that users who don't use the correct client or plug-in may miss out on the benefits of synchronization. The enforcement and maintenance for IT Administrators to manage so much client software in an enterprise may be unattractive.

Technology: C++/Qt

License: N/A

Overview: xTuple builds its own e-mail client in Qt.

Pros:

Cons:

Technology: C++/Gecko

License: MPL/GPL

Overview: Thunderbird and Lightning are popular e-mail and calendar clients developed by the Mozilla project,which works on all three or our required platforms. Other CRM systems including Sales Force and Sugarcrm have Thunderbird plug-ins available.

Pros:

Cons:

Technology: C++/Qt

License: GPL

Overview: KMail is the Linux KDE desktop mail client, while Konact is the address book component and KOrganizer is the accompanying calendar and task manager. Though relatively unknown, the products are very polished. Currently work is in process to port KDE applications including KMail and KOrganizer to run in Mac and Windows. Like xTuple, KMail is written using Qt. We would write a plug-in to connect KMail and KOrganizer to xTuple. Strong likelihood we would need to package and distribute the KDE software in addition to plug-ins to avoid confusion for users who might get lost trying to figure out how to get just these components out of the otherwise very large KDE universe.

Pros:

Cons:

Technology: C++/MSFC, Cocoa, C

License: Proprietary, Proprietary, GPL, GPL

Overview: Write plug-ins for the most popular mail clients on each operating system.

Pros:

Cons:

Server Proposals

The two server-side solutions presented here offer the benefit of guaranteeing that all corporate e-mail traffic runs through a server regardless of the client. Any IMAP complient e-mail client should work with these servers. Upgrades and maintenance are therefore easier for administrators. This also frees administrators of the burden of having to tear users away from their preferred e-mail client, what ever it may be. Finally it would be easier to justify charging enterprise-level fees for server side solutions, where client software pretty much has to be given away. Both solutions listed offer an LGPL license, meaning we are free to repackage and sell our own product either as open source or proprietary. The proposals also both have high potential for extremely tight integration between mail and xTuple using trigger-based integration methods.

The downside is that organizations which are unsophisticated and don't have an I.T. administrator may find the installation and maintenance of server solution complex and burdensome. Also, without having control over the client, the synchronization aspects will have to behave in a default behavior that client users will have no control over. So, for example, if e-mail history is configured to be tracked in the ERP system, it will ALL be tracked, with no mechanism available to handle exceptions.

Technology: C++/Qt

License: N/A

Overview: xTuple writes a groupware server that can attach to both e-mail servers and the xTuple database and provide e-mail and xTuple data together. Email clients in turn attach to this service.

Pros:

Cons:

Technology: Objective C

License: LGPL

Overview: Open Groupware is a project sponsored by a company, Skyrix, based in Germany. Open Groupware attaches to email servers and organizes e-mail and related records in a Postgres database. xTuple would integrate with the Open Groupware server by building a package of triggers that keep data in both Postgres schemas synchronized. Repackage and sell as xTuple Groupware.

Pros:

Cons:

Technology: Java

License: LGPL

Overview: Meldware Communication Suite is spin off sub project of JBOSS that is now its own entity on buni.org. xTuple would integrate with the database server by building a package of triggers that keep data in both Postgres schemas synchronized. Repackage and sell as xTuple Groupware.

Pros:

Cons:

Other options:

There are a literally dozens of other e-mail client products and projects out there, but all others I found were incompatible with xTuple either because of GPL or proprietary license constraints. Likewise, there are numerous "Groupware" products and projects available. But in addition to licensing constraints, they tend to have a different focus. Many are full-fledged e-mail servers, which we really don't want to get into, and most are geared to be more of a web portal or CMS solution, rather than the intermediary storage solution for mail contents.

EmailIntegration (last edited 2009-01-06 22:19:29 by ptyler)