Actually, calling what I did “surfing” is generous. It could more accurately be described as a rapid transition from lying prone on a piece of polyurethane foam to swimming in the Pacific Ocean.

Even with this minimal, and quite unimpressive experience, there’s an immediate lesson you learn about surfing. It requires the combined ability to read the conditions with a mastery of timing. First you have to be positioned correctly for the break. Then you have to set out at the right time. Fall behind and you miss the wave. Get too far out front and you’ll be dumped.

If you see an analogy approaching you’re right.

I am personally of the view that with Wave, Google is paddling furiously for a break that isn’t there. Sure, there’s a swell developing – but it’s still a couple miles offshore.

Why am I so hesitant? It’s not for lack of respect for the vision and engineering achievement of the Google Wave team. Instead, it’s based on personal experience.

Back in the mid-90′s I was a regional product manager for Novell GroupWise. 15 years ago GroupWise was a pretty cutting edge application outside of the mainframe world. But while we were pushing the concept of a universal inbox it became rapidly apparent that people were not using the integrated time management capabilities.

What electronic calendar power users quickly realized in 1995 was that the feature was useless unless everyone else used it too. Without near universal participation, busy searches yielded false availability results. Even with a clear solution to a problem that bothered everyone we still ended up calling around on the phone so that everyone invited to a meeting could check their paper diary.

The electronic calendaring phenomena is something I looked at in some detail in a research report I wrote titled “Corporate Social Systems: The History of Electronic Calendars Offers Key Adoptions Insights” (a Gartner subscription is required). One of the findings was that it took 5-7 years after the widespread availability of electronic calendars for it to become broadly adopted. It was only through the confluence of a number of external factors that electronic calendars transitioned from being an unused feature in an email program to being a mandated corporate social courtesy.

I can see with Google Wave a number of such electronic calendar scenarios. At a minimum, people will need to grok onto the concept of threaded interactions in a single, multi-dimensional environment rather than specific collaboration patterns each being represented as it’s own discrete application. In the real world, outside of conferences attended by software engineers, people don’t just change the way they interact with one another because I think there’s a cooler way of doing something. Like the electronic calendaring situation a decade and a half ago, just because I can see how I can apply Google Wave to my collaborative requirements doesn’t mean I can get other people to buy into the same approach.

The inertia of the status quo is a very real impediment to Wave’s success. It reminds me of a meeting I had a couple of years ago with the CIO of a law firm who spent an hour elaborating on their highly successful document management implementation. When two of the firm’s partners showed up they made it clear that they avoided the document management system at all costs choosing instead to send files around as email attachments. While the IT guy could grasp the concept and value of centralized document storage with check-in, and check-out capabilities the actual users saw the sharing of documents of being a simple matter of distribution. That job, as they saw it, worked best in email.

Nor is it just the new collaboration paradigm that Google Wave represents. Working within the environment will require a whole new set of social norms, the lack of which can create frustration that will drive users right back to the tools they’re already comfortable with. For example, concurrent editing is very sexy but it seems to me this can become an unwieldy free-for-all without an agreement by everyone to abide by some type of sequential contribution rule. Playback? I love it. But will some content additions in wavelet’s require commenting in order for there to be a meaningful context for playback? Is there the potential for Wave proliferation to the point where it creates digital clutter? All of these, and many more, will need to be resolved, agreed upon and broadly propagated.

There’s one other comparison with electronic calendars that I think is critical here. There is a lot of talk about Google’s ability to permeate the enterprise through the user. But it doesn’t always work in that direction.

How many of us actually carry around a paper-based diary any more? More to the point, how many of us in knowledge work type of roles can unilaterally avoid maintaining our calendar electronically? Not many I’m guessing. But while the electronic calendar has largely become a mandated corporate courtesy it has not become a mandated personal courtesy. With all the buzz around social software like Facebook, YouTube, and Twitter we can often forget that some types of collaboration tools are mostly of value in a work setting.

If that’s the case then Google has some additional hurdles they’ll need to jump based on their current ability to execute in the enterprise market. This is a point my colleague Tom Austin makes in his observation of Wave.

Let me finish on an observation that Google’s own Lars Rasmussen made. He pointed out that email, an application built on the paradigm of traditional mail, actually emerged over 40 years ago. What that means is that it took roughly 30 years before email was broadly embraced. While I am greatly impressed with what the Google team has put together I think we all need to entertain the very real possibility that it could be another couple of decades before the impact of what they’re proposing will be realized.

