This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Oracle/Acme and the UC Golden Age
Oracle's purchase of Acme Packet is seen by a lot of people in the industry and on the Street as transformational for the UC space. Here's a giant software player, somebody with roots in telecom and the enterprise, someone who owns Java, buying a SIP/SBC player. Does this mean that the Golden Age of UC is finally here? Should we break out the garland?
Well, hold off a bit. Aside from the fact that there are many things that Oracle could be looking for in Acme besides UC, there's the bigger question of whether the acquisition will move the ball where it matters.
The driver of UC deployment can only be UC benefits, and I think everyone has learned by now that users almost always interact with software and not with equipment. The hardware is just a way of fulfilling service needs expressed by users through what's ultimately going to be an application programming interface (API) that links the user's applications to UC services. Most users don't even know they're using SIP, much less SBCs.
Acme Packet has APIs, but they're APIs designed to control and configure an SBC (they're SOA/SOAP APIs, not web APIs). Given that this is way below the level of user services, Oracle doesn't get any new assets in the battle for benefits to justify UC deployment.
End-user APIs for communications applications have traditionally revolved around Microsoft's TAPI in various forms. Today, the API focus at Microsoft is shifting toward the Microsoft Lync SDK APIs, a shift that's likely to accelerate as Microsoft integrates Skype and Lync fully. However, other UC vendors are promoting their own APIs as vendors look for differentiation, and also to lock developers into their own products by making UC software non-portable. Cisco and IBM have increasingly expanded and specialized their own approaches to UC APIs, and Oracle has a range of calendar, call, and messaging APIs that expose UC services to users. Acme adds nothing there.
Which is why I'm suggesting that this may or may not be an indicator of a new age of UC. Oracle can't drive UC benefits with Acme, but it could drive UC profits. The hardest sell of anything in network services is the sell to the end user, because there are so many of them and they're so hard to sell and support. So if you're a vendor like Oracle who is committed to pushing user-level UC products with APIs useful to real application developers, you're doing all the heavy lifting. Given that a commitment to UC is likely a commitment to SIP and SBCs, why not sell those things too and keep more of the money you've worked so hard to unlock? And why do the deal now if you don't think that UC growth might in fact be coming?
That's the key point in the Oracle/Acme deal, I think. Oracle must believe that UC market growth now justifies making a big acquisition to increase the revenue it can expect from UC deals it can drive. What better reason to think UC is going to take off than that you're planning to try to make that happen?
This is what fuels the interest on the Street in further M&A in the SBC and SIP space. Their theory is that if Oracle plans to raise the UC tide it will lift all the SBC boats. At the minimum, aggressive UC promotion would likely increase revenue for everyone, at least at first, and if Oracle liked the SBC revenue opportunity, other giants (Cisco is often mentioned) might grab up another SBC player (Sonus is often mentioned). Next thing you know, there's a SBC land rush.
The problem is that this all stands or falls first on the question of Oracle's intent to aggressively promote UC, and second on whether they would be successful enough to take most of the market. And one of the big issues may be that Balkanization of user-level APIs I noted above. Differentiation is a good thing if you're a seller, but in the special world of developer-driven opportunity, differentiation can increase the cost of developing an application for a market like UC. If there are 20 different sets of APIs to play with, you need 20 versions of the program to cover the market.
What Oracle would benefit from, and what the whole of the UC market would benefit from, is a push to create a totally standard set of UC APIs, not down in the bowels of SBC control but at the level where application programs access UC services. That's pretty much what WebRTC targets, and who is a big sponsor of WebRTC? Oracle!
What we may be seeing here is Oracle betting on WebRTC, whose APIs are W3C-based. Yes, I know that WebRTC is "click to call", meaning that discussions have been focused on the browser interface. Yes, I know that some are saying that WebRTC will make SIP irrelevant. Underneath, the reality is that there are native WebRTC APIs and you can use to build that browser click-to-call, but you can also implement SIP calls via these APIs. And who has done that? Acme Packet!
So here's my bet. Oracle thinks that harmonization of UC APIs via WebRTC is going to build a rich UC application development ecosystem that will drive the market. OTT calling isn't going to make Oracle or anyone else money, but linking this WebRTC revolution to SIP could make a lot of money. Oracle buys Acme to get a leg up on WebRTC in the SIP flavor, and to get the SBCs that will be in demand as this takes off.
Smart...maybe. Buying Acme gives Oracle the potential for a WebRTC ecosystem, but they still have to move with skill and aggression to realize that potential. We've declared the Golden Age of UC before, and been disappointed.