Mashing up the client to the cloud

Next week, I'll fulfil a long-running ambition when I attend the Office 2.0 conference for the first time — I'm moderating a panel on Platform as a Service, with speakers from LongJump, Salesforce.com, SuccessFactors and Zoho.

The event is now in its third year and is one of those events that brings together everyone of significance in its field — in this case, the fast-growing category of business applications served from the cloud. Naturally, that makes it a key event in the SaaS calendar, although many of the participants are a little wary of the SaaS label, which they feel is too closely associated with old-school vendors and other players who don't fully 'get' the new cloud paradigm. This is definitely an event where you have to be unambiguously multitenant and cloud-centric — there's no room for hybrids here. Like many of us, be there or be square.

One point on which I personally differ from Office 2.0 orthodoxy, however, is on the matter of client software. Organizer Ismael Ghalimi has walked the talk, having begun using (and documenting his use of) browser-based Office 2.0 applications more than two and a half years ago. His Rules for Office 2.0 are adamant: "No client application other than a web browser ... No files on personal computer ... No browser extension or plugin ..." not even Java or Flash, if they can avoided.

My own take is that many applications work better when they can take advantage of the compute resources of powerful clients, and that cloud-serviced client platforms such as Adobe's AIR, Microsoft Silverlight and Google Gears are the way of the future (albeit with some caveats, which I'll come back to later). I say 'cloud-serviced' because it's important that the software for these client platforms should be managed from the cloud. I'm not advocating a return to the bad old days of leaving users struggling with shrinkwrapped software installs.

But I do think that there are many occasions when users want to be delighted and supported by a client experience that the browser alone simply can't deliver (and sometimes they want or need to work offline, too). I've written about several vendors that exemplify this approach: SlideRocket, Entellium (see disclosure), DreamFactory (see disclosure) and RightNow.

This week, CRM vendor RightNow has brought out a new release of its software and several of the new features impinge on this question of whether smart clients have a role in the Office 2.0 landscape. Mashups are also an important part of this release, and the way RightNow has implemented mashups cast some additional light on the smart client issue.

In several senses, this latest edition of its software is RightNow's Web 2.0 release. The vendor has added a customer portal capability that its customers can use to host conversations with and among their own customers. It includes a design studio and a library of widgets, many of which are there to kickstart mashups with third party resources. Here the emphasis is on openness and of course the ability to reach the widest cross-section of visitors is paramount, so every element of the portal is browser-based. Similarly, the mashups are easy to set up, making the capability as accessible as possible to non-technical marketing and customer service staff who might need to set up or modify these features.

When David Vap, VP of products, was briefing me on this, he used a phrase that I found illuminating. "We're really trying to leverage what this on-demand, in-the-cloud model delivers," he said, "— both formal and informal mashups." An IT professional versed in the ways of SOA might use the alternative phrase 'both governed and ungoverned.' It made me realize that the point of a lot of Web 2.0 mashups is that they're easy to set up and don't need to be managed so they can be largely ungoverned. But there's another type of mashup that's more formal (ie needing to governed to ensure that it complies with certain requirements), and this is the type of mashup that we see a lot in the enterprise and business applications space — the 'enterprise mashup' that I highlighted last week.

A case in point of these more formal mashups is another new feature in RightNow's latest release: a co-browsing option that allows customer service agents to offer to co-browse a caller's screen so that they can more quickly resolve a problem. This capability is operated by a third-party service that RightNow has white-labelled and embedded within its application. Naturally, there are SLAs and other agreements that govern that integration so it's a clear example of a formal mashup.

Now of course co-browsing requires a download to the caller's machine (which the caller must grant permission for, either as read-only or as read/write, depending on the extent of help required). On the customer service agent's machine, it's even more embedded, running inside RightNow's smart client. And here's the point that I found especially interesting about the way it's architected: the smart client interacts directly with the third party provider's infrastructure to perform the co-browsing rather than going via RightNow's servers. Why would you need that extra hop, after all? Here I feel is a useful illustration of why it's sometimes valuable to run some code on the client, making it act in effect as an extension of your cloud infrastructure.

Taking this further, RightNow is using some Microsoft technology called the .Net Add-in Framework that makes this principle extensible. The Framework allows RightNow's customers or partners to extend their own implementations of the client with additional components. They then upload those components to RightNow's servers. and RightNow's infrastructure manages the process of downloading and maintaining the code to the agent desktops. For example, one customer has implemented an order management plug-in for the client that brings in functionality from DemandWare. So the integration happens at the presentation layer, directly between the client and DemandWare's servers without having to add a hop via RightNow's servers.

You would not want to do this sort of thing universally. As I mentioned above, the outward-facing Web 2.0 capabilities of the customer portal need to have the widest possible reach, and therefore they must restrict themselves to the browser. But the client software that runs on the call center agents' desktop is serving a known user base where speed and richness of functionality have far more value than cross-platform compatibility. It's a business role where eliminating those extra hops to the server make a dollars-and-cents difference to the operational efficiency of the business as well as affecting the quality of customer satisfaction.

So the case I'm making here is that, while some client roles value maximum reach and therefore have to restricted to the browser, as per Ismael's rules of Office 2.0, there are other roles where maximum functionality counts for more, and where it's worth paying the penalty of being tied to a single platform.

I understand that a counter-case can be made that putting functionality and code on the client is just a foolish way of storing up management and support nightmares that will fly home to roost sooner or later. Not to mention the drawbacks of getting locked into proprietary platforms, especially when they're owned (horror of horrors) by Microsoft. But maybe there's a middle way that solves those problems through standardization and virtualization, allowing users to have their rich functionality and their platform independence too.

My vision of Office 2.0 says make the client part of the cloud, too, and have a truly distributed architecture that allows edge devices to participate in the network where it makes sense to do so, rather than force them to remain powerless and dependent.