Dislocators for Email, Messaging, and Collaboration

To enter a mature market, start-ups need there to be dislocators or “sea changes” in technology or business model or, better yet, both.

For example, WebLogic (my last time around the block) benefited from three technology dislocators and one business model dislocator:
(1) The emergence of the Web, and the associated requirement to deliver Web-enabled applications;
(2) The emergence of Java (a.k.a. managed code);
(3) The definition of a set of standard programming models for server-side Java (a.k.a. J2EE); and
(4) The use of the free trial Internet download to allow programmers to self-select (and to bypass the historical top-down sales cycle).

(Even with those dislocators going for us, we still had to coin a new category name—“Web Application Server”, because there was no way the venture capitalists were going to invest in a Java transaction processing monitor. Further evidence for those dislocations is Microsoft upgrading from Visual Basic and DCOM to C# and .NET, which the Java and J2EE communities can and should take credit for motivating.)

As Zimbra is poised to enter another mature market against very talented, deep-pocketed incumbents like Microsoft, we had better make sure we have some significant dislocators going for us. Here’s my short list of technology sea changes:

(1) Ajax (Web 2.0 UI) — Web 1.0 didn’t turn out to be much of a dislocator for email even though email is one of the “killer” applications of the Internet. The issue, of course, is that HTML is not itself rich enough to provide a great email experience. Ajax is, and moreover finally allows us to combine fat client richness with browser security (no VPNs required) and zero client administration.

(2) XML and web services (Web 2.0 integration) — The sum of XML for inter-application communications and Ajax
is greater than the parts. XML plus Ajax allows for the mixing and matching of the browsing (“pull”) experience and the email (“push”) experience to reduce all of that cutting and pasting from email to browser and back. Moreover, it also allows other business applications to directly access the messaging infrastructure so that it no longer need be a black box that does not play well with others.

(3) The emergence of Internet-based collaboration technologies — The Web itself is growing up into a collaboration platform: RSS and Atom for publication; Wiki for collaborative authoring and versioning; iCalendar and CalDAV for sharing meetings and events on intranets and the Internet; instant messaging and presence; voice over IP; and so on.

(4) Mobility — While the application model for mobile remains murky to me (J2ME versus PocketPC vs. Flash/Flex vs. Ajax, and so on), the success of Blackberry and its competitors has reset the bar to “over the air” synchronization of email, calendar, and contacts, and generally without any additional client-side install of software.

(5) Storage management — As email has emerged as a business-critical application, email servers have moved to relatively more expensive managed storage (SAN, NAS), and large attachments are no longer the exception. Hence keeping one copy of a multi-megabyte message for each recipient or each storage group/database has become unacceptable.

(6) Search and cross-mailbox search — Powerful search is simply far better than human-intensive organization via folders. The bar has been reset by technologies like Google and Apple Spotlight: Indexing must be done a priori so that search is nearly instantaneous. And once you have powerful search within mailboxes, why not natively provide the same search across mailboxes so that compliance-related discovery can be accomplished by packaging up a virtual inbox of messages matching the discovery criteria (and without having to pay lawyers to sift through reams of email printouts).

(7) Archiving, hierarchical storage management (HSM), and disaster recovery — Other mission-critical systems such as databases provide native support for protecting the data contained therein. Why should email servers require expensive third-party bolt-on’s that double storage requirements and administrative overhead?

At the same time, the incumbents are also facing business sea changes:

(8) Open source — Open source is a particular effective way for start-ups to challenge incumbents by leveraging community help, offering investment protection beyond their direct reach, etc. Open source is a far more effective dislocator than the free trial download. See Open Source Software: It isn’t just for developers anymore.

(9) On-demand — While on-demand is not a perfect fit for every application, businesses are rightly frustrated with the cost of installing, configuring, managing, and especially updating third-party software on-premises. As broadband costs continue to drop, on-demand or hosted deployment of relatively stand-alone applications and systems becomes a compelling alternative. Many small businesses today already leverage externally-hosted email solutions, most often packaged with other technologies.

(10) Appliances — Where an on-premise solution is indicated, software appliances that embed underlying components (operating systems, databases, web application servers, etc.) and fully automate their administration and maintenance, provide a far more compelling total cost of ownership than endusers having to take ownership of the full stack themselves.

So that’s a top ten (and I was not even trying for ten) sea changes and potential sea changes coming to corporate email, messaging, and collaboration. Incumbents ignore them at their peril, but willingness alone may be insufficient if the “re-architecture” required for success undermines the existing business or is a bridge to far from an older, more monolithic code base.

Comments are closed.