Email Archiving, Email Hosting - SaaS

Beyond the buzzword: SaaS and deployment times

To all of the other dads in the world out there, Happy Father's Day! I enjoyed Sunday with a trip to the children's museum, some touch football with my buddies and fellow dads, tasty BBQ and rocking Guitar Hero on the Wii. And lots of love throughout. I hope your day was as wonderful as mine was.

Back to business, as a leader, I've always been a nut about the importance of on-time delivery. Whether it's releasing a new software version or launching a new website, it's critical to be predictable. So many other people and organizations (internal and external) build around your scheduled date. So slipping creates a snowball effect.

This is why I have always been so fascinated by how long it takes to get on-premise email archiving software deployed. I would find that customers often took several months and in some cases years to get internal archiving projects fully up and running. This was despite all of our significant efforts as vendors to simplify the installation process.

Over time, I realized that client delays in deployment were only partially related to software installation:

• Delays in storage configuration. In many organizations, storage is a separate discipline and sometimes a distinct organization. As I described, the process of choosing, sizing, procuring and provisioning storage is non-trivial. Obviously with a SaaS email archiving solution, the storage is automatically provisioned and scaled behind the scenes.
• Delays in server configuration. Customers typically have a standard server vendor. But they often struggle deciding how many servers they need to handle the archiving load and also maintain reliability. Most on-premise vendors offer excellent sizing guides. But many of these documents are 50-100 pages and still require follow-up consultation with the vendor and/or their partner. In a SaaS deployment, customers don't have to think about sizing or servers - they simply think about the service that they need.
  
• Delays in selecting and scheduling professional services. Nearly every on-premise email archiving vendor recommends or requires professional services for installation and deployment. If you are choosing an on-premise solution, I highly recommend this route as the complexity is significant; you should trust the experts. Some vendors offer services through their own firm. Others also offer services through partners. Customers often need to decide on which partner is the most proficient (or whether to use the vendor directly). Then they need to negotiate on rates and terms. Finally, they have to schedule the consultant(s) to come on-site. Not surprisingly, given how hot email archiving is, getting a consultant on-site can often take 4-6 weeks or more. Clearly with a SaaS email archiving offering, the software is already deployed; all that is required is to personalize it for your needs.
• Delays because you have to get it right the first time. Most significantly, customers know that they have to "get it right the first time" with an on-premise deployment. It takes so long that you absolutely can't go through it again. So customers often spend weeks in committee meetings to make sure everyone buys off on the approach. Anyone that works in an organization of any size knows that universal consensus can take a while. One of the beautiful aspects of SaaS email archiving is that you can get up and running right away and tweak it as you go.

In reality, the "next-next-next" of the Windows installer for the on-premise product is often the smallest part of the deployment time. On-premise vendors can only go so far in terms of addressing this issue.

In contrast, SaaS email archiving solutions are up in running in hours to days, not weeks to months to years. Customers simply configure their email server to domain to forward/journal email to us. We take care of the rest.

I hate delays. :)

Beyond the buzzword: SaaS and storage management

It's easy to get lost in your own little world. But life is very good at bringing you back to reality on a regular basis.

I remember going to a family function a few years ago. A very well-educated friend of my parents' who happened to be a physician asked me what industry I'm in. Having been a new, eager employee to what was then called VERITAS Software Corporation, and having drunk the Kool-Aid of our mission to change the world with our "No Hardware Agenda" strategy, I answered proudly that I'm in the storage industry. The doctor responded excitedly that he was looking to move and needed to find cheap "storage" for his furniture during the transition. He asked for my business card.

The reality is that even in IT, storage is often an after-thought. The two things I hear from people that are not deep into this stuff are: (1) storage is so cheap and (2) we have TONS of storage. Storage, storage everywhere but not a spindle to use.

Unfortunately, in on-premise email archiving deployments, storage often ends up becoming an after-thought as well. Customers purchase email archiving solutions (whether SaaS or on-premise) for the mailbox management, E-Discovery, compliance and other benefits. Given that, in most cases, the team responsible for email and/or legal drives the decision. Buying a new, energy-hogging storage cabinet to keep the office warm is the last thing on their minds.

I can't count the number of visits I've had where the customer gets to the realization that they are going to be creating tons of data and need a place to store it. If they're lucky, they bring their "storage expert" into the room who often hasn't been informed about the project at all. In most cases, for small-to-mid-sized businesses, there is no such role, so they have to learn as they go.

Some of the challenges I've seen customers, particularly ones with limited IT staff run into:

"We have extra space on the SAN." In most IT departments, there is some extra storage "somewhere." Many small-to-mid-sized on-premise email archiving deployments often start by leveraging the available storage in-house. Unfortunately, most organizations quickly realize that archives keep growing and often very rapidly overwhelm available internal storage. In addition, as you'll see below, archive storage needs to be very finely-tuned and nine-times-out-of-ten, what the customer has in-house won't work for the archive.

"How much storage do I need?" Sounds like an easy question. I guess you can ask the storage hardware vendor and let him or her tell you, but that seems like letting the fox guard the hen-house. In reality, the answer is "a lot" and "more every day." Most on-premise vendors have tools and white papers - in many cases, ones that involve 50-100 pages of reading - to answer the question precisely. Obviously you need to assess your mail volume, message size, retention period and other factors. The sizing is surprisingly arduous and complex.

