Pattern Finder

RIA/SaaS: Dealing with the Internet Version of the Keystroke Interrupt

James Fallows makes an interesting point in his "Another step toward the online 'cloud computing' life" post:

Web-based computing has a small disadvantage: working with an online program like, say, Writely (now Google Docs) is slower than using one based on your own machine, since info must constantly go back and forth from a remote server.

In other words, there's a certain value in client/server computing--now considered passe--since the client can perform work locally without always going back to the server. This value add has been true for years, and remains true now. At this point we've been through four generations of client/server architecture (that I know of--there may be more). The first is shrouded in arcane minicomputer history, the second is well-known, the third has been around for several years, and the fourth is happening as we speak.

The first began in the late 1970's, when Wang Laboratories was the equivalent of a dot.com wonder, growing at 100% a year and challenging the incumbent at the time, IBM, within the office market. Its success was due to the combination of a great product (word processor) and a smart architecture (client/server, although no one called it that at the time). Each Wang workstation contained a Zilog Z80 chip, which did a lot of the graphics work required when displaying and editing a document. For example, inserting a character would cause the following characters to move one position to the right, and therefore sometimes cause a word to jump to the next line. Because the Z80 did much of the work, the workstation talked to the server after only every tenth keystroke or so.

This smart design was Wang's secret weapon. For example, although DEC eventually got into the office market, all Wang had to do to beat it in a competitive situation was to suggest to the prospect that it run a test under a heavy workload. Having forty secretaries concurrently pound out memos would bring a VAX to its knees, because every keystroke was a CPU interrupt. On a Wang VS minicomputer, due to the Z80 doing much of the work, 200 typing secretaries was a typical and easily handled workload. Unlike the VAX, the Wang system didn't have a dumb terminal as a front end--it had a smart terminal.

All Google Apps Docs Can Now Be Viewed Offline

On Friday, The Official Google Docs Blog announced that all Google doc types (documents, spreadsheets, and presentations) can now be viewed offline. At this time, users can also edit word processing documents; that additional capability will be added over time for spreadsheets and presentations. The post also included a pointer to more information about Google Docs Offline: Overview: What is Google Docs Offline?

Of course, viewing and editing documents offline has been a capability of software for years. It's nice to see Google go retro and add some software flavor to its solution.

Book: "Dreaming in Code"

Dreaming in Code is one of those books about the ups and downs of a software project. Tracy Kidder's The Soul of a New Machine (1981) created the genre, and in my view it has never been equaled. Scott Rosenberg is an equally gifted writer--his explanation of Python and its place in the programming universe (pages 70-79) is masterful--but he picked a dud project.

Dreaming in Code is about building a new personal information manager code-named Chandler. Famous folks in the programming community turn up in the story from time to time--Mitch Kapor (creator of Lotus 1-2-3), Andy Hertzfeld (an early Mac programmer), and Lou Montulli (co-founder of Netscape)--but their experience and contacts were still not enough to make Chandler a success.

