Pie in the Sky

A truism of today’s IT investment climate is that there is little appetite for conducting forklift replacements of anything. Just as there was talk of closing the Patent Office in 1890 because all the inventions had been invented, a similar outlook persists with enterprise software today because, if you didn’t need to replace it in year 2000, you probably won’t need to now.

So what do you make of somebody trying to sell you on replacing your email system? What kind of ROI or competitive advantage could you get by replacing the it?

Recently, an open source startup, Zimbra, introduced a new system that demonstrated what you could do if you merged the email client with the web. We eventually caught up with Scott Dietzen, the same guy that introduced WebLogic, who heads the new venture.

We first crossed paths with Dietzen back at Java One in 1997, where his startup demonstrated one of the first appservers based on technology that would eventually become J2EE. A riverboat gamble, but the right one. Dietzen’s company was eventually acquired by BEA, whose technology became synonymous with Java until IBM challenged it.

There’s an indirect parallel between what Dietzen & Co. demonstrated back in 1997 and what he’s hawking now.

If you recall, when Java first came out, the excitement was around Java applets, because they could enrich static web browsers with animation and interactivity. Not surprisingly, at that Java One, the crowds thronged booths showing dancing letters. Consequently, we had plenty of quality time at Dietzen’s booth to learn about server-side Java, which eventually proved the real value proposition.

This time around, the hype around Zimbra was again the rich client, which uses Ajax technology. Instead of a static email, mouse around an address, and a Google map appears. Or move over a customer name, and a summary of their CRM file and your next scheduled meeting with them pops up.

By contrast, current email systems require you to toggle back and forth between email, the web, and whatever application you’re running to view or insert data. But with the Zimbra client, it’s all accomplished by embedded web services.

According to Dietzen, most corporate users spend roughly 40% of their time in email. But is the resulting improvement to productivity ample justification for dumping the old email system?

Turns out that, like Java circa 1997, the real value is on the server, not the client. Zimbra’s server taps the inherent efficiencies of the Linux file system and the MySQL database to deliver today what Microsoft promises with the long-delayed WinFS file system – if it ever comes out.

With Zimbra, you could search all instances of email on a specific topic across everybody in the company, see who received which file attachments and when, and so on. Not a bad trick to have the next time the SOX auditors show up.

But is the email market actually up for grabs? Email may be the system we love to hate, but it’s hard to imagine that organizations would be willing to bear the disruption because the new technology is slick. Maybe if your company still uses the mainframe for email, or you need better audit trails because one of your CxOs just got indicted.

Still we can’t totally dismiss Dietzen’s folly out of hand.

Zimbra’s using viral open source strategy to seep inside the enterprise. It must eke out enough modest victories, plus a mainframe conversion here or there, to keep the money patient.

The inflection point could happen once Microsoft finally debuts its long-awaited successor to Exchange.

Say It Ain’t So

Every trend has exceptions. And in the software industry, Mercury was one of them. In an era of consolidation, Mercury remained independent. And it generally stayed profitable, even after the bubble burst.

Last year’s $685 million revenues represented a 35% jump over 2003, with income doubling to $84 million. Try identifying a software vendor over $500 million today with comparable growth. Google excluded, you can’t.

Mercury prospered the old fashioned way: it made better product. For distributed applications, Mercury’s software testing tools consistently lead the market over a decade.

And growth was pretty smart. Realizing that its core market of software testing was maturing, it acquired project portfolio management vendor Kintana in 2003. In so doing, it repositioned itself to respond to IT governance concerns in a new age of Sarbanes-Oxley. Although hardly the only vendor to make the move, Mercury was one of the first, compiling one of the broadest product offerings in the process.

So it’s more than ironic when this IT governance vendor winds up with a major governance issue of its own. A couple days back, Mercury’s CEO, CFO, and general counsel were each asked to resign over improprieties over their exercise of options. An internal investigation convened at SEC request concluded that they knowingly gamed the system.

The scandal is especially senseless because it was allegedly driven solely by executive greed, rather than a desperate attempt to salvage falling numbers. Although Mercury’s 2005 numbers haven’t been stellar, that’s had nothing to do with the allegations.

Mercury’s business will survive, but can it stay independent? A perennial issue for any software firm under the $1 billion mark, the question is especially acute for firms encountering such a confidence bump.

The answer is surprisingly simple, although not necessarily easy.

Mind the basics. Start with a sound core business. Cultivate existing customers because they’re your lifeline (and they’d rather not switch vendors if they can avoid it). Naturally, clean house, and if the product mix needs updating, don’t shy away.

CA proves there are second acts. Although not yet out of the water, the latest quarter looks positive. Incidentally, they’ve also tweaked the product mix towards IT governance, courtesy of a couple well-placed acquisitions over the past year.

Sure, Mercury lacks CA’s size and depth, but until now that’s not been the issue. If no other evidence of wrongdoing is uncovered, Mercury can tell its customers that the problems had nothing to do with product, vision, or execution.