"It's an archive so I'll just use cheap disk." One of the basic principals of archiving is that old email will be accessed less frequently by users and therefore it can be stored on cheaper (lower-performance) storage. In geek-speak, this means things like using Serial-ATA drives for archival instead of Fibre-Channel for production email. Unfortunately, people take this to an extreme and often think the whole archive involves cheap storage. In reality, most archives have three pieces of data: (1) archived emails themselves, often written as files, (2) high-level metadata stored in some kind of relational or XML database and (3) search indices. The archived email indeed can be stored on relatively-cheap storage (though see below for more on this). But the database metadata needs to be stored on high-speed disk, like any database. Furthermore, the search indices are often even more temperamental about disk I/O times. As a rule of thumb, the database and index data can end up being 10% - 50% or more of the original content size. So you end up needing to buy a significant amount of significantly-expensive disk. :)

"This #!@# archive is slow!" Despite the best of software engineering in on-premise products, they are dependant on storage hardware and its proper configuration. Usually you only figure this out when you have a huge E-Discovery or compliance request and need to search through and export thousands or even millions of email messages. The searches can be slow due to poor performance or misconfiguration of the area where indices are stored. But the actual bulk export of messages itself can be a nightmare if the storage isn't configured correctly. Indeed, this mass export use case is why you can't just use cheap disk for archival without thinking it through at all. And of course, this all happens when you've got a lawyer camped out in your office waiting for the data.

"How do I move all of this data?" This one is perhaps the scariest of all. The math is simple. Storage arrays last 3-5 years. Archived data is often retained for 5-10 years or longer. So now you have this array with 100s of GBs or TBs of data. How do you migrate it all to a new array? How do you preserve compliance in the process? And make sure it all works? And how long will it take? This migration problem is a ticking time bomb for many customers and there is no easy answer.

Obviously with Software-as-a-Service, storage is still complex, but the customer doesn't deal with it, we do. And for whatever strange reason, I find storage fun. I've got issues... :)

Beyond the buzzword: SaaS and innovation

As a longtime NFL fan, I've gotten used to the perennial ritual of sports writers identifying "seminal" changes that are "redefining the game of football." Some of these analyses pass the test of time and turn out to be legitimate evolutionary points in the game (e.g., the "era of the passing game" with QB-friendly rules and refs). Others are eventually called out for what they truly are - cool new phrases to describe things that have been happening for some time (the term "post-free-agency era" comes to mind; geez - that happened in 1989 so we're pretty squarely in the era!)

Now enter the IT industry, where buzzwords flutter around faster than the West Coast offense. Customers (and vendors sometimes) ask: which trends are real? And which ones are simply the result of marketing teams desperately relabeling old ideas to make new headlines.

With that in mind, I'm enjoying taking a critical eye to what's truly different about Software-as-a-Service (SaaS).

Having been in the tech world for a while, I entered LiveOffice with a healthy skepticism over how much is unique about SaaS. After all, the 101 highway in Silicon Valley near my house was littered in 1999 with ASPs, MSPs and ISPs before they all went RIP. And the idea of running centralized servers and delivering service over data lines is kind of the Internet in general, no?

Yes and no. I'm going to write a few posts over the coming months on some of the truly unique aspects of what I'm seeing, as a recovering "licensed software guy" reformed to this new world.

As anyone who has run an on site software product team in the past can attest, what always kills you is when you realize how much of your resources go to things that don't help the customer's business problem for which they are talking to you in the first place. Obviously it's a trade off. On site software provides great value and can be tightly integrated into your network. But I'm now learning some of the challenges in terms of providing innovation for customers:

1. Compatibility. One of the biggest issues any on site vendor has to deal with in terms of development and testing is managing the huge matrix of possible systems in the customer environment with which the vendor's product may have to integrate. In the archiving world this often means [# of Server OS versions] * [# of Client OS versions] * [# of Email Server versions] * [# of Email Client versions] * [# of Storage versions] * [# of Database versions] * ... You'd be amazed how much time this testing and development takes - especially when you consider how many service packs of Windows, security patches for storage arrays, and database versions, etc. there are out there. Obviously a SaaS vendor has one internal environment against which to test. This simplifies development and testing dramatically.
   
2. Management Tools. Over time, as an on-site vendor, you need to invest not only in customer-facing functionality but also into tools to help the customer manage your technology. These tools are very important to the IT user of the product and are critical for solution success. However, at the end of the day, they don't help the business get incremental value - they simply help deliver on the core value of what they already purchased. In contrast, a SaaS vendor only has to build management tools for its own operations team (for the most part), which means significantly-less effort.
3. Instant Upgrades. One of things that always blew me away as an on site vendor was how long it would take for a customer to get the new functionality that we built. We'd ship a new release and it would take 1 year+ in many cases for customers to (a) find out about the new functionality, (b) get the software, (c) plan the required hardware changes and upgrade schedule, (d) test the changes and (e) upgrade. In contrast, when a SaaS vendor upgrades, its customers are generally on the latest version right away. This can often mean 1 year+ difference in the "time to new functionality" for a customer.
4. Legacy Version Support. When an on site product vendor identifies a bug or issue, it often has to fix it in many different releases at once. Because of the pain of upgrades, many customers ask vendors to support products for several years after they are released. Hence, vendors often have many "supported" versions out in the field. This is good for the customer on paper but means the vendor needs to recode each bug fix in several "code trees" in parallel. Again, this takes away from the innovation the vendor can provide. Obviously, a SaaS vendor can instantly deliver a fix for all customers with one code change.

What does this all mean? Well, all of the above "non-innovation" development work adds up. From experience, "keeping the lights on" tasks can consume 80% of R&D resources in a mature organization. No matter how many people you have in your team, that's a lot of lost functionality.

As I said upfront, Software-as-a-Service is a trade-off and not panacea. But one of the big benefits you get, for customers that are able and willing to receive services rather than on site software, is that the vendor can spend more time innovating for the customer and less time maintaining.

I'll continue this theme on what's different about SaaS in future posts. I welcome your feedback.