There is a healthy, ongoing debate—for example, check out Phil Wainewright’s ZDNet blog or our own prior efforts—over whether email (and associated functions like group calendaring, contact management, enterprise IM and so on) should be delivered via
(1) On-premises software that you configure and manage yourself;
(2) Outsourcing to dedicated service providers (e.g., EDS, IBM Global Services) that manage to your custom requirements (using dedicated hardware/software, often that you transition to them); or
(3) Outsourcing to generic hosted or application service providers (think Salesforce.com, but for email), who often aggregate email with other services (e.g., broadband, telephony) or applications (e.g., Microsoft Office Live).
From Zimbra’s discussions with customers, I agree with Phil that many endusers underestimate the costs associated with managing their on-premises messaging/collaboration deployments. Industry analysts are putting the average cost north of the ~$100 per user per year that you can expect to pay for the medium-tier hosted email solutions. And once you roll in support for wireless messaging (such as via Blackberry and the Blackberry Enterprise Server) and the additional costs of archiving and compliance, enterprise messaging can easily reach north of $1000 per user per year. So the net is that I don’t buy that lower cost is a good justification for on-premises email. (At Zimbra, our goal is to bring down costs for all three models.)
I also tend to agree with the SaaS advocates that the management of messaging and collaboration infrastructure is not a core competency for virtually all endusers. “Core” should rather be reserved for information systems that are customer and partner facing or for which there is inherent differentiable value-add (think programmed trading strategies). Email is absolutely business critical, just like internet connectivity and CRM. But that does not make it a core competency (unless you have tightly integrated email within you business processes, or unless you are a Microsoft or a Zimbra).
One of my problems, however, with the SaaS advocates is that they tend to conflate (2) and (3), when in fact they are very different beasts: (2), a.k.a. traditional outsourcing, gives the enduser all of the specialization and customization of on-premises software, with some reduced total cost of ownership (via amortizing operations and management overhead across multiple endusers), while (3), a.k.a., generic hosted/application service providers (HSPs/ASPs), can deliver greater cost savings with the inherent sacrifice of some specialization and customization.
The challenge to delivering all enterprise messaging/collaboration via the HSP/ASP model is that we still need to solve some harder problems. In weighing your choice between (1), (2), and (3), you need to think about more than just TCO:
(*) Custom integration with other applications — Since IT-intensive users often spend 1/3 of their working hours dealing with email, even modest improvements in efficiency can deliver dramatic productivity improvements in the aggregate. Web 2.0 technologies like Zimlets can deliver such productivity improvements by seamlessly making your email a portal into your other enterprise applications. As more of your business applications are themselves provided via ASPs, email ASPs are in a better position to provide such integration (i.e., cheaper to integrate once over the internet, rather on each and every intranet). But so long as the applications that offer such productivity improvements are custom and intranet-based, integration with generic applications over the Internet will often be out of reach.
(*) Integrated user provisioning — The HSP/ASP model generally requires provisioning users over a web services interface specific to the HSP/ASP as opposed to simply adding them to your enterprise directory (with the appropriate class of service) from which provisioning can be automated;
(*) Mobility — We anticipate a major reduction in TCO for mobile messaging as more standard infrastructure either displaces or drives down the cost or proprietary alternatives, but endusers still have to get from here to there by preserving the connectivity employees are depending on today while looking to better solutions tomorrow;
(*) Custom security, compliance, and archiving policies — The additional TCO associated with Sarbanes Oxley compliance is itself a motivator for divesting messaging deployments, but the immaturity of both the regulations and the technologies introduce additional hurdles. And then there are industry-specific security and retention policies, such as the fiduciary isolation of business units, that may have to be factored in.
Our conclusion? Enterprise messaging is a business critical but generally not “core” function of IT. As such, organizations should be considering (2) more custom outsourcing or (3) more generic hosted service providers, based on how specialized their messaging requirements are. So over time, we should indeed see less of (1) and more of (2) and (3) for enterprise messaging, but that your own specialized messaging requirements must be balanced against the lower TCO offered by (2) and even more so (3).
To reiterate what we have said before, from our perspective here at Zimbra, the key is to continue to architect Zimbra in a sufficiently balanced way that it supports this spectrum of deployment models—meaning that we need to get multi-tenancy, delegated administration, intra-server security, etc. right for hosting by our (3) HSP/ASP partners, as well as get the easy installation and compatibility with existing systems for (1) on-premises and (2) outsourced deployments. The good news is the vast majority of the Zimbra Community’s work (and hence the Zimbra codebase) is focused on improving the productivity of both users and system administrators, and hence relevant to all Zimbra users.
Comments are closed.