UC is a concept that harmonizes the multiple communications conduits used by people, including and especially workers. Ideally, it should provide a flexible way of creating a communications connection (call or message) that's consistent across the range of possible devices or software clients that support the interchange. It might even let you cross between delivery systems, like FMC would with voice, or like SMS-to-IM, or either of these to email.UCC adds collaboration, so its proponents say. But if the goal of UC is to harmonize communication, then why wouldn't it already include "collaboration," which is a communications exchange, after all? If we leave the marketing hype aside, the answer is in how you integrate communications services into your enterprise.
In a lot of ways, UC is a kind of desk organizer. You've got paper clips, pens, and other stuff that would normally spread around and get in the way of effective operations, and so you get this handy gadget to keep them in a structured context. The individual tools don't change much, but how you get at them does. If this sounds trivial, it might be worth recognizing that UC adoption to date isn't validating an earth-shaking set of benefits. Maybe the analogy isn't as negative as it might seem.
Is that just a different-colored paper clip in our organizer? The answer depends on whether how we collaborate and how we communicate are fundamentally different.
Collaboration and communication are different. Communication is an exchange of information, and collaboration is a sharing of and cooperation in mission and practices. According to users themselves, collaboration is most often built around IT resources--applications. In 2008, 47% of enterprises I surveyed said this, while only 31% said that collaboration was built on network services. Not only that, as enterprises have matured in their views of collaboration, more have cited applications as the collaborative focus point.
Application-centered UC means that you have to start your communications process by creating a shared work context, a set of synchronized virtual desktops, for example. From this sharing, you then begin some form of human communication to organize your cooperation in working with the applications or data you're sharing. Thus, UCC really needs to be built around a virtual desktop instead of being built around some set of communications devices.
The virtual desktop issue isn't just a matter of being able to share application context with somebody else by letting the two of you create the same picture of the same applications, either. Collaboration based on communications has to imply that the workers aren't all in the same place, and often the reason is that one or more aren't in their normal place, at their normal desktop system. This implies that UCC has to be better able to support mobility. You may also need to schedule interactions more carefully to assure a team can be assembled, and that involves scheduling and presence.
Sharing application context also means being able to create a link to a context, in effect, and sending that link to someone the way you'd send a URL. If I want to collaborate with a co-worker about something specific, there's a decent chance that I would have the specific thing I wanted to collaborate on in front of me when I made the decision. I need to be able to paste that link into a collaboration invitation and send it, so my partner can simply click and establish that same view of the data. This function also supports the possibility that the parties won't be able to collaborate immediately; they can exchange links and both restore context at the time they can really "meet" in a virtual sense.
As significant as building UCC around a virtual desktop may be, the most significant difference between UC and UCC isn't application context, it's social context. How in the world can we presume to support collaboration as a concept on a communications framework that recognizes no relationships, no "social framework?" The fact is that our communications in general, but our collaboration in particular, is really mediated by a set of social rules. The more intimately we attempt to communicate, meaning the more context (visual or otherwise) we share, the more we depend on the social mediation of the process.
Social networks' popularity can surely be attributed in large part to a fad-hungry culture, but behind every fad is an unformed need, a fundamental human characteristic that's being activated. I think that social networks have imperfectly tapped into the need for social context in communications, and I think that social context will have to be the underpinning of UCC.
The final issue in all of this is the issue of organization or architecture. The more "universal" the scope and application of communications is within an enterprise or a culture, the more critical it is that the communications be based on components that can be organized and reused to create efficient and flexible service structures. One of the unstated or understated value propositions for the Enterprise Architecture (EA) initiatives now becoming popular with IT is their ability to frame the relationship between workers and tools in terms of reusable service components. That makes the structures flexible enough to accommodate the changes that we'll surely see.
UCC and UC are both steps away from discrete communications or technology-limited interactions like voice calling. Looking at how they differ offers us a lesson in how to support where all human interactions must eventually go-which is to a very dynamic and variable future. Our approaches have to match that with flexibility.
