The reports of Microsoft's death are greatly exaggerated

Here's a conversation that happened at least twenty times with my startup friends in Silicon Valley when I told them I was taking the CEO role at LiveOffice:

Friend: So what does LiveOffice do?

Nick: We provide email archiving and Microsoft Exchange through software-as-a-service.

Friend: Exchange? Do people still use that?

Nick: Yeah - there are like 150 MM+ seats of Exchange out there actually and it's growing 30-40% per year.

Friend: Really? I heard Microsoft is going out of business or something on techcrunch.

Nick: Umm...

Friend: And by the way... email is pretty much dead with facebook, twitter and all.

Nick: Thanks for the vote of confidence. I'll let you get back to "mashing" things up or whatever it is that you do.

You can definitely get stuck in your own little bubble if you don't watch out.

From my experience at Symantec leading the Enterprise Vault team and now at LiveOffice, I can say that the Microsoft ecosystem and customer base around email is still alive and kicking.

Obviously Google has created a compelling alternative with Google Apps. But I've found that many customers still love the tight integration of Microsoft Outlook, Office and Exchange as well as the huge network of technologies and technologists around it.  For the thousands of SMB clients we serve, we see that users are very comfortable with Microsoft Outlook as an interface and are loathe to switch. 

Personally, I still haven't found a Web-based email service that allows you to get through emails as quickly as you can with Outlook.  But I'm biased. :)

And sure - email will evolve over the long run and will at some point be end-of-lifed. But folks have been saying that for nearly a decade and my inbox volume hasn't missed a beat. As the famous economist John Maynard Keynes said, "In the long run, we're all dead." Between now and then, I'll keep checking my Blackberry, thank you very much.

This article about a Google employee going back to Microsoft (from where he originally came) made me think about how skewed the view is between Silicon Valley ("Microsoft is dead, Google has taken over and actually is in decline because Facebook is the new king") and the rest of the world. My favorite quote (probably apt to describe much of Web 2.0 in general sadly):

"This orientation towards cool, but not necessarilly useful or essential software really affects the way the software engineering is done. Everything is pretty much run by the engineering - PMs and testers are conspicuously absent from the process. While they do exist in theory, there are too few of them to matter."

I also thought this was interesting:

"This is probably fine for free software, but I always laugh when people tell me that Google Docs is viable competition to Microsoft Office. If it is, that is only true for the occasional users who would not buy Office anyway. Google as an organization is not geared - culturally - to delivering enterprise class reliability to its user applications."

So in any case, we in the SaaS industry will watch with amusement as Google and Microsoft duke it out and the Bay Area writes off Redmond. Meanwhile, we'll eagerly service the "niche" 150 MM+ user Microsoft Exchange ecosystem.

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.

New season

I love football (and my beloved Pittsburgh Steelers), as anyone who knows me at all gets to know very (sometimes nauseatingly) well.  The glories of the game have been documented many times over.  But one of my favorite aspects of football is the blank slate and eternal optimism that accompanies the new season for every team.

I kind of feel that way about the new jobs that we take periodically in our careers.  There is nothing like the feeling of walking into a company and realizing how much unknown excitement lies ahead of you. 

On that note and as you may have heard, I recently (Monday) joined LiveOffice as CEO.  Needless to say, I'm fired up.

Almost five years ago, I had the fortune of being pulled into the messaging industry when VERITAS Software (now Symantec) bought KVS and I was offered the opportunity to get involved with the business.  The archiving product (Enterprise Vault) ended up doing very well and I was honored to have been a part of it.  And for some unknown reason, I just completely fell in love with the email and messaging industry, as well as with the amazing product and team we built specifically.

Because of this, when I left Symantec in October 2007, the good folks at LiveOffice asked me to join the Board of Directors last fall. I thought it would be a fun opportunity for me to learn about the Software-As-A-Service industry that I had heard so much about from the likes of salesforce.com and to help the company in any way I can based upon my archiving experience, while I pursued my own personal dream of finding a company to join and run.

