Presence: Challenges in Realizing the Promise
Without inter-vendor agreement and cooperation, presence will not be able to fully support the increasingly sophisticated--and valuable--UC applications that could be available.
Presence has been described as "the dial tone of unified communications." That characterization reflects the key role that presence capabilities play in enabling new UC modalities by helping to convey information about whether and how people are available for interaction. But there are some significant limitations both in how users conceive of presence capabilities, and in how today's offerings support the functionality that will be required in the future.Many people think of presence only as a "buddy list" showing names of colleagues along with an icon indicating availability. The icon selection is generally controlled by the individual, and the information displayed is both limited (as to number of options) and undifferentiated (everyone accessing the presence information sees the same thing). Presence capabilities are available through an enterprise's PBX or desktop supplier (e.g., IBM or Microsoft), public instant messaging services (e.g., AOL, MSN, Google) or through a small but growing list of business applications providers (e.g., Salesforce.com Chatter).
These presence capabilities provide helpful support for enhanced communications between individuals--what we call UC-User. In fact, in many enterprises today, an internal phone call is rarely made without first checking presence status, and frequently by sending a quick IM to verify availability.
While buddy-list presence is a good start, it's just that: A start. As many vendor case studies attest, much more significant business impact and demonstrable ROI comes from embedding new communications capabilities within processes and workflows--what we call UC-Business.
The presence requirements needed to support UC-B will, in many situations, go beyond what's needed for UC-U. Here are a few examples:
* Finding a particular skill will be more important than finding a particular name. And, keeping those skills accurate and up-to-date will be challenging. Today, users update those capabilities in their profiles; in the future, solutions will automatically cull corporate databases and documents for clues to skills.
* Federation between different systems will become critical, as communications are integrated into business processes spanning supply chains or links to customers. The industry is now beginning to enable links between different suppliers' offerings, but progress is slow, spotty and restricted to inter-domain links. There are even more difficult challenges, somewhat surprisingly, when trying to enable intra-domain links.
* Presence status needs to be expanded and also set automatically, based on inputs from devices or software, location-awareness and other sources. Individuals change state too frequently to keep their own status current, and "available" or "busy" are not adequate for more sophisticated UC applications.
* A mechanism for establishing rules and policies needs to be devised. My availability differs depending not only what I am doing, but also who is trying to reach me and why.
* Finally, there are privacy and security issues that complicate sharing presence information, including both internal policies and external regulatory requirements.
Without progress on these issues, many of which require inter-vendor agreement and cooperation, presence will not be able to fully support the increasingly sophisticated--and valuable--UC applications that could be available.
We will be talking about these important issues at VoiceCon Orlando at a session on Wednesday, March 24, at 3:00 PM. Come join me and a panel of leading suppliers as we discuss issues, trends, and the prospects for progress. Write to me at email@example.com or add your comments to the discussion here.Without inter-vendor agreement and cooperation, presence will not be able to fully support the increasingly sophisticated--and valuable--UC applications that could be available.