These things happen when I have the least amount of time for them.
Why couldn’t they wait until next week? Just when I go on a vacation with the family, I need to halt everything, take out my laptop and sit down to write a post. The news this time? Cisco acquires Tropo.
Tropo is one of the 19 (!) vendors I cover in my WebRTC PaaS report (more will be added later this year).
Planning on selecting a CPaaS vendor? Check out this shortlist of CPaaS vendor selection metrics:
Tropo is also the 5th distinct acquisition in this space:
- TokBox got acquired by Telefonica
- AddLive got acquired by SnapChat – and taken off market
- Crocodile RCS got acquired by Acision – and morphed into Forge
- Requestec got acquired by Blackboard – and taken off market
And now Tropo gets acquired by Cisco.
Zeus Kerravala does a good job on NoJitter to explain what this means to Cisco, I’d like to touch some additional points here.
Why Tropo and no one else?
- If Cisco is serious about developers and APIs, the it should have acquired one of the communication API platform vendors instead of building its own
- The vendors with the largest developer communities around are probably Twilio, Tropo and TokBox
- Twilio is somewhat out of reach – it just raised another $100M with a $1.1B in valuation. Probably more than Cisco would be willing to invest, and at a time when Twilio won’t be willing to sell
- TokBox belongs to Telefonica already
- Tropo was up for grab
- Tropo is playing in the service providers market, where it tries to integrate its APIs right into telcos. This fits well with Cisco’s target customers
- Tropo readied its platform for SDN and NFV – both acronyms are important to Cisco in their own portfolio, and in that regard, Tropo was the only Comms API platform with such a focus
The Challenges ahead for Cisco
In recent years, Tropo has changed focus. My understanding from speaking with a past employee of Tropo, they shifted their focus somewhat, trying to appease service providers (their target customers) instead of their developer community (their suppliers/ecosystem). While I am unsure if that is correct or not, there is little to be said about the breadth and depth of WebRTC capabilities that they have introduced. Their efforts have been spent elsewhere in the past year.
Will Cisco continue with this trend, trying to focus on service providers, large enterprises and its own Spark product integration, or will it try to compete head to head with Twilio and TokBox, trying to gain a leadership position with communication APIs and WebRTC?
It will also be interesting to see what route they take with video support in Tropo. Up until now, video hasn’t been Tropo’s strongest asset, having no real multiparty support to speak of. This places Cisco/Tropo at a cross road:
- Should they support multiparty video by mixing?
- Cisco has considerable know-how and assets in that technology through its Tanberg acquisition, Telepresence systems and many years in the Enterprise Video Conferencing Market
- Tropo partnered in the past with Dialogic to offer similar capabilities to some extent
- It may fit well into large enterprises and Cisco’s current thought processes, but it makes little sense with large scale cloud deployments, consumer services and to some extent WebRTC as a whole
- Should they support multiparty video by routing?
- Routing is what most other WebRTC PaaS vendors end up using
- It is cost effective considering the alternatives
- It is Atlassian’s reason behind acquiring Jitsi
- But it may not fit well with Cisco’s DNA and thought processes
Will they even focus on video?
Will developers be attracted to Tropo or will they look for their solution elsewhere?
Was this acquisition about the technology? Was it about the existing customer base? Was it about the developer ecosystem?
Why is this important?
The communication API space is moving forward. The map of available alternatives is different than what it was a year ago. It will probably change again in a few months.
If you are planning on joining this space, then you need to consider your strategy carefully.
If you are planning on using a communication API vendor for your next service, then finding the most suitable one for your needs require a well thought vendor selection process.
Check out my report (and consulting services). I will be happy to set a call with you to see how I can help you with your strategy or vendor selection.
One of the things that Cisco did very effectively in optical transport in the early 2000s was to push their optical networking gear via enterprises (where they were selling routers) and then sponsor those solutions into carriers (RBOCs and CLECs). This helped drive optical transport sales in areas where they weren’t approved/certified by a number of larger carriers. And eventually, the amount of business and co-marketing that they brought carriers helped those carriers overlook some of the performance issues in the equipment.
Where this deal has some similarity is that Cisco can go to large Enterprise customers and say, “Hey, we can enable X service through using our PaaS that is embedded in Y Carrier’s network.” That drives use of the carrier’s service and revenue for Cisco-Tropo.
The reason for the strategy shift from a developer-based API model to a carrier network-based PaaS was because key ingredients to the developer-API-based resale of SMS/voice minutes are exposed to a supply they don’t control – DIDs and minutes. Plus, it’s a very competitive, commodity, low-margin business. Keep doing what you’re doing, and you’ll keep getting what you’ve got–just a little more of it if you do a good job doing it. Of course, I don’t think they realized that getting an application server in a carrier network is not easy and takes much longer than their “I’ll just write this code tonight and make it work” way of working. I know of at least one casualty along that path.
Their global distribution deal with Ericsson is probably blown up. Their deal with Huawai as well.
Interesting that their WebRTC API, Phono really hasn’t been an area of focus, partially because of the open source nature of WebRTC, the real-world lack of demand (I think WebRTC is in the Gartner Hype Cycle’s Trough of Disillusionment phase) and all of the work they were doing with AT&T (and with E///) where E/// was very protective of the the AT&T WebRTC business (that it was basically giving away). Cisco can help productize WebRTC to Enterprises in a way that Tropo never could–in a way that few companies can today. Because the value of WebRTC to an enterprise lands in IT, Marketing and Operations – Cisco has enough breadth and market savvy to make that possible.
Thanks for the comment Kile. You make a good point. I’d only question the value of voice and SMS versus “OTT” moving forward, and the need for a carrier network.
It will definitely be interesting to see if Cisco/Tropo will win the heart of the enterprise or will Twilio or some other vendor take that role.
it will be interestimg to note how Google vidyo development on webrtc will work in the market as against cisco
I don’t think it matters in the bigger scheme of things. SVC was always interesting and useful, but not a game changer. I don’t believe it is that even today.