Accellion blog has moved!

You should be automatically redirected in 6 seconds. If not, visit
and update your bookmarks.

Friday, July 21, 2006

No Pain is Gain - What email focused VAR partners are doing for email size limits

Summary: Should IT impose file size limits on email users? While limits can help IT manage the beast that is enterprise email, they also can hinder business processes. Perspectives from those who deal with this issue everyday, email-focused VARs.

"[Should] security and stability of an email infrastructure be a separate issue from whether Beth in accounting, or Pete in marketing, or Ed in Editorial can store 200 Mb worth of email or 2 Gb worth of email," asked Edward F. Moltzen of CRN on a July 14th article.

Ah, the conundrum of email size limits. Should it be set? What limit is reasonable? How would the limits impact actual business processes? What happens to the limits when the email (attachment) size gets larger, as it always does?

Stripping away all the rhetoric, the gist of the problem with message size and in-box limits comes down to the attachments. After all, nobody is going to compose a 10MB email purely in text; it’s the large attachments that hog the resources. Exacerbating the problem is the common moral hazard of not just sending attachments, but sending them with numerous CCs and BCCs, because the capability is there.

Theoretically, there is no technical reason why email cannot be designed to be robust enough to handle unlimited size. However, the problem of building an email solution that does it well is that it has to be architected specifically with this requirement in mind from the start. Adding to this Herculean goal is the IT truism that what is considered large size today is often the mere starting size tomorrow.

Now, let's face the facts here. Nothing is more core than email in most of today's business processes. The surest way for IT to rouse the ire of the bosses is when there is an email problem. Under the motto of if it ain’t broke, don’t fix it, no sane IT department of an enterprise with a keen sense of self-preservation is going to push the envelop on the email front. So, it is theoretically possible and technically feasible to allow unlimited size, but it is not going to happen, given the current code base for both Exchange/Outlook and Domino/Notes.

So, what do the email-focused value-added resellers (VARs), who are paid to confront and resolve such issues everyday, do? What our (Accellion’s) email-focused VARs are telling me is that looking at the issue as a purely email size limit problem is a myopic way of framing the problem. Namely, take a step back; email is nothing but a tool to get things done. And, the key thing that users are really asking for with large email size is the ability to easily exchange large file/attachments as the business process requires.

What we are seeing in actual field usage is that while limiting the size of messages and in-boxes is a common practice, these limits have the undesirable effects of restricting legitimate business processes that require large emails/attachments. Sure, there are the FTP sites, USB key Sneaker-Net, and the good old fashioned CD/DVD burners -- but nothing comes close to email's ubiquity and ease of use for end users. So, the question is not so much how/what size limits to impose. Rather, it is about how to let users operate in an efficient manner with increasing attachment sizes without requiring extensive and on-going contortionist trainings for both IT and end users.

We are seeing an increasing number of email-focused VARs adding Accellion Courier Secure File Transfer Appliance (SFTA) to their arsenal because it allows end users to use the familiar email application to get things done, while offloading attachments from email servers to a complementary secure file transfer appliance for IT's ease of management and ease of mind. As a result, happy users can go about their business without the frequent disruption of dealing with email limits, and IT (and the VAR) can look like a hero for solving an enterprise problem with a simple solution.

In life. No pain is gain, sometimes.


No comments: