Do communication APIs complement or challenge UC products?
Communication APIs boast a bevy of benefits, but don't expect this newfangled technology to replace unified communications completely.
Organizations and developers can embed communication APIs into existing business applications to streamline communications and workflows. As a cloud-based technology, communication APIs follow the same value proposition as other cloud products. Namely, users ordinarily don't need to worry about infrastructure, carrier connectivity or maintenance support.
Despite their advantages, communication APIs are not going to usurp prepackaged UC products, said Mark Winther, an IDC analyst. Instead, expect APIs to complement, configure and customize existing unified communications services.
On the other hand, Winther added, companies could cap their investments in preconfigured UC systems and use APIs to create customized platforms.
As a nascent technology, some questions hound communication APIs. For instance, are these tools business-grade? Can they support specific business needs, including security, compliance and auditability?
"There are questions about communication APIs," Winther said. The core customer base for APIs has been digital-native firms that wanted to grow quickly and perhaps ignored quality and compliance issues. But in the enterprise world, major banks and government agencies, for example, will think first about these enterprise-grade issues.
In the video above, Winther discussed the relationship between communication APIs and unified communications. He also examined the drawbacks of APIs, their ease of use, cost structure and the "deficit of developers" facing the API world.
Communications APIs are cloud communications. Because it's all a cloud platform, the user doesn't have to worry about infrastructure or carrier connectivity or maintenance support -- just like the cloud value proposition. UC is a finished, ready-for-end-user solution. Communications APIs are raw, primitive elements. They're going to complement. I don't think the world is gonna go all deconstruction and everybody's gonna wanna build their own, so let's get rid of our solutions and build our own from the ground up. I don't think that's gonna happen. On the other hand, I think that companies are probably gonna think about capping their investment in preconfigured solutions, so that they'll use APIs to create the customization on top of them.
There are questions, right? Business-grade is a question about APIs. Are these solutions gonna be sufficient to support what a business needs, a bank, a retailer, a government organization, healthcare firm in terms of security, privacy issues, compliance with government regulations, auditability, just the reliability of it? So, you know, there are questions about communications APIs because their core customer base are digital-native firms that have grown up quickly using APIs, and maybe didn't think about quality, compliance. They thought about how fast they can grow and support that. Now you've got Morgan Stanley or Citibank or a federal government agency, they're gonna think first about these issues of enterprise-grade. And so I think this is where communications platforms have to be able to stand up to that. And I think there's a question, can they do it?
APIs are quite easy to use, but you gotta pull it apart a little bit. I mean, an API is like 20 or 30 lines of code, that's what it is. And anybody's API, it's gonna be the same. So the thing is though, the API is just the beginning; it's the wraparound, the kind of support you get, tutorials, helper libraries, use cases -- that's what you wanna look for, because anybody could have an API, but that's step one. To make it easy to use, to make it efficient for you, you wanna have all those wraparound pieces that show you how to do it.
It's developers who use these, and by developers, I mean web developers, like the guys who're building the website or a mobile app. They can use these communications APIs because they're all in languages they're familiar with to use to build a website. So in fact it's typically not the IT department that's using them, it's gonna be a developer who maybe is working with a marketing group to build their website, or edit it, or refine it, or add new capabilities, or who's working with a line of business to build a mobile app, you know, the airline reservation mobile app. They're gonna have developers work on them. So often, communications APIs are not, it's not the IT department. And the beauty of this though is that their developers, they're simple, so their developers are building websites, and there's millions of them, they're not highly specialized software expertise. And that's why this broadens communications out to a much bigger potential.
Companies are moving more and more toward software and applications, part of this is the digital transformation trend that companies are going through. They wanna create all kinds of self-service tools for their workforce, for their customers, for partners, a lot of that is software development. The problem is there's not enough developers that the IT department can hire to support the demand for all these new software applications. So they need another resource, and that's what we call the citizen developer, somebody who is a simple web developer, these are kids often, still in high school, even, we see them developing these things. But they know these new modern software languages, and that's where your resource is to build these. So it's really important there's what we call a deficit of traditional developer resources, so you gotta develop a different way to broaden your pool of resources.
The business model is very simple, it's a metered usage model. You pay per minute of a voice call, or you pay per message of a text message. It's pay-as-you-go pricing. So it's micro-billed, no contract, no subscription, no minimum, just usage-based pricing. That's its beauty, and therefore it is cheaper than just about any other way you can build a communication solution. Now, where the change is coming in as customers scale, this comes into question. Number one, customers are gonna want a contract. "I'm a big enterprise customer. I'm running 5 million, 10 million minutes a month, give me a contract for this so I have predictability in it. I'm beyond the point where I wanna pay per use and manage my costs, but I need it predictable. So give me a clear contract with deep discounts based on my volume." So I think that's where we are now. We're gonna see more of that, we're also gonna see profiles. I want a pricing for my telehealth application, the way that it works, which means I wanna pay for every patient-physician session. I don't wanna pay by the minute, or by the stream, or by the megabyte. I wanna pay per session because that's the way insurance companies would cover the cost. So we're gonna see more of those kinds of use-case-defined pricing.