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.
Adopting an API Attitude at Cisco
Long before Cisco acquired Tropo this past May for its communications development platform, the company had APIs on the brain -- the July 2014 launch of its DevNet initiative stands as evidence to that. But even so, the company's mindset around APIs has changed over the last six months.
With DevNet, Cisco has had a group focused on getting developers involved with its existing APIs. The DevNet posture has been, "We've created an API; now how do we make sure a developer is going to be interested in it?" Missing was the API-first understanding, Adam Kalsey, Tropo product manager at Cisco, told me in a recent interview.
"What Cisco hasn't had is the 'let's start from the API' thinking. 'Let's start by thinking about the API, and create a product the developers are going to love,'" he said.
But with Tropo's guidance, that's changed, especially within the Collaboration Technology Group run by SVP and GM Rowan Trollope, who spearheaded the acquisition (and a scheduled keynote speaker for Enterprise Connect 2016). "There's been a shift in thinking, where we're looking at APIs from the perspective of starting from what the developers need rather than starting from what the product team needs to expose as an API," said Kalsey, who I chatted with at last month's IIT Real-Time Communications conference at which he delivered a keynote address on the next wave of cloud communications.
APIs on the Mind
That Cisco tapped Tropo in the first place certainly showed the company's recognition that developers are increasingly interacting with communications products, trying to automate communications and work with real-time communications, Kalsey said. But with its large portfolio of communications products, Cisco's focus historically has largely been on the user and the administrator -- how do I buy, install, and get the products running. And further, how do I to automate that development, and how do I do this from the end-user perspective? With such an approach, the results are small, focused APIs that don't take into account what a developer needs, he added.
The APIs, too, come wrapped in veils of secrecy, Kalsey noted.
If you're evaluating a traditional communications product, you can pour over data sheets and find all sorts of information on what the product does and how to use it. You can usually even get access to it and give it a trial run. "But the APIs are often hidden behind NDAs, and you have to talk to a salesperson or somebody in support who has the magic access to give you a key to use the API. Then you might get a PDF document that is hard to read, hard to follow, and often written, created, and managed by engineers, rather than by people who have a user experience," Kalsey said.
Think about this from the perspective of, say, a desk phone, he suggested.
"You would never let an engineer slap together a new desk phone you're building and ship the thing out without having a designer look at it and think about what the user experience is going to be and how you need to document it and support this down the road. But that's exactly what often happens with APIs."
At Tropo, which launched in 2009 as a project inside Voxeo to further development around API-driven cloud communications, "we came at that with a different approach," said Kalsey, who has been with Tropo from the start and now handles training, documentation, and education for Tropo at Cisco. "We think of the developer as our primary customer and the API as our primary product, which means how we do everything -- development, support, documentation, metering, management -- is about the API."
When you think about the API from the entire ecosystem, Kalsey said you then consider questions such as: How is it going to fit in with the rest of the products? How is it going to fit in with the rest of the APIs the company develops? How are you going to support it? What is it going to look like?
"So just like you have somebody focused on user experience, you need to have somebody focused on what the developer experience is -- and that's everything from how the APIs look and feel to making sure there's consistency between them. If this part of the API works this way, then this part of the API over here behaves in a similar manner," he explained. "You don't want to be surprising the developer. You want to be sure the API behaves in an expected way."
The Enterprise Spin
This developer, by the way, could just as easily be Joe working from his garage for a startup or Jane doing app development within your enterprise. However, enterprise developers will likely have requirements around security, contracts, and billing arrangements that their counterparts working at smaller companies or on one-off projects don't, Kalsey said. With expectations formed in legacy environments, enterprise developers aren't necessarily prone to thinking about getting communications functionality by signing up for a cloud service; selecting the appropriate API, be that for calling a phone number, accepting a phone call, or sending or receiving text messages, for example; and plunking down a credit card for payment. Yet these are all intuitive processes to developers working in more open, less stringent corporate environments.
In fact, if those latter types of developers can't get the communications functionality they need quickly and easily, they'll leave the Tropo site and look elsewhere for their comms APIs, Kalsey said. Enterprise developers, on the other hand, are looking beyond the quick grab. They expect enterprise-grade service and support -- and they'll get it from Cisco, he added, noting that he considers Cisco's Tropo support a competitive advantage.
"We provide 24/7 support staffed by people who know how to develop applications. You can ask a question about a complex programming problem at 2 a.m. on Christmas, and you'll have an answer very, very quickly rather than the two to three days you'll see with a lot of companies," Kalsey said. "Our philosophy is, somebody is asking us a development question because they have a problem right now -- they're stuck, they're blocked, they can't continue with their project. We need to answer them quickly."
Other advantages Cisco brings to the enterprise developer are global reach and availability of phone numbers in "dozens and dozens" of countries; depth of features, with speech recognition and text-to-speech conversion in about 75 languages being two prime examples; and its cloud hosting model.
If you're changing your own mindset about communications APIs, be sure to join us at Enterprise Connect 2016, March 7 to 10, in Orlando, Fla. We've just added a Communications API track, which will feature introductory and demo sessions, plus more.