Design began in the spring of 2002. With the powerful Lotus Agenda as a historical rev 1.0 (however, Microsoft's Outlook cleaned its clock in the marketplace), Chandler was going to be a new rev 2.0. Besides helping users manage their e-mails, appointments, contacts, tasks, and notes in a very hyperlinking kind of way, Chandler would be cross-platform, running on the Windows, Mac, and Linux OSs. However, the project never really got off the ground, and it was scaled back in January of this year.

So if you want to get a feel for what's it's like to work on a struggling software project, read Dreaming in Code. It's interesting, but depressing.

CCS Has an Opening

Yes, we're looking for an analyst to join our Collaboration and Content Strategies (CCS) practice at Burton Group. The job posting is on the Careers page on the Burton Group web site; since the company currently has several openings--yes, we're growing--you'll need to scroll down a bit.

Some background. Burton Group is an IT analyst firm; we write reports and consult on IT issues such as security, identity, networking, data center operations, and programming. CCS, the practice I work in, covers collaboration, communications, and content.

Although Burton Group doesn't have as high a profile as Gartner Group and Forrester Research, it is the ninth largest IT analyst firm (according to Outsell), and we should climb up one or two more rungs this year. If you're worried about being a third-party marketing arm for vendors, don't. Burton Group is atypical in that the vast majority of our business comes from enterprises; only a small part of our business comes from vendors (15%). To put this into perspective, some analyst firms get 90% of their revenue from vendors; a typical percentage is in the 30% range. We don't hire analysts out of college; typically, our analysts have worked many years in the business by working in IT, by being product managers, and by being analysts at other firms. I, for example, have done all three.

If you want to be an analyst (at Burton Group, anyway) you need to:

• Know your stuff
• Write well
• Have opinions that you can back up

If you think you have the right stuff, apply by sending your resume to Lynn Ward at [email protected].

A SaaS Lesson for Microsoft: Simplify the Licensing

Whether an enterprise has purchased a SaaS solution or still kicking the tires, the feedback I continually get from clients is, "Boy, you gotta like the simple licensing model."

In the office applications space, Microsoft has built an empire out of complex licensing. The sales rep patter goes like this. "Oh, you want e-mail? Well, you're going to have to buy a Microsoft Exchange Server license, a number of Microsoft Outlook licenses, and then a group of Client Access Licenses (CALs) so the Microsoft Outlook clients can legally talk to the Exchange Server. Or, if you want other stuff, we could set up an Enterprise Agreement and you could get a discount on a wide variety of Microsoft products. Let me fire up my spreadsheet so I can figure out the discount we can give you."

In other words, an enterprise is sent back in time to more than 160 years ago, when buyers and sellers haggled over prices. (For the historians in the crowd, fixed prices and price labels on products arrived in the 1850's, coinciding with the arrival of the first big department stores: Bon Marche, Macy's, and Marshall Field.) When enterprises look at the time they spend with Microsoft negotiating terms (weeks or months) versus the time they spend with Google  (seconds: multiply $50 per user per year by the number of users and then click "Yes"), they much prefer the Google model.

To highlight the real world frustration with Microsoft's pricing model, following is an excerpt from an e-mail sent to me by a Burton Group client at a Fortune 500 company:

MS has miles to go in terms of simpler pricing. That's another thing I'm looking for this year. We have spent 6 months now trying to master SharePoint pricing and even our MS account team can't give a clear answer. Server OS licenses. MOSS license per server. Product license - Project web access, Excel calc services... - are they for EVERY server in the farm, or only those where we've enabled that product? Heap-o-synergy design means we MUST install every piece of software on EVERY web & app server in the farm, regardless. Then the CALs - Server OS, MOSS, MOSS Enterprise, Project, Excel... Compare with Google - $50 / year / person buys everything on the menu, and no hardware required. Archiving is extra. This means everything Google introduces is instant value-add for us without complicated arithmetic or lengthy justification, budget, PO, invoice... cycles.

Stark Reminder: Gmail Is Still in Beta

Oops. A little more than a week after I mused that enterprises should start investigating the Gmail portion of Google Apps as a Microsoft Exchange replacement, Google proved me wrong. David Berlind noted in a Tech Radar blog post that the Gmail IMAP interface took a vacation yesterday, meaning that he couldn't access his e-mail via Microsoft Outlook. Even the Ajax features within the standard interface for Gmail weren't home. He says,

But, what are the implications? Somewhere at some business where all the users were tying into a Google Apps-based version of Gmail, someone's phone probably started ringing off the hook. Maybe it was the CFO or the CEO who set his/her entire company up with Google Apps because of how easy it is to do (it's VERY easy) and how s/he's avoiding all sorts of costs associated with running something like Microsoft's Exchange Server or Lotus Notes (including the people needed to run those things).

But today comes the flip side to the argument. Something goes haywire at Google (there was no announcement, warning, or post to the official Gmail blog before this happened) and what would that CFO or CEO do next? Basically, there's nothing s/he can do about it except wait until Google fixes it (I thought of switching my clients to Gmail's still-active POP interface until the IMAP interface was fixed, but that is most definitely not a good idea).

Even more of a challenge for CxO's taking the Google, Salesforce, et alia shortcut (a shortcut I still favor, by the way), is what happens if applications like Gmail and Salesforce are integrated into each other in a way that a failure of one stifles the functionality of the other.

All good points. My post last week acknowledged that there would be bumps in the road:

To be truthful, I'm not convinced it's ["Google Exchange"] fully baked yet. In the updated version of my Google Apps report (released today), I say, "GAPE is on the road to becoming a credible replacement for Microsoft Exchange if an enterprise wants to stop paying for Exchange server and CALs licenses but wants to keep Microsoft Office." Notice that I don't say "is a credible replacement," but instead say "on the road to becoming a credible replacement."