“Microsoft’s patent application describes how it could sell software functions to users – they need not buy “the whole application” – and the users could pay by the function and how much they used the function. This would give the user the chance to only pay for what they used. So, I’ll conjecture that one might have to only pay $0.10 to use an Excel pivot table (or $0.01 to use a simple date series calculator) one time.”

First off, I am in complete agreement that there is a trend towards delivering discrete function points via a specific URL, as Google has been doing for years. But I think there are significant dangers for traditional software vendors to assume they can decompose an application into specific, pay-as-you-use functions. The problem is open source.

An oft-stated objection to open source projects is that they don’t match proprietary software in functional parity. Oracle, for example, would argue that a significant problem with mySQL is that it simply can’t do as much as Oracle 11g. They believe that this is a major reason why organizations pay the premium for their product. The same argument has also been applied to Windows over Linux, Office over OpenOffice, Exchange over Zimbra, Siebel over SugarCRM, SAP over Compiere, etc. etc. etc.

I’m not about to validate this view – there’s a lot more nuance to functional fit then the sheer number of features in a product. But if these vendors think that they can re-purpose their products as function-specific cloud services then they need to realize that they’re destroying a fundamental defence they have against open source competition. Should Microsoft want to deliver an Excel Pivot table feature for $0.10 they can rest assured there will be an equivalent open source cloud service for $0.00. By granularizing the features they reduce the programming effort needed to create competitive open source alternatives.

Tom also points out:

Someone could establish themselves as “the distribution point” for software (think iTunes for the universe, not just iPhones and iPods and other Apple gear).

And this is the crux of the challenge for traditional software providers. Excel, Word, Office, Oracle 11g, SAP 2007 – all of these are simply packaging constructs. They are the distribution points for an arbitrarily defined set of functional capabilities.

That’s why traditional software vendors are caught between a rock and a hard place. They have no choice but to embrace the cloud. But they can’t do it in a way that undermines the very packaging constructs that function as lucrative distribution points. However they leverage the cloud they have no choice but to maintain their functional herding instinct. If they let individual features start wandering off as unique services they will get happily picked off by hungry competitors whose business models and cash flows have been built in the cloud.

But the more Microsoft addresses the technology underpinning their cloud efforts the more pressing the questions on their cloud economics come into play. Technology determines what can be done but ultimately it’s the economics that provide the reasons to do it. The closest Microsoft came to providing some insight on the topic was Ray Ozzie’s assurance that Microsoft Azure would be “priced competitively.”

It’s important to note that there are two dimensions to a competitive cloud price. The obvious one is its relationship to direct external competition. But the less obvious aspect is the indirect relationship it has with the on-premise products also provided by the organization. The challenge is how to aggressively compete in the the first area without creating a competition distinction in the second.

Microsoft Dynamics CRM Online is a good example of where Microsoft would like to be on this spectrum. At $59 per user, per month, for their Professional Plus version they’re posing some serious competitive pricing pressure on the likes of salesforce.com, RightNow Technologies and Siebel CRM On Demand. At the same time, pricing is roughly equivalent to what you’d be paying for the on-premise version. From the users standpoint there is no on-premise or Online penalty. And that certainly helps those users considering contextually blending the two different approaches – exactly what Microsoft wants to see in a Software + Services model. Achieving the same dynamics (no pun intended) across the portfolio will not be as easy for Microsoft.

Pricing aside, the most significant component of Microsoft’s cloud economics that still need to be detailed are their service level agreements. Pricing, ultimately, has to relate to service levels and hopefully they will significantly increase the current market standards. Just as important, if not more so, these service levels have to be designed in a way that doesn’t complicate their developer community’s ability to create their own meaningful and competitive service levels agreements to their customers.

Microsoft Azure is a proof point that Microsoft’s engineers are capable of building their cloud. Next time around we need to see whether their product managers are up to the task.

Something that I found to be particularly noteworthy was that only 20% of their consultants are technology-related. The other 80% are actually trained in sociology and anthropology. The blend of their staff skill sets are driven from two factors. First, from HeadShift’s experience, training and development departments are the driving force behind many corporate social software projects. These people don’t think in the context of technology and product – they think in the context of human behaviour.

Second – and I hope we all know this by now – the challenge with social software is not sourcing and deployment but uptake and momentum. Sociological and anthropological skills are much more valuable in figuring out how to address those challenges.

So, IT departments take note. If you’re becoming serious about adopting social software you’re going to have to get serious about tapping into a more diverse set of skills then is commonly found in most organizations like your own.