Presence is the foundational element of unified communications. It provides visual indication of user-set status in a few basic states--on-line, off-line, away or busy. More robust or "rich presence" can aggregate and provide information about availability, location, skills, roles and other attributes. From these sets of information, users and/or business process software can determine whether and how best to contact individuals or members of skill groups, to find the "right" resource in the most efficient way.
Presence servers aggregate and publish availability information, while incorporating constraints imposed by policies, preferences, privacy concerns and security issues. Because presence will provide core functionality in emerging UC applications, many suppliers want to "own" and control the presence server. That's caused some jockeying for supremacy, along with claims and counterclaims of: "We're more open than you are!"
Innovative presence products and ideas are emerging from Avaya, Cisco, IBM, Jabber, Microsoft, Siemens and many other suppliers. Software and mobility providers are joining in as they see expanding application opportunities to provide or access presence information. Each enterprise, and its employees and value-chain partners, will have different sources of and uses for this data. And it's clear that presence will need to span a multi-vendor environment, even before companies extend UC connectivity to partners or customers. Therefore, federation, the term for this exchanging of presence information, is essential.
Federation standards have to be open, robust and fully bi-directional. While some standards initiatives are already underway (e.g., SIP/SIMPLE, XMPP), these cover only the basics, they have yet to be fully adopted and they rely on suppliers to agree to provide the underlying data. It's tempting for Supplier X to provide basic information to Supplier Y's applications, and more complete information to its own. But that approach will stifle the innovative development that can bring transformative business changes, and inhibit UC from reaching its full potential.
At the VoiceCon Orlando session called Software-based Architectures and Unified Communications, Jim Burton, my colleague and co-founder of UCStrategies.com, brought up the subject of presence interoperability to a panel of suppliers. During the ensuing discussion, Jim asked the "Are you open?" question. Eric Swift, of Microsoft, and Pat Galvin, of IBM, engaged in some light sparring on the subject, and then Pat challenged Microsoft to join in development of full, standards-based interoperation. Eric Swift accepted the challenge. Jim had them shake hands on this agreement. Then co-moderator and VoiceCon GM, Fred Knight, offered to feature a demonstration of open, fully-featured presence federation at VoiceCon San Francisco 2008 ( November 10-13) and all agreed.
Of course, the devil is in the details. There are many ways that federation will have to work: Between servers in different companies; between servers within the same company; within a network of servers; between enterprise servers and public IM services (e.g., MSN, AOL, Yahoo!); and between servers and other systems that are a source or user of presence data. There are other possible configurations as well.
Each of these has its own wrinkles, and various models can be envisioned: master-slave, peer-to-peer or the use of a neutral third-party service (think, DNS) at least for intercompany federation. And, while the notion of fully open federation sounds appealing, some difficult and critical hurdles need to be overcome--sound technology, scalability, reliability issues, security and privacy concerns among them.
In the aftermath of the handshake on the VoiceCon stage, subsequent discussions have led to an agreement for IBM and Microsoft to start with the easiest configuration--federation between their equipment in an inter-enterprise deployment. Frankly, this won't be much of a stretch, and demonstrating equipment interoperability won't fully solve the issue. Suppliers also have to agree to make available all information across the link. We also need for these or subsequent demos to include a broader spectrum of suppliers.
But, this is an important beginning. The industry can build on this handshake and make open, federated presence a reality.
