Email Archiving, Email Hosting - SaaS

Beyond the buzzword: SaaS and integration

I've written a great deal (as have others) about the benefits of SaaS in the email archiving and Microsoft Exchange hosting worlds in terms of usability (here and here), deployment times, storage management and innovation.

But all of those points above are very IT-centric, since on-premise software is inherently IT-centric.

What I've found is that senior business leadership at companies (e.g., how I think about my company) don't think in terms of technology or systems - they think about business problems they are trying to solve. One of the fundamental challenges for IT since the dawn of time (or at least the mainframe) has been to connect systems together so that technology aligns with business processes and business value.

The problem is that when your technologies are running on-premise, this is really difficult. Each technology has different architectures, interfaces, infrastructure and teams to manage it and customers end up deploying NEW systems (remember Enterprise Application Integration?) to connect those silos together. What a mess!

One of the benefits of software-as-a-service that's only getting attention recently is that customers running their applications "in the cloud" can also connect those applications together more easily to mirror their business processes.

Phil Wainewright at ZDNet has a great post on his SaaS blog about this trend in general ("SaaS mashups" as he describes them). In particular, he highlights an innovative vendor Xactly that recently announced a 5-way SaaS integration:

As a case in point, take Xactly's 5-way mashup, announced Monday (image courtesy of Xactly). Using Salesforce.com's Force.com platform as the foundation, the SaaS vendor has mashed up its own sales compensation application with Amazon.com's retail catalog, the Paypal payment system and an iGoogle gadget. The mashup creates an enterprise-class incentive rewards management and fulfilment application that at the same time is economical enough to be affordable for smaller businesses - subscriptions will be $10 per user per month, at the end of a 90-day free-of-charge launch window that ends December 1st.

So how could an email SaaS platform tie into the other SaaS business applications organizations are using like online CRM, HR and accounting packages?  More to come on that...

Email management workarounds: HitMeLater

Michael Arrington at TechCrunch profiled HitMeLater today.

Per Michael, it attempts to solve the email deluge problem many users face:

HitMeLater is simple. Forward any email to 24@hitmelater.com and it will send it back to you 24 hours later, putting it on the top of your inbox pile. You can change the number of hours to anything you like, up to 1,000 hours ahead (3@hitmelater.com sends it back three hours later). Alternatively, put in a day (Wednesday@hitmelater sends it back the next Wednesday). If you send it something it doesn't understand, HitMeLater sends back a polite email message saying "We're not sure what you want." 

While I understand that people (including me) are flooded with email, I don't quite get why they aren't able to use Outlook (if Outlook is their email platform) to manage it.  Outlook has had "follow-up" flags for years and has search folders which automatically let you see all messages across all folders with flags.  It seems like HitMeLater is trying to do the same thing?  Seems like overkill for a simple use case.

