To me WebRTC won’t really be real until top-tier vendors or providers have integrated it into shipping products or services that businesses are actively buying. We seem to be on the cusp of this happening.
When writing about any new communications technology I try to walk a line between cautious optimism and informed incredulity. We've all seen innovations in business communications nurtured by well-meaning engineers, glint in the eye of marketing, embraced by standards bodies, and productized by vendors. Sometimes they go on to become as transformative as they originally promised to be. Sometimes they fail. And sometimes they fall somewhere in the middle – widely utilized, but watered down by compromises or rife with unexpected, or at least unintended, issues.
It's still too early to say how WebRTC will fare. I wince as I write that because WebRTC has been around for at least four years, which is untold ages in Internet years. Much of the speculation about WebRTC's import two years ago – that it could "revolutionize the way business is conducted," "be a weapon for innovative carriers," "be the next iteration of communications" – remains just as speculative today. And many of the same problems the industry was at loggerheads over two years ago – lack of support from major browser developers, the codec conundrum – remain fundamental problems holding back WebRTC today.
It's not that things are at a standstill. There is, after all, an entire WebRTC ecosystem with a lot of developers – big and small – introducing products that incorporate WebRTC to one degree or another. Many of these developers and many of their products belong to a category that I – rather dismissively, I'm afraid – lump together as "enabling technology." It's the underlying infrastructure and development tools, the gateways that connect WebRTC apps to carriers' IMS networks, SDKs that web developers can use to build click-to-call capabilities, plug-ins that shoehorn WebRTC into browsers that don't actually want it.
Enabling technology is, of course, important, but it doesn't really hold my interest. I suppose it's like a new chipset. It might be faster and smaller and more powerful than anything that came before it. But I'm not really interested until it's in a shipping product that people are buying, and even then I'm not as interested in the chipset as I am in the product it powers.
That is to say, to me WebRTC won't really be real until top-tier vendors or providers have integrated it into shipping products or services that businesses are actively buying. We seem to be on the cusp of this happening. Unify says it will incorporate WebRTC into Ansible, the next-gen collaboration software it will release this fall. And Avaya is using it to build as-yet unreleased snap-ins that let contact center agents co-browse with customers.
And then there's SAP
I had a chance meeting with SAP at Genband's recent customer event. WebRTC was a big topic throughout the conference, with the company drawing attention to its Spidr gateway and upcoming Kandy development environment.
SAP used Kandy to embed realtime communications into applications that don't otherwise support it. The first scenario will be enabling field service engineers to communicate with experts back at the office using SAP Cloud for Service. (A dishwasher repairman is the example the SAP folks gave at the Gendband event, or field service agents like the folks who restock vending machines.) The field service app runs on a tablet or smart phone, giving technicians the details of the next assignment ("Go to Brian's place and fix his dishwasher") and showing the location of and directions to the job ("From current location proceed down Main Street ..."). Once on the site, the app can suggest how to make the fix ("Replace the doohickey on the back of the unit") and, via SAP's Visual Enterprise app, can show interactive and instructional 3D diagrams or other material for the technician to look at.
What the field service app does not provide today is a way to determine presence and conduct in-context, real-time communication with dispatchers, supervisors, account reps, experts, or anyone else the technician might need to interact with. This is where WebRTC comes in.
In a future release of the field service app, customers logging in to the SAP Cloud for Service will see that a "Contact an Expert" button has been added to the UI. Tapping it, the field tech will be able to open a communications channel with experts who can assist with whatever task they are performing, all within the application and without needing to switch to a dedicated communication app. The tech will be able to see the presence of specific experts, letting him or her choose who to communicate with. The two can exchange IMs, or initiate a voice or video call. And if the tech's tablet has dual cameras, the tech can show the expert whatever the problem is.
SAP Cloud for Service with the WebRTC-enabled "Contact an Expert" panel to be made available soon
The "Contact an Expert" feature was built using Kandy, which, though still in development and expected to go GA later this year, is available for some Genband partners to use. The software that enables "Contact an Expert" will reside in Kandy, which is also a PaaS environment managed by Genband. This way SAP and its customers do not need to purchase and maintain any of the infrastructure associated with it.
SAP and Genband plan to monetize Cloud for Service's new comms capability by making IM and presence free, but charging customers a premium for voice and video. SAP is looking to incorporate WebRTC in other apps, such as Jam, SAP's collaboration and enterprise social software.
"Contact an Expert," however, is still not generally available to SAP customers. So this stops short of the real-world WebRTC-based products from major enterprise software developers that are necessary to turn WebRTC from a developer's plaything and a marketer's talking point into something that will have real impact in the industry. But assuming SAP and other top-tier developers successfully release their WebRTC-based services and products before long, the WebRTC story could soon become a lot more interesting.
Follow Brian Riggs on Twitter and Google+!
@brian_riggs
Brian Riggs on Google+
