Two competing visions of the endpoint.

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