Archiving101.com

Having been in the archiving industry for many years, one of the things I have noticed is that almost every vendor comes up with its own terminology about the same technology.   The term ‘archiving’ is sometimes used to refer to the physical capturing of the information non-journaling .. but I’ve also seen it being used to refer to stubbing, shortcutting, extending or stripping of items that already have been captured.

That brings me to the whole stubbing thing.  Stubbing, Archiving, Extending, Stripping, Shortcutting … if we as vendors already have a problem with understanding our own terminology .. what do you think the prospects think?   However .. for some reason the industry has come to a realization that the stripping, stubbing, shortcutting of data that is stored on a File Server is best to be referred to as File System Archiving .. almost every vendor uses that phrase.

Can’t we just come to an agreement to use a single ‘name’ for things ?

So lately I’ve been reading quite a bit on the usability of products. With this I’m not really referring to what the administrator sees when he opens up his console on Monday morning sipping a cup of coffee, but the stuff that the end users see and work with.

The success of an archiving solution partially (I’m not saying entirely here on purpose)  depends on if users can comfortably use the application to their benefit.  Important to understand is that a solution or feature that is too complicated to understand or use is simply going to be ignored by the end users.  A properly designed solution ensures that users optimally leverage the functionality given to them, resulting actually in a benefit for the employer (that could be increased productivity for instance).

Now .. if I talk to Product Managers from competing vendors they all agree that usability is important and they tout that theirs has the ‘best of class’ or ‘best in the industry’ … or whatever this weeks hot description is.  If that is the case .. why does my head hurt sometimes when I see screenshots of the user interface?  If it hurts me .. it probably hurts many other brains as well.

A solution should not only be technical capable .. but also usable.  There are tons of reports out there that probably give you some rough number or idea on ‘extra savings’ a proper designed user interface will give you so I’m not going to quote those (Google them if you wish).  In the last Gartner Magic Quadrant … ‘ease of use’ was seen as a big bonus point … and I’m glad that that is starting to be recognized.  The fact that archiving solutions solve a very complex problem doesn’t automatically mean that these solutions have to look complex or be complex to use.

Remember .. your end users will love you

Historically consolidating your archiving systems or moving to a new archiving product has been challenging in many occasion.  The fact that customers choose another archiving product isn’t always because something else is better (it is a large percentage however).  Companies get acquired and there might be another product in use already that will be made standard.  Or … customers opt to move away from an on premise solution to a hosted archive.  In my years in this industry I’ve seen it all … most often these migrations were painful, time consuming and costly.  The easiest way was to export all the data to PST (if that option was even available), and then import it back into the new system.

However you now can buy an off-the-shelf product that can help you migrate your archived data to a new system.  The folks at Essential in the UK have written it.  Right now it supports only a few archiving vendors, but I suspect more will follow. More details are at http://www.essential.co.uk/product/transvault/index.asp

Looks like people are finally listening and seeing that stubbing/shortcutting truly is ‘evil’ and that it has negative impact on an Exchange environment. Quoting from:

http://technet.microsoft.com/en-us/library/cc671168(EXCHG.80).aspx

Third-party archiving solutions have become popular as corporate compliance requirements and mailbox quota management have gained importance. Many of these archiving solutions offer the ability to leave a small stub file in place of the archived message that can be used by end users to retrieve archived messages from the archival system. Some organizations use the stub file solution as a workaround to offering large mailboxes. One of the goals of stub archiving solutions is to reduce the aggregate mailbox and database size, thereby reducing recovery time objectives (RTOs). On the surface, this appears to be a good idea. However, stub-based archiving solutions have the following technical problems:

• Server performance Removing the message bodies and attachments from Exchange reduces the mailbox size, but it does not significantly change the server performance for users accessing Exchange via Outlook in online mode and Outlook Web Access. Item counts are the primary performance driver for the Exchange store, and not aggregate size. For example, server performance with a folder containing 100 KB of full e-mail message items is similar to a folder containing 100 KB of stub files.
• Client complexity Because the use of stub files with a third-party archiving solution requires the deployment and use of Outlook add-ins, a significant amount of time must be spent by administrators to deploy and manage these add-ins. Administrator time is also required to assist end users with technical difficulties using the add-ins. Not deploying stub files removes all of this additional administrative work that must be performed, thereby allowing more time to administrators and end users.

Today I raise a glass and toast …. for the non-believers .. time to change opinion. Archiving vendors need to change their ways to capture information.