Over the past several months, I learned more and more about the LiveOffice business and company and fell head-over-heels in love again.  There were three aspects of LiveOffice, in particular, that really caught my eye.

1.  Sector 

As I said, I am fascinated by the importance of email in our world.  So many smarter people than me have written about the importance of email to businesses that it's become a cliche.  Companies increasingly understand the needs to manage, archive, retain, discover and secure email effectively and are recognizing the overload employees are personally dealing with around email.

But what always struck me about email was the emotional impact it has on us: the unreturned email and the hurt feelings it can create, when the person may have just lost the message in the inbox; the "high" people get when they check their email and the addiction that this implies; the thrill of cleaning up your inbox, despite the inevitable futility of the effort.  

When I left Symantec, I really wanted to start or find a business in the messaging industry with which to get involved.  I looked at various startups and was intrigued with the new approaches to email productivity like what the guys at Xobni were doing.  I was equally impressed with what Microsoft and Google were planning themselves to advance the industry.  I knew that if I could find something in the messaging world, I will have found the next season of my career.

What really intrigued me about LiveOffice was that the needs we solve are well-understood (messaging, archiving, compliance, discovery, etc.) and that the method of delivery of the software ("-As-A-Service") was what was unique.  Having been involved in in-house software for many years, I saw the great things that could be done by balancing innovation, timeliness and quality for customers.  But I also saw the challenges customers faced with even the best of products if they didn't have the in-house IT staff, capital, expertise and tolerance for risk necessary to plan, provision, deploy, operate, troubleshoot and scale these systems.

Put more simply, it felt to me like messaging and message archiving are universal needs and yet not every organization was equipped to run these systems themselves.

In general, I'm a big believer that more-usable and transparent technology (which you see in SaaS, open source and appliances) is the future of IT, and this felt like a good way to mix my passion and experience while learning something new.

2.  Scale

At the same time, what I love about my work is leading teams.  I enjoy all of the minutia, melodrama and mania of managing people and growing organizations.  I looked at starting something from scratch, but in some sense, I was thinking about that as a means to an end of running a real company.  I get the biggest high out of working with people, getting them on the same page, helping them to find their professional dreams, as cheesy as it may sound, and in the process, creating an organization of positive energy, prioritization and passion.  All of this matters a lot more when you have 10 or 100 people versus 1. :)

In this respect, LiveOffice's stage as a profitable company with around 100 employees was very attractive to me.  There was a great base of technology and team to build on, with demonstrated history of substantial revenue, growth and customer loyalty (99% client retention rate).  At the same time, there was a great deal of fun work ahead to scale it to the next level.

But even more importantly, what I found amazing about LiveOffice was how it was built.  I'm from Silicon Valley and am used to the excitement and craziness typical with "venture-backed startups."  Raising money and "getting VC funding" is often the first priority for any entrepreneur. 

In contrast, the founders Alex Rusich and Matt Smith built LiveOffice on nothing but the sweat of the team, some money from friends and family and a few credit cards here and there. :)  I'm a firm believer that a business built in this way has more staying power because of the fundamentals and loyalty that all of that hard work creates.  And I was excited to learn from Alex and Matt in this regard. 

3.  Style

Most importantly, work is very personal for me.  I work because of the feeling I get from the team around me.  So the "cultural fit" (to use another cliche) is the most critical factor for me.

Having been on the board, I was lucky to have gotten a chance to know Alex, Matt and many of the employees of the company.  This is truly a remarkable and unique organization in terms of the loyalty and history that all of the employees have demonstrated.  I really think of the greatest of jobs as feeling like family (which is how things felt for me with my team at Symantec) and it felt like this family was one in which I'd be honored to be adopted. 

Needless to say, when Alex and Matt got to know me and asked me if I'd ever consider joining the company, even though they weren't looking for a CEO, it became the opportunity of a lifetime and a total no-brainer for me.  I kind of feel like new Pittsburgh Steelers coach Mike Tomlin in this regard. :)

I look forward to sharing more of my thoughts on the company, messaging, SaaS and perhaps some football in the coming months. Thanks for reading this.