Interoperability Emerges As The Key To UCInteroperability Emerges As The Key To UC

Over the last two months or so we've had the opportunity to interview about 100 IT executives from end-user organizations of varying size and scope about their organization's approach to unified communications. We're asking IT executives about their UC plans, experiences, business drivers, and concerns. In most interviews one key concern emerges: Interoperability.

Over the last two months or so we've had the opportunity to interview about 100 IT executives from end-user organizations of varying size and scope about their organization's approach to unified communications. We're asking IT executives about their UC plans, experiences, business drivers, and concerns. In most interviews one key concern emerges: Interoperability.IT executives have told us time and time again that the most frustrating factor they face when crafting a UC strategy is figuring out how to integrate their legacy infrastructure with their emerging applications. It's rare that there is a justifiable business case for replacing large and often not-yet-depreciated PBXs, video conferencing systems, and instant messaging applications with an end-to-end integrated single vendor solution. Rather, IT architects are struggling to create an architecture that provides a unified client experience to the end-user, while integrating applications on the back-end.

Some of the more specific concerns we've heard are around integration of desktop applications such as IM, web conferencing and presence with telephony and video platforms. While almost every vendor claims to have some level of internetworking capability with other leading vendors, as well as support for open standards such as SIP, the reality is that practical integration is difficult. Numerous individuals have told us that when it comes time to actually integrate systems, they are plagued with incompatabilities due to differences in software revisions, hardware, or bugs which have not yet been worked out.

Often we've heard tales of frustrations from those who heard marketing hype about how SIP would solve all their interoperability problems only to find out that SIP is only one piece of the integration puzzle. For example, Microsoft and Cisco both argue that they support SIP for their voice systems, but since Microsoft uses a proprietary codec for voice, calls between Microsoft and Cisco systems must go through a mediation server. One can't use an Avaya SIP phone with a Microsoft call server. We've seen the same reports of incompatibilities between SIP trunking services and IP-PBXs.

As organizations begin to integrate presence among disparate systems a new challenge is emerging - how to share presence information among applications, and perhaps more importantly, how to enable end-users to control distribution of presence information in a multi-vendor, multi-system environment.

It is relatively trivial for someone in a single-vendor architecture to manage their presence; they simply use the desktop application or a web-based management portal to set their presence notification rules, or they use rules and/or policies set by an administrator. Examples include an employee who for whatever reason only wants a small group of people to be able to see his or her status, or someone who wants to set sophisticated rules around call forwarding - e.g. "if a member of my team calls, route the call to my cell phone, otherwise route it to voicemail" or "if my boss calls when I'm in a meeting, activate an IM session, otherwise put the call into voicemail."

Creating these kinds of rules in a multi-vendor environment becomes a challenge that is ultimately governed by "who owns the master presence store?" Today there aren't any solid standards to govern presence policy federation. So if a user sets rules for their telephony system, they may have to set rules for their IM system as well. It becomes even more difficult when the organization needs to federate between IM systems (such as environment where there are both IBM Lotus Sametime and Microsoft LCS/OCS users).

Recently SIP pioneer Jonathan Rosenberg of Cisco and Avshalom Houri of IBM submitted an Internet Draft to the IETF SIMPLE working group to create a framework for presence federation. But adoption of this approach is based on a willingness of vendors to accept a multi-vendor, interoperable presence model where all applications function as equal peers.

Instead, presence is moving to the forefront of the UC battleground, with vendors increasingly operating under the assumption that the vendor that controls the master presence repository will in effect hold the keys to the UC kingdom. Microsoft, Cisco and IBM Lotus have all stake their claim to having their UC platforms serve as the master repository for presence information. Avaya recently teamed with Jabber to deliver the "Intelligent Presence Server", again to fill the role of "master presence repository" for multi-vendor environments.

So far it's rare that we've seen end-user organizations (especially those in the mid-to-large end of the market) that are planning for a single vendor environment, so interoperability concerns, especially around presence, will remain as a major stumbling block to realizing the promise of UC. Vendors would serve their customers well by continuing to remove roadblocks to interoperability rather than creating them.