But while IBM and Avaya have made strides toward unified communications interoperability, Cisco and Microsoft have fallen short, according to Zeus Kerravala, distinguished research fellow at Yankee Group.
Twelfth century France saw the rise and fall of the professional storyteller -- the jongleur -- who told fascinating stories of knights, princesses, faraway places and people living happily ever after. The jongleurs are long gone, but thanks to Cisco and Microsoft, fairy tales are alive and well.
Cisco and Microsoft love to spin stories about companies that deploy unified communications solutions that interoperate with a huge ecosystem of third-party vendors in an almost plug-and-play manner. This is the way the world will be -- someday.
What makes the UC interoperability story [a] fairy tale is the unwillingness -- or inability -- of some vendors to develop a robust developer ecosystem in which UC is envisioned as a platform ...
But for many companies, someday is too far away. Most organizations want to get started with UC now and start reaping the benefits immediately. That's tough to do in our current environment, because third-party unified communications interoperability is not yet here.
Lack of third-party interoperability focus hampers Cisco, Microsoft
Both Cisco and Microsoft talk a good game about the degree of unified communications interoperability they've achieved, but most of the examples they offer are actually custom-built solutions with specific partners rather than products of a robust developer environment based on standards that anyone can use to build applications.
For example, one of the better integration solutions is a joint Cisco-Microsoft product called Cisco Unified Communications Integration for Microsoft Office Communicator (CUCIMOC). While this helps bridge the gap between Cisco and Microsoft environments, it closes the overall environment to other companies (which is probably part of the plan).
It also raises a major question: If this world of unified communications interoperability and standards-based communications is coming, why did Cisco and Microsoft have to create CUCIMOC? Shouldn't their solutions be able to work together out of the box?
In my opinion, what makes the UC interoperability story more of a jongleur's fairy tale is the unwillingness -- or inability -- of some vendors to develop a robust developer ecosystem in which UC is envisioned as a platform instead of an application. The platform vision is universal across the major solution providers -- Cisco, Microsoft, IBM and Avaya -- but not acted upon by all of them.
Avaya and IBM: Third-party UC interoperability success stories
Avaya has been the most aggressive vendor by far in building a developer environment for third-party independent software vendors (ISVs), as well as working with other vendors to interoperate with their own solutions. As UC developer environments go, Avaya's DevConnect is the gold standard, and the addition of the Agile Communications Environment (ACE) suite from the Nortel acquisition gives Avaya a great platform on which to build.
IBM has been among the more collaborative UC vendors, as well. In fact, the value proposition of its Sametime Unified Telephony (SUT) is built around multivendor solutions. IBM has also been very aggressive in pushing its Unified Communications and Collaboration (UC2) offering into its developer and user community as evidence of the big UC move it made with its annual Lotusphere conference.
The same cannot be said for the two mindshare leaders, Cisco and Microsoft.
Innate issues fuel Cisco's UC interoperability failings
Cisco has been talking for years about building a bigger developer environment. Its latest iteration, the Cisco Developer Network (CDN), has been in the works for years and is supposed to be the program that finally surrounds Cisco with a huge ecosystem of developers. The program hasn't produced any more results than previous iterations, though, and Cisco's developer ecosystem hasn't changed much over the past five years. That's partly because Cisco's UC portfolio is by far the broadest of any UC vendor out there. As a result, Cisco already has much of what a third-party ecosystem would bring to the table.
The other reason -- and this requires a mindset change for Cisco -- is that when a vendor develops a third-party ecosystem around itself, it needs to be willing to take a backseat and let ecosystem partners take the lead. Third-party applications are often developed by vertical specialists that provide an additional layer of business value that UC vendors can't provide. Cisco has been the center of its ecosystem for so long that it's hard to imagine the company accepting a different role.
Microsoft's UC interoperability stumbles: A break from the norm
Microsoft's lack of developer involvement around Office Communications Server (OCS) is a much bigger surprise than Cisco's. While Cisco is operating more or less as it has in the past, Microsoft's success with Windows, Office and Exchange has been based primarily on its ability to create the best developer program the industry has ever seen.
OCS hasn't gone down the same path, however. Microsoft has recently worked to fill out the telephony feature set to bring OCS up to feature parity with the leading IP PBX vendors, but that emphasis might have come at the expense of pushing OCS into its enormous developer community.
Lessons of the past: Fail to work together, prepare to fall apart
One could argue that because Microsoft and Cisco are the two vendors with the biggest mindshare, they don't need to be as aggressive as Avaya and IBM. But I believe the long-term winners in the UC industry will be the solution providers that find a way to capture the minds of the developers. Microsoft snuck up and stole the entire OS industry out from under IBM's nose back in the early 1980s, and the same thing could happen in the UC industry.
If you're evaluating a UC solution right now, the easy decision is to pick Cisco voice over IP (VoIP) and Microsoft on the desktop, but you may find that an alternate provider gives you broader third-party solutions.
About the author:
Zeus Kerravala, distinguished research fellow at Yankee Group, leads the Research Council and is chartered with the responsibility of providing thought leadership to the research organization. He drives the strategic thinking of the research organization and helps shape the research direction. Much of his expertise involves working with customers to solve their business problems through the deployment of infrastructure technology. Before Yankee Group, Kerravala was a senior engineer and technical project manager for Greenwich Technology Partners, vice president of IT for Ferris, Baker Watts, and an engineer and technical project manager for Alex. Brown & Sons.
This was first published in September 2010