That's the problem with these new technologies. They're never perfect out of the gate. I remember when LANs came in in the 1980's, and at that time they were a joke. They went down all the time, they weren't very scalable, and they looked like they'd never be a replacement for ubiquitous (at the time) mainframes and minicomputers. But Banyan and Novell worked at it, and they became solid technologies. The real trick is figuring out when the inflection point has occurred. With Gmail, it looks like it hasn't arrived yet.

A Google Apps Buyer Profile via Press Release?

As an IT analyst I'm e-mailed a lot of press releases and just got one this afternoon that starts off, "Early response has been nothing short of phenomenal to Cemaphore Systems' recent announcement of MailShadow for Google Apps (MailShadowG)." MailShadowG synchronizes the Gmail servers with Outlook (thereby allowing an enterprise using Google Apps to de-install Microsoft Exchange) and offers Outlook backup for continuity. The company was looking for 500 beta testers; at this point the number of applicants is hovering around 2,000.

However, I thought the really interesting tidbit was Cemaphore's characterization of the beta testers:

While the majority of applicants (70 percent) are from small-to-medium companies (1-500 mailboxes) as was anticipated, it is important to note that a full 15 percent of these immediate applicants are from large organizations. Individual users accounted for 10 percent of applicants, with the remainder coming from academic institutions and government. In another somewhat surprising development 40 percent of the immediate applications are from international customers; while 60 percent are from the United States.

It's unclear how closely this beta test community profile maps to the Google Apps user base at large, but I don't think it's wildly divergent. In the Cemaphore Systems' case,  80% are either individuals or SMBs, which buttresses my argument that its popularity is centered outside of the enterprise space. Fifteen percent of the interest coming from large organizations strikes me as a bit high--I was figuring 10%--but 20% wouldn't have been out of whack. I don't think this means that 15% of the current Google Apps user base is large enterprises; I'd read it as Advanced Technology groups within large enterprises are seriously kicking the Google Apps tires.

There's nothing that says large enterprises have to use Google Apps in the way that Google is marketing it. And as I noted in a blog post last week, I think IT departments are tuning out Google's mantra of coolness and consumer-centricity and taking a block-and-tackle approach: "If I can put in Gmail and (1) save a lot of money compared to Microsoft license fees and (2) my end users never even know I did it, that's a win."

Five percent of the applications coming from academic and governmental institutions strikes me as low--I'd figured it would be somewhat higher, given Google's success in the university space.

In short, maybe not definitive numbers, but at least interesting and not wildly out-of-whack numbers: a useful set of datapoints as everyone--enterprises, IT analysts, the press--tries to figure out the future of SaaS-based collaboration, communication, and content.

The Impact of Moving from Final Versions to Early Drafts

An excerpt from page 13 of the 2006 Burton Group Collaboration and Content Strategies report, "The Copernican Revolution in Content," bears repeating:

Content management has moved upstream in the creation process over the years. In the past, secretaries typed only important documents, such as major memos and contracts, since it was too expensive and time-consuming to type ephemera. However, as employees began typing e-mails, they started to document unformed thoughts, while blogs now capture thought snippets and distribute them to potentially millions of readers. Wikis are literally works in progress.

While capturing work-in-progress content helps employees collaborate, it also brings with it an increased compliance burden. Rather than locking up a set of file cabinets containing important documents, enterprises must now archive memos, spreadsheets, e-mails, instant messages, pictures, and a host of other digital content. Furthermore, depending on content type, this can become a complex process. For example, a company may retain e-mails for two years, but contracts for seven. This means that if a contract is e-mailed, the archiving system must store the contract and the e-mail separately, so the contract does not vanish when the system destroys the e-mail transaction.

Generating content earlier in the process also means that enterprises must offer a spectrum of control. While companies must ensure that final versions of documents are secure and cannot be altered, such control is anathema to wikis, which exist just so scores of employees can modify them collectively.

Two years after writing this, I find that people still miss this pattern: the shift from businesses (1) creating only final versions to (2) creating the full spectrum of documents, ranging from early drafts to working versions to officially published documents. Since this shift occurred slowly--it's a three decade span between the heyday of typewriters and the arrival of wikis--it's not surprising that people still don't recognize the change. However, once you convert to this worldview, a whole bunch of Aha! moments take place.

Oracle Getting Deeper Into Records Management

