Un-Unified Communications
Un-Unified Messaging
Last week I wrote about OCS at the UCStrategies site (Microsoft’s OCS Rides Its Own Wave) which discussed the proprietary nature of OCS, I wrote:
“Active Directory and Exchange are not optional components with OCS. By committing to OCS for voice, the user is committing to network security and messaging standards. Is there any other UC solution that mandates the messaging solution? Microsoft positions this as infrastructure organizations already have, but that isn’t the same as infrastructure organizations will always want. Voice solutions tend to last a minimum of five years, longer than IT server life cycles. Even worse, with “Wave 14″ (AKA version 3), Microsoft is now recommending dedicated Exchange servers for voice and email – (un-unified messaging).”
For the past decade, voice mail systems and email systems have been trying to figure out the best solution for unity, which more often than not meant separate servers and duplicated/shared messages. Microsoft was pretty savvy with OCS to position Exchange as a single messaging server – true unity. Would’ve been a great strategy if voice wasn’t so darn picky about real time resources. With “Wave 14” (nomenclature reminds me of the “K Car” from Chrysler), Microsoft is introducing speech to text capabilities. Like so many OCS features this spawns a requirement for new servers. But upon reflection, “Un Unified Messaging” was not a fair shot. The unified part represented the intended user experience, not the number of servers.
And that brings me to “Unified Communications”. The term I love to hate. I’ve written several times about the ambiguity of Unified Communications:
March 2010: The Emperor Has No UC
Dec 2008: Unified Communications, Yeah Right
UC brings together telephony, email, presence, conferencing, mobility, instant messaging, content sharing, and other communication (custom?) solutions. Most of these didn’t exist twenty years ago. As new methods of communication gained popularity, the communications puzzle got harder. The problem is unified communications today represents strategies to include, not unify disparate communication modalities.
Interoperability: The next big thing?
There are two mega-challenges to real unified communications:
- The customer experience between modalities: Return a call with an IM, Reply to an email with an SMS. First making the communications seamless, and secondly properly logging it in a searchable format.
- Vendor Interoperability: Step one is a challenge today with a single vendor solution, but single vendor solutions aren’t cutting it in UC. The model of a vendor creating a solution and tossing it out to the standards bodies in an attempt to get everyone to follow suit isn’t working either, nor is the API with reduced capabilities game going to deliver interoperable UC.
The first point is evolution – progress is being made. Step 2 is delayed for two reasons: the industry is moving faster than the standards bodies, and the vendors (in general) are reluctant to embrace competitors. There are always a few glimmers of light. Consider the Polycom Open Collaboration Network which embraces standards for interoperability. “standards based solutions, solutions that are scalable, flexible, multi-network, and able to run in mixed environments”. Polycom is in a unique position to pull this off as most of its relationships are partnerships rather than competitive.
Standards based solutions are always preferable, but the UC space is changing too quickly for overall standards. Some standards are just too weak. SIP is smack in the center of UC – and it has a terrible record for interoperability. SIP actually specifies five ways to place a call on hold – no wonder two SIP compliant vendors can’t inter-operate. Standards can’t keep up with either the rate of innovation in UC or the increasing demands from customers. Vendor interoperability is going to require more innovation and cooperation where standards leave gaps.
Anecdote Time:
New York Times Consumer Tech Columnist, David Pogue, recently did several pieces on the Apple iPad. Right after the launch, he did a “town-hall” interactive video were he fielded a variety of questions from 20 two-way video participants. Assuming you don’t have an Apple portable device, you can watch the video here in (Adobe Flash). The video is an impressive use of technology – inspiring really. Except it was totally fake. Pogue writes about how he pulled it off here. Basically, each of the 20 “participants” were pre-recorded videos his readers submitted. It wasn’t a town-hall interactive meeting, it was Pogue talking to 20 videos of people performing a part that he scripted. He faked it because the technology inexplicably isn’t here.
Why isn’t it here? Webcams are readily available. Broadband networks are commonplace. Such technology could be implemented within a closed system – but a 20 user town-hall experience with unaffiliated consumers is still science fiction due to interoperability constraints.
Standards won’t get us there. Standards bodies look at technology through a rear-view mirror. It is going to take a stronger proactive approach to interoperability – to fill-in the gaps where standards don’t exist. And there are no shortage of those gaps in the UC space. Single-vendor UC gardens should be by overall choice – not because one product/solution was selected. The equation is even more complex as cloud options become more compelling. How to create a unified communications solutions among different vendors, clients/servers, and cloud services.
