UC Needs InteroperabilityUC Needs Interoperability

Interoperability, in the sense of full feature/function transparency or interchangeable parts, however, remains an unfulfilled goal.

They say everyone wants to get to heaven, but nobody wants to die. Our industry seems to be similarly conflicted about interoperability; everyone's for it, until it's time to put money on the table.Enterprises are not immune from this wink-wink, nod-nod attitude. Buyers claim to want interoperability in order to lessen their dependence on a single vendor, to enable them to assemble "best of breed" solutions and because, theoretically, it should create lower prices.

But enterprises also know that when products from multiple vendors are involved there are some significant downsides: Inventory management becomes more complicated - and expensive, they have to train people - within the IT shop and end users - on a broader assortment of gear, there's more likelihood that integration costs will rise and, without a single neck to grab, problem resolution can quickly devolve into a game of whack-a-mole.

The vendors are keenly aware of these trade-offs and, coupled with their strong resistance to anything they perceive as diminishing their ability to differentiate themselves, has enabled them to successfully avoid making real progress on interoperability for decades.

Net, net: Meaningful pressure to achieve interoperability quickly deflates even as both buyers and sellers swear allegiance to the goal of interoperability.

We re seeing this cycle play out in the SIP space, particularly now that SIP Trunking is becoming more widely available. The SIP standard has almost as many variations and proprietary extensions as there are vendors. As a result, there are interoperability hurdles getting SIP gear from one vendor to work with others, getting on-premises gear to talk to the carrier/service provider network and between carrier networks. Bottom line: SIP interoperability cannot be taken for granted and, not surprisingly, during the SIP sessions at last week's Virtual VoiceCon, a substantial percentage of the questions submitted from attendees focused on interoperability. (If you missed Virtual VoiceCon on June 10, it is available on demand.

Enter UC; the U in UC stands for Unified, which at the very least implies interoperability. To be fair, there has been some progress. For example, some vendors' products can exchange "buddy list" availability information with public IM services. Microsoft and IBM have worked out some aspects of presence federation between OCS and SameTime. And many vendors are doing what they've always done: Publish specifications or create software hooks that let systems from other vendors communicate and interact. Interoperability, in the sense of full feature/function transparency or interchangeable parts, however, remains an unfulfilled goal.

In an email exchange I had with Marty Parker (UniComm Consulting) he noted that most of the UC vendors "...emphasize their ability to interoperate with disparate systems -- e.g. PBX vendors with Exchange or Domino; desktop vendor with PBXs via gateways, etc. -- rather than with peer systems." Marty went on to say that raises the stakes for interoperability even higher, "...since peer interoperation is key to growth and proliferation. Certainly was true for e-mail; certainly was not true for voice mail; and somewhere in-between for PBXs with Q.SIG and now SIP."

Maybe as UC matures and evolves, the historical limits on interoperability will begin to break down. After all, virtually every other dynamic in the communications industry is being radically transformed, so why not this one?Interoperability, in the sense of full feature/function transparency or interchangeable parts, however, remains an unfulfilled goal.