WebRTC is a very hot technology these days, and at the same time, we're seeing the talk about CEBP (Communications-Enabled Business Processes) heating up. What does all this mean for the enterprise? Fred and I have been talking it all over as we do our planning for the Enterprise Connect Orlando 2013 program, and a few things seem to be coming into focus.
What kind of made this all gel for me this morning was a tweet that Brian Riggs of Current Analysis (and a No Jitter contributor) just sent out:
"@SiemensEnt wants to move its UC software away from thick clients and dealing w/ disparate APIs, toward HTML5 and WebRTC. #SiemensEntAR"
That would be a really interesting development. Up through now, the enterprise communications business, from the vendor standpoint, has relied heavily on the idea of controlling the end user by controlling the endpoint. This was easily accomplished with proprietary telephone signaling protocols in the TDM era; the first generation of IP phones also featured proprietary protocols like Cisco Skinny; and now, even in a SIP world, SIP implementations tend not to be interoperable across vendors.
When SIP first started emerging, we tended to ask whether standardized SIP phones would commoditize the telephone set business and hollow out the 30%-40% of the system purchase price that phones represented. This commoditization never transpired, and though low-end SIP phones have made progress in the market, all the major systems vendors report phone sales continuing to rise each year, even in the face of SIP commoditization and the move to mobility and away from desk phones altogether.
To the extent that enterprises are moving from hard phones to soft phones--and indeed some are--the "softphone" is a proprietary client from the systems vendor, running either on a laptop or a mobile smartphone--your Microsoft Lyncs, your Cisco Jabbers, your Avaya Flares. Now what Brian is suggesting that Siemens is suggesting is: Forget about the proprietary soft client--with WebRTC, which communications-enables Web browsers, the browser can be your enterprise client.
It's an interesting play for a company like Siemens, which is chasing the market leaders and would like to disrupt the current client-server model. If Siemens comes to you and says: You don't have to buy any client licenses from us, just set your users up to point their browsers to a secure website built on OpenScape technology, from which they will get all their communications capabilities--that looks like a pretty interesting deal.
Or does it?
If your goal is to not have to pay for endpoint software licenses, the obvious counter-move for the quasi-incumbents in this space is to give away the clients for free. And guess what? They've already started down that road, with Microsoft including Lync IM/presence in Exchange licensing, and Cisco giving away basic Jabber. They surely don't want to give away the more feature-rich versions of these clients if they can help it, but it's always an option that they can adopt incrementally in response to any slippage they see in market share.
Beyond the pricing issue, there's the general issue of over-the-top-ness (OTT-ness). One of the great benefits that people tout about WebRTC is that you get communications in your browser, and don't need to download an OTT app like Skype. And for enterprise purposes, Jabber, Lync, etc. count as OTT also.
Here on No Jitter, Kevin Kieller, one of our contributors and a Microsoft partner, has expressed a lot of skepticism about WebRTC, touching off a really terrific debate in Comments. His argument is that WebRTC isn't here yet, which is true but won't be true forever. He also doesn't see a lot of difference between the hassle of downloading an OTT app like Skype vs. upgrading your browser, as you periodically have to do. That argument makes a fair amount of sense to me--half a billion Skype users can't be wrong!
Still, the idea of your browser being your enterprise client seems appealing: It'd be a lot less of a burden on the IT staff when it comes to deploying connectivity to new users--presumably you'd push out a URL where they'd go to configure their service; that URL would correspond to a webpage matching the new hire's policy profile, which would be discovered based on directory integration; and the user would then register with the system and have the appropriate permissions when she communicates with the enterprise systems.
Or maybe your corporate PBX goes away altogether? In a WebRTC world, maybe your corporate wiki/intranet is your PBX. All your contacts are there; you can reach them via voice, video, or IM/text. It's just another website, and now every website is two-way multimedia. That may be a little far-fetched right now; companies are pretty invested in legacy telephony-based (and increasingly IM-based) processes.
The other big factor here is CEBP.
Next page: CEBP vs. WebRTC
Even if you believe that WebRTC-enabled browsers can beat "thick" enterprise UC clients in the real world of enterprise communications, these UC clients aren't the only competing option as a communications endpoint. The other big competitor here is the existing business application, with communications functionality integrated via Communications-Enabled Business Processes (CEBP).
Not every employee "lives" in their web browser. Many live in a business application. For many, that application is email, and so the email client already is almost a de facto UC client for many--if you've got OCS or Lync integrated with your Outlook client, you're already seeing the presence indicators and you're able to launch other communications media out of that email client--IM and video today for sure, and if your company goes with Lync PBX, it'll be telephony as well. (Also a similar progression occurs for those with Cisco and Avaya integrated to the back-end of Outlook or IBM Notes).
Alternatively, it might make sense for your users who live in applications like SAP or Oracle to have these applications function as their de facto communications client. That's what Neal Shact argues in this No Jitter post. The communications piece of that integration could be powered by communications capabilities that are part of the application platform, as SAP is doing with its Business Communications Manager, or it can be via an API that integrates SAP, Oracle, etc. with your existing communications platform from Avaya, Cisco, etc.
The CEBP scenario doesn't preclude the WebRTC scenario, of course. In fact, you could argue that the two complement each other and, together constitute a compelling argument against the standalone UC client. You communications-enable your main business apps and that's the interface that those users avail themselves of; while those who would, in the past, have been telephone-based workers, eventually find themselves migrating to WebRTC-enabled browsers for generic multimedia communications.
In any case, if CEBP catches on, it's possible that WebRTC-based browsers wind up battling with dedicated UC clients for this diminished slice of the enterprise endpoint pie. Maybe the thick UC clients become niche, high-end products for workers with enhanced needs. Or maybe UC clients prevail in the mobile world but lose on the desktop PC--after all, the app download model has won the smartphone battle over the browser so far.
Then again, maybe WebRTC never does garner the support it needs from Apple and Microsoft to become a truly interoperable, universal standard, and none of this transpires. Maybe we all just keep using email as our main client, and whatever integrates with that is good enough.
Regardless, it seems certain that at least some of the enterprise communications systems vendors will have WebRTC as a check-box on their systems going forward, just like Lotus had to come out with Domino to complement Notes back when the Web first started. This is definitely an issue you can expect to see us address at Orlando next March.