Oracle announced two records management products yesterday at Collaborate 2008: Oracle Universal Online Archive and Oracle E-mail Archive Service. Built with Oracle's ContentDB technology, the Universal Online Archive is a place where enterprises can archive digital documents. ("Online" in the name refers to the fact that it stores digital (online) versus paper (offline) documents, not that it is a SaaS-based service.)

The product interrelationships are as follows. Oracle's Universal Records Management serves as the policy engine; Oracle Universal Online Archive serves as a high-volume repository; Oracle E-mail Archive Service is the archiving interface for getting e-mails from Microsoft Exchange, IBM Lotus Notes, and SMTP-based mail systems into the Oracle Universal Online Archive. Oracle says that e-mail is the beachhead; it will offer other archiving services over time to make it easier to archive documents from other systems (e.g., Microsoft SharePoint, file servers, production systems).

I'd say there were two interesting tidbits from the pre-briefing I had last week. First, Oracle is mentally splitting content into three buckets: active content (controlled by Universal Content Management), transactional content (controlled by imaging and process management), and historical content (controlled by Universal Online Archive). While I would split it into draft, active, and historical buckets instead, I applaud Oracle's larger view. Too many vendors concentrate on talking about one or the other: active content (content management vendors) or historical content (backup, information lifecycle vendors). At this point, no one talks about draft content (blog and wiki vendors should). Second, Oracle noted that within Oracle, active content (which it defines as having a 30-day life) is a much smaller percentage of documents than that of historical content (which it defines as having a 5-year life). A stat worth keeping in mind from both a security and disk cost point-of-view.

Salesforce.com Now Selling Google Apps Since Google Can't Do It

Salesforce.com is announcing rather breathlessly--using the headline, "A Dream Come True for Your Business"--that it will start reselling Google Apps. Henry Blodget, in Silicon Alley Insider, characterizes the deal as, "Google-Salesforce Deal Shows Google Not Insane, Microsoft Disruption Continues." A more accurate headline (and analysis) would have been, "Google-Salesforce Deal Shows Google Apps is Struggling, Microsoft Disruption Continues."

Fourteen months after announcing Google Apps, Premier Edition, Google still has not convinced a major corporation to install Google Apps enterprise wide.  I've heard rumors that Genentech has decided on Google Apps, but the connection there is that Dr. Arthur Levinson, the Chairman and CEO of Genentech,  also serves on the Board of Directors at Google.

A year ago, Google announced Google Apps Premier Edition to great fanfare, and the cheap price ($50 per user per year) meant that Google got its foot in the door at many corporations. But Google then found that enterprises, after listening to the sales pitch, slammed the door on their leg. It isn't that enterprises aren't listening--they didn't shut the door completely--but at the same time they aren't opening the door wide, welcoming Google in, and signing the necessary paperwork.

