No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Is Cisco Announcing a "Jabber Cloud"?

Cisco just made a major upgrade to its Jabber client to let it participate in a broader set of collaborative activities. They also announced they were making it work with virtual desktops and third-party browser-based interfaces and appliances. On the surface, this seems like both a general push at the UC area and an example of Cisco's never-ending desire to make everyone into a video-collaborating machine. But is there something under the surface?

I think it's interesting that Cisco talks about "virtual desktop" and "third-party thin clients" in the same sentence. Why? Because a virtual desktop is a cloud-hosted PC, and because thin clients are linked to cloud-hosted virtual applications. And because I think Cisco may be thinking about pulling these two things together.

If we had to think of an ideal model for UC in a BYOD-and-cloud world, I think it's clear that model would be a combination of a hosted UC process inside the cloud linked to a device-specific agent. All of the intelligence of the application would be concentrated inside the cloud process; all of the communications pathways for this particular user would terminate there. The UC process would be always-on, always-connected, always-ready because it's in the network and not roaming around out there in the disorderly world. The user would simply connect to that UC process through whatever device was convenient.

The approach would sure simplify the BYOD problem, at least for collaboration, and it might also introduce a way for applications in the data center or cloud to connect with devices of all sorts. While collaboration might drive the approach, a truly flexible architecture might well become a framework for cloud-device relationships in general.

The question this model raises is just what the relationship between the UC process and the agent appliance would look like. There seem to be three choices.

* Model One is from VDI; we have what's in effect a virtual GUI linked to a virtual PC.

* Model Two is the one that Mozilla is proposing with its Firefox OS--a phone becomes an extended browser platform, an HTML5 client that can draw on some local scripts but depends mostly on external services that reside in the cloud. "Featurephones" can also work this way, allowing operators to offer additional features to these lower-end devices without the user needing to upgrade to a smartphone.

* Finally, with Model Three, we might see a truly cooperative model where the user's device and the hosted UC process cooperate with each other almost like a form of distributed computing.

Here's an example of how the process would work for any of the three examples above, and how it would differ among the three as things proceed: Suppose a UC user is invited to a conference, be it audio, video, web, or some combination of these. The initial contact is really with the hosted UC process, which presumably would then apply policy filters to determine--based on the location and device capabilities of the user, presence, and other factors--whether to even signal the user for the invitation. Assuming that signal is made, the user could still reject it, but let's say that the user accepts. This is where the three models would diverge.

Next page: The 3 models in action

In Model One (basically VDI), the UC process creates the visual image of the conference internally and simply sends it to the user's selected device, which might well be as dumb as a stump.

In Model Two, akin to Firefox OS, the user's device could supply some intelligence--in formatting or reformatting, for example--and the UC process could invoke that intelligence to perhaps create a better conference display or reduce bandwidth consumed in linking the conference to the user. Security and compliance could even be hosted within the end user device.

In Model Three, the UC process might best be considered as being hosted in a cloud that extends its boundary all the way out to the device.

Gee, it seems hard to pick which model is best, right? I think that's one of the challenges.

UC itself is morphing under a combination of pressures. Technology is changing the power and capabilities of mobile devices and is shifting workers away from a fixed place of work. Mobile practices, particularly texting, are shifting users away from voice calls, and that makes it harder to validate a pairwise video collaboration model; why use video when you don't even want to talk? Applications are becoming more collaboration-focused, meaning that any kind of knowledge work, from programming to document development, is now supported by tools that allow multiple simultaneous users, and also often include some form of real-time (simultaneous) parallel communication among the users.

Perhaps we should be thinking not of which approach is best but of how to support them all. Arguably we could do this with a single step--expand our notion of "the cloud" to include the devices in the users' hands. The resource pool of the future includes...US! Our devices can contribute anything from their own compute power to information about their location, motion, and social context. If that's the case, then we can visualize the UC application of the future as a set of components selected dynamically, based on what we are using and what and who is trying to work with us.

This seems to me to be a good approach, but the question is whether Cisco (or anyone) is really following it. Yes, Jabber with XMPP seems a decent protocol to use to mediate collaborative communications flows, but I don't think anyone is proposing it as a general model for inter-element communication within the cloud. Thus, if we presume that the future cloud envelops even mobile devices in its "resource pool" we'd need another set of APIs or protocols to support that model. That could be the "platform-as-a-service" or "virtual cloud operating system" on which applications of the future would be built.

Does Cisco see this? Here's a network company who says it wants to be an IT leader. Could a concept like this give Cisco a real path to that goal and not just some neat talking points for Wall Street? I think it could, and since it seems 2013 will be the year of transition to the cloud model of the future, we're likely to find out soon whether Cisco sees that too.