Have to Versus Want to

In both professional and personal life, there are things we like to do and there are things we have to do. We have to pay taxes. We have to pay rent for our office space. We have to keep accurate records of our business transactions. We like to engage with our clients on innovative projects. We like the the work flexibility of remote access technology. We like going to a college football game on a crisp autumn afternoon. Based on my conversations with clients over the past few years, one of the things that is definitely falling in the “have to do it” versus the “like to do it” category is running corporate email systems.

Email has evolved to one of the, if not the most important business applications for many organizations. As email has evolved from simple communications that was a nice complement to the phone system, its complexity, its impact, its support requirements, and therefore its costs have grown exponentially. The “wow factor” for using email is gone. The “fun factor” of supporting email is definitely gone.

The good news in this development is that there is no reason to deploy, manage, or run email systems in the cumbersome and expensive ways of the past. Email systems can be deployed in one of three ways: 1) they can deployed in a traditional architecture with on-premise physical assets dedicated to email and managed by local staff. 2) Email systems can be virtualized either on site or remotely and run as file systems managed on a shared virtual infrastructure. 3) Email can be deployed in the cloud, as a service with one of several providers.

TBL is a big fan of 2 of these 3 options. Frankly, we hate to see any of our clients investing in a traditional email architecture. We believe that the leverage from either a virtualized email infrastructure or email-as-a-service from a provider like Cisco Mail is a far better use of scarce capital and resources. Without going into a long dissertation, virtualized email can either be a snap-on to existing virtual operations or can be an initial virtualization project that can be leveraged across the enterprise for exceptional returns to the business. Outsourcing email to a provider like Cisco Mail can provide users with the Outlook experience users know and love, but exports all of the capital investments and support activity to a “cloud” provider. Remember how much fun it was the last time your Exchange environment crashed? Remember the pleasant conversations with the end user community while your entire team dropped what they were doing and scurried to get email back up and running? In a Cisco Mail scenario you get to export all of the pandemonium of an email crash to your provider. In a virtualized email scenario, your email system is a file, like all of your other virtualized systems, and can be restarted off a boot from SAN to any available server resource. Both of these options sound a lot better to me than an entire I/T staff running around with their hair on fire scrambling to get email back up and running.

Since email is no longer something we like to do, but is unquestionably something we have to do, why not optimize how we deliver email services through the miracles of either virtual infrastructure or cloud services? Then maybe we can enjoy the college football season a little more.

2 Comments to “Have to Versus Want to”

Mark Farnsworth September 1st, 2010 at 7:51 pm

So I am all over options 2 and 3… specifically the cloud, but aren’t there some hurdles associated with a cloud based email systems and Unity?

Alan Sears September 2nd, 2010 at 9:16 am

Great question! With most public cloud-based e-mail, unified messaging (the ability for voicemails to be stored or appear in your e-mail inbox) will no longer be available. However, Cisco’s emphasis for voicemail going forward is Unity Connection, an alternative voicemail product from Cisco that has been around about 4 years now, and Unity Connection will have the ability to synchronize voicemails serverside with Cisco Mail in Q1 of 2011. Cisco Unity Connection is also a linux-based appliance with no dependencies on Microsoft Exchange, so you could have the best of both worlds. For more on Cisco Unity Connection, check out Patrick’s blog post on the Death Toll for Cisco Unity.

leave a comment