There are a number of reasons for this wariness, but they all come down to the fact that Google Apps is missing certain features expected by large corporations: e.g., an offline ability to work (which Google is fixing by stages), records management for documents (Google has a solution for e-mail), and role-based administration (which Google says it's working on). In other words, the strong Google brand hasn't been able to overcome product shortcomings. (That Google was figuring its brand would overcome any objections was brought home to me one day when a client told me that when they told Google that they wouldn't be buying, the Google sales rep blurted out, "But you have to--we're Google!")

This is not to say Google Apps hasn't been successful--it has been in the SMB and education markets, where requirements aren't as stringent and the price isn't as high (Google Apps Education Edition is free). But Google hasn't been able to sell Google Apps to the Fortune 500, and that's frustrating it.

Consequently, it's changing its sales strategy. The first thing it did was sign up Capgemini to support and recommend Google Apps, but the only installation I'm aware of through that partnership is an internal installation of Google Apps at Capgemini itself. Then Google came out with Google Apps Team Edition, which bypasses the IT gatekeepers and encourages business users to ultimately gang up on IT and demand the solution's installation. (I can't imagine that strategy has won a lot of friends in IT departments. They're probably sitting there thinking, "Google is doing evil.")

The latest gambit is to have Salesforce.com sell it. Salesforce has a much larger sales force, and is also much more enterprise savvy. Also, the integration within the Salesforce.com application is quite nice. However, this is an installed base play--non-Salesforce.com customers won't be touched by this initiative.

Google Apps is a supreme disrupter and creating a whole new market sector in the process. But until Google figures out how to talk to the enterprise and offer a product it needs, it's going to be stuck at the door--and companies already in the door (e.g., Adobe, Cisco, Microsoft) are going to be working hard to get a signature before Google does.

Book: "A Short History of Financial Euphoria"

As we head into a recession, a good book to remind you that this has all happened before is John Kenneth Galbraith's A Short History of Financial Euphoria. The title is correct--the book is short: 113 pages.

Although written in 1990, his words could be used describe recent events: the dot.com boom and bust, the rise and fall of Enron, and the mortgage market collapse:

Some artifact or some development, seemingly new and desirable--tulips in Holland, gold in Louisiana, real estate in Florida, the superb economic designs of Ronald Reagan--captures the financial mind or perhaps, more accurately, what so passes. The price of the object of speculation goes up. Securities, land, objets d'art, and other property, when bought today, are worth more tomorrow. This increase and the prospect attract new buyers; the new buyers assure a further increase. Yet more are attracted; yet more buy; the increase continues. The speculation building on itself provides its own momentum.

This process, once it is recognized, is clearly evident, and especially so after the fact. So also, if more subjectively, are the basic attitudes of the participants. These take two forms. There are those who are persuaded that some new price-enhancing circumstance is in control, and they expect the market to stay up and go up, perhaps indefinitely. It is adjusting to a new situation, a new world of greatly, even infinitely increasing returns and resulting values. Then there are those, superficially more astute and generally fewer in number, who perceive or believe themselves to perceive the speculative mood of the moment. They are to ride the upward wave; their particular genius, they are convinced, will allow them to get out before the speculation runs its course.

And then, of course, the crash comes.

If you're a bit weak on economic history and want to brush up, Galbraith gives capsule histories of some of the great boom-and-bust episodes: the tulipmania in Holland in the 1630's, the Bank Royale scandal in the early 1700's, and the Crash of 1929.

A quick and enjoyable read from a famous economist, while at the same time a bit unsettling: "We should have seen it coming...."

   

Google Should Announce Google Exchange

Google should wake up and announce Google Exchange: the Google alternative to Microsoft Exchange. However, the good news is that you don't need to wait for Google product management to figure out the obvious and make the official announcement--you can start investigating it today.

To be truthful, I'm not convinced it's fully baked yet. In the updated version of my Google Apps report (released today), I say, "GAPE is on the road to becoming a credible replacement for Microsoft Exchange if an enterprise wants to stop paying for Exchange server and CALs licenses but wants to keep Microsoft Office." Notice that I don't say "is a credible replacement," but instead say "on the road to becoming a credible replacement." However, at this point I think some enterprises may be willing to accept some product deficits to gain savings.

I didn't say this back in August 2007 when the first version of the Google Apps report came out, so what's changed?

• IMAP Support: Google Apps now supports IMAP. This means that Microsoft Outlook can store Gmail messages offline.
• Google Calendar/Microsoft Outlook Sync: Google Calendar can now synchronize with the Microsoft Outlook calendar.
• Better Exchange Documentation from Microsoft: Today, Microsoft posted detailed information on how Microsoft Exchange Server 2007 and Microsoft Outlook talk between themselves on MSDN. In other words, with this free documentation, it's going to be easier for Google and others to replicate Exchange/Outlook behavior.
• New Add-Ons: Today, Cemaphore Systems announced MailShadow for Google Apps (currently in beta), an application that will synchronize Outlook e-mail, calendar, and contacts with Gmail.

Product deficits? You can't yet have proxy users in Gmail--for example, a secretary logging in to manage the e-mail and calendar of his or her boss--but I suspect Google is working on that. I'd also look into how recurring appointments are handled.

However, given how the costs of Exchange can add up (hardware, Exchange Server license(s), Client Access Licenses, and trained staff to manage it all), using Google Apps to cut e-mail costs can be attractive to enterprises looking to cut IT costs without disrupting their users' Office world. And while Microsoft offers Hosted Exchange, from what clients have told me you end up paying Microsoft more for less e-mail storage.

Finally, this is really how Google Apps is being used in many large organizations (read "large universities"). Universities always roll out the Gmail portion of the solution, but sometimes get resistance on the apps part (Docs, Spreadsheets, Presentations) since they're less functional than their Microsoft Office counterparts. While I hear complaints about the apps, Gmail is almost never mentioned. And if it is, it's the user interface portion. Using Gmail as the backend to Microsoft Outlook fixes that problem.

So rather than thinking about Google Apps as a combo Office/SharePoint/collaboration wannabe, adjust your viewpoint and think of it as an e-mail server. With that in mind, Google Apps may make sense for your enterprise.