I have a unique email management style where I simply leave everything in my email inbox (I don't have to worry about quotas, since my email is automatically archived :) ). I use the read/unread flag as a mark for messages that I need to attend to.  If I view something and still have to process it, I re-mark it unread.  Then I use the Outlook search folder "unread" to see all unread messages.

I moved away from foldering a few years ago to save time (since I didn't have to worry about quotas) and decided that read/unread was the fastest method to process email in Outlook (you can toggle read/unread with hotkeys easily) and you can toggle read/unread from mobile devices as well.

I guess everyone has their own system, huh? :) 

Email archiving: A baby step into the cloud

Since I'm on the theme of Bill Murray movies, my mother-in-law's all-time favorite and one of my personal top picks as well is the 1991 classic What About Bob?

In the movie, where a supposedly-insane Bill Murray (Bob) drives his therapist (Richard Dreyfus) even crazier, Bob learns about a method of therapy involving taking "baby steps" toward challenges.

As you know, there is a ton of hype and some substance around the idea of cloud computing (or XaaS as CIO Insight put it, in a recent article) where companies leverage external infrastructure for applications, rather than building everything themselves.

In this vein, many companies are now looking at their email infrastructure and trying to decide whether to use a hosted service (e.g., Hosted Microsoft Exchange) or continue to run an email service on internal servers.

However, a few companies that I have spoken with struggle with whether they're ready to pull the trigger on outsourcing email altogether.  Some are aggressively moving forward - particularly if they have to upgrade their email infrastructure anyways (e.g., to Microsoft Exchange 2007).

Others are finding an interesting baby step: start by archiving your email to a hosted service provider to:

• Reduce your storage costs and backup windows for email.
• Give your users an Unlimited Mailbox without the need for quotas or PST files.
• Create a searchable repository for e-Discovery and other legal searches.

Archiving is a great way to start in the cloud since it's typically a new project, not core to most businesses, expensive to build internally and surprisingly-complex to run in-house.

Once a company has its email archived with a service provider, a few things happen:

• The company now has experience with the "cloud" and can determine whether to go deeper.
• The company also has its historical email hosted.  If its service provider also provides hosted messaging, a future migration to a fully-hosted email platform is much easier (since the biggest time in an email migration is in copying the data from the old email system to the new one).
  

Why SMBs need to think about e-Discovery too

George Crump posted a great writeup on InformationWeek's storage blog about how email archiving and e-Discovery are problems that affect all companies - big and small:

George lists three great reasons why small companies should be looking at this issue:

1. Has your business ever been sued? 95% of all discovery requests involve e-mail. 65% now ask for other forms of data (office productivity, CAD diagrams, etc). You must be able to not only deliver this information quickly after the request, but also at the request you need to know what you have and state what you are planning to deliver.

2. Have any employees? Ever have any leave because they weren't happy or you weren't happy with them? (if you answered no to question one and yes to this question, go back and change your first answer to yes.

3. Ever need to reference a previous piece of work as a starting point to save time or to upgrade or add on? Data retention is not just about being prepared for bad things, it is also about using your digital assets as... well... an asset, to help you save time on the next project, addition or redesign.

He also profiles LiveOffice Mail Archive as a possible solution for this need:

What makes LiveOffice interesting is how mature it is in the space, with more than 7,500 customers in eight years of business.

Google Apps downtime

As I've written before, I find it amusing how my brethren in Silicon Valley think Microsoft is dead and that Google will inevitably win in the business software world.  While I don't think you can ever underestimate Google, given the talent of the team that they've assembled (it truly is remarkable), I also don't think Microsoft will just go quietly into the night.

In particular, I think Google will end up having to learn how different the challenge is to sell paid software to businesses versus giving free (ad-supported) software to consumers.  While I have no doubt that they will figure it out, it will certainly take time.

Some of the recent outages Google Apps (Google's enterprise email/productivity offering) has had illustrate these growing pains.  As IDG pointed out in its article on the subject, the customer outrage was about the response and communication from Google as much as it was about the downtime itself:

In the main Google Apps Discussion Group thread devoted to this incident, administrators complained loudly about the length of the outage and the lack of status update details offered by Google officials ...

"Seriously... It has been two hours. Can you provide us with another update? For a company with your reputation, I'm absolutely shocked at the apparent absence of customer service," wrote a Google Apps administrator on the discussion forum on Wednesday. "This amount of down time is unacceptable."

Phil Wainewright wrote a great post on ZDNet questioning whether Google's corporate culture is conducive to building enterprise technology.  He quotes the resignation announcement of engineer Sergey Solyanik from Google, who talked about some of the challenges Google faces in the enterprise.

"[T]he culture at Google values "coolness" tremendously, and the quality of service not as much. At least in the places where I worked. Since I've been an infrastructure person for most of my life, I value reliability far, far more than "coolness", so I could never really learn to love the technical work I was doing at Google." 

Knowing many folks at Google myself, I think this characterization is unfair.  They value user experience as much as any company I've ever met.  However, I do think there are some unique aspects to the business technology world that Google is learning as it grows. 

Welcome Frank Sansone!

Today, we announced that Frank Sansone is joining our family at LiveOffice as Chief Financial Officer.

Frank was previously CFO at Guidance Software, a public software company and leader in e-Discovery.

We liked Frank for many reasons, but three really stood out:

1. e-Discovery is one of the main drivers for email archiving and Frank's experience at Guidance is very relevant for our business and for our clients.
2. Frank was at Guidance from its roots as a small private company to the public and rapidly growing firm it is today.  As such, Frank will help us scale our operations to meet our clients' needs.
3. Most importantly, Frank is a huge NFL fan, like most of us here.  Sadly, he roots for the Miami Dolphins, but hopefully I'll get him converted to my Steelers over time.

Welcome, Frank!

To stub or not to stub

Bob Spurzem on the Ferris Research blog wrote a good post today on a method of archiving called stubbing.  Bob was referring to a recent Microsoft TechNet article on the topic claiming that Microsoft was recommending against stubbing.

Stubbing involves replacing items in the email server (e.g., Microsoft Exchange) with a stub or pointer that refers to the original message and attachments in the archive.

While a number of vendors try to make the issue black-and-white (i.e., stubbing is great or stubbing is bad), I personally think it's simply a tradeoff:

• Pro: Stubbing allows the management of the message to remain in the normal folder structure, since the "stub" remains in Outlook and Exchange.
• Con: However, Bob and others are correct that the stubs themselves over time can clog up Exchange and cause performance issues.  One of the main reasons for this is that item counts (i.e., how many messages you have) often drive performance bottlenecks in Outlook and Exchange as much as does mailbox size.
  

I think stubbing is great for giant enterprises that can manage some of the complexity in order to benefit from the folder integration.  However, for smaller organizations or ones with limited IT resources, the simplicity of pointing users to an archive folder or archive search tool often wins out.

Again, it's not a good-versus-bad situation but it's good to know the tradeoffs between the alternatives. 

Exchange backups: Groundhog Day?

Do you remember Groundhog Day?  It was the 1993 Bill Murray film about a guy who relives a day of his life over and over again.  It featured the classic line:

This is one time where television really fails to capture the true excitement of a large squirrel predicting the weather. 

In any case, I think the way we stick to the weekly tradition of full Exchange tape backups is like a bad recurring dream.  Lots of the same stuff over and over again.

Today, I spoke with the blogger and former storage CTO George Crump who had a great post on his blog, Storage Switzerland, about how full backups are becoming a thing of the past in general.

I think this is particularly true for email, where users and lawyers want and demand the granularity of a message - not the granularity of a tape.

Many clients backup Exchange every day with incremental backups and innovative disk-to-disk technologies and yet still perform full backups to retain data for legal discovery or data retention purposes.

If all of your data is in a hosted archive, full Exchange backups and retaining tapes for long periods of time become something admins can cross off of their ever-growing to-do list.  This saves tape media, tape storage and precious IT time.

So they can move on to the next day. 

The inconvenient truth: Item counts matter

The conventional wisdom in the Microsoft Exchange administrator base is that mailboxes are getting too big in terms of size, hence the advent of quotas and email archiving solutions to reduce mailbox sizes.

However, many Microsoft Exchange gurus have now realized that the number of items in a mailbox and a folder matters as much in some cases as the size of the mailbox itself.

Bob Spurzem at Ferris Research points this out on his blog.  He refers to a great technical article on Microsoft TechNet on the same topic which includes the following:

Folder contents are stored in a table in the information store database. As the number of items increases, there is a corresponding growth in storage complexity. The storage mechanism for the Exchange store is the Extensible Storage Engine (ESE). ESE uses B+ tree data structures to store records. As the number of records increases, the potential number of disk I/O requests that are required to locate the information and traverse the B+ tree also increases. For more information, see Extensible Storage Engine Architecture.

As the number of items increases, the possibility of any requested data being located on physically adjacent locations on the hard disk is greatly diminished. Therefore, more I/O requests are required.

Martin Tuip, on his Archiving 101 blog, mentioned this issue a few weeks ago as well.

As Martin points out, and as I know from experience, the traditional approach of archiving messages out of Exchange but still replacing them with a small message ("stub") that's a pointer to the original sometimes has challenges.  The fact is that if you replace every 5 MB email with a 1 KB email, you'll cut mailbox size but still retain high item count.  Indeed, the lack of mailbox size will encourage users to store more items in the long run.

There are a number of solutions to this problem - from:

• Pruning stubs over time (how many on-premise products handle it)
• Not using stubs at all and directing users to search instead

There is no perfect answer here, but users should be aware that mailbox size is only one of several issues to consider. 

Beyond the buzzword: SaaS and usability part II

David Ferris at the Ferris Research blog has written a quick post on LiveOffice and the trade-offs of having tons of functionality versus ensuring usability.

I find the ad salesforce.com is running in magazines to be the best description of how SaaS vendors should think about product development.

Salesforce.com shows a napkin that has a big circle drawn on it with "all CRM functionality" written inside and a smaller intersecting circle with "all CRM functionality you actually use" which is what they then focus on.

SaaS is about building software where the features actually get used by everyone rather than having a bunch of features that most people don't use and which clutter up and confuse the experience for everyone else.

Obviously for super-complex mega-companies, that may not be enough, but for the typical business or organization, it's all about the 80/20 rule.