As communications service providers (CSPs) transform digitally, they are starting to use APIs both to help create partner ecosystems and to develop microservice architectures that decompose business processes into components that can be used and reused to create new services. This strategy requires that they adopt standard application program interfaces (APIs). In this interview, Claus Nielsen, Product Management Director, Neural Technologies, explains why.
MN: CSPs have been trying, largely unsuccessfully, to develop API strategies for some time now. Why is the market now ready for APIs? What has changed?
CN: I think there are two main reasons. First, in the past, operators didn’t really have a way of properly storing data, and the data that they did have – for example, customer location – wasn’t attractive because there were other ways of getting it or it was too costly considering the business value of it. But now that operators have access to lots of data about customer behavior, devices in the network, and in the future IoT services – and now that they are storing that data – it is much cheaper and easier for them to expose it for third-party use.
Secondly, and I think this is the more important reason, as operators advance in their digital transformations, trending towards more agile architectures, they need a standard methodology in decomposing their business processes into individual ‘network’ elements or microservices and re-combining them to create new services. This applies both to third-party services and to the ones that are being created by operators’ own IT teams. To do this you need to have a standard set of open APIs.
MN: And do you think operators are enthusiastically embracing this vision?
CN: They are beginning to. They have always been enthusiastic about making money from APIs, but traditionally they went about it the wrong way because the APIs they had just weren’t attractive. Now that they understand more about APIs and their fundamental importance to microservice architectures that are used by web companies. They are seeing the benefits: faster service creation, faster time to market and better reusability.
Traditionally marketing sat down with IT and said, ‘We have this great idea’. Then IT took away the requirements, worked on them, and came back and said, ‘Is what you want?’. Sometimes it worked and sometimes it didn’t.
Now you have each line of business with their own service-creation tools. IT now becomes the enabler of the ecosystem of service creation. Now, for example, marketing can make use of network resources by SMS communication, and the open APIs become building blocks for creating services much quicker.
MN: What are the biggest challenges in adopting APIs?
CN: The biggest challenge is getting CSPs to adopt standard APIs. In the past you might have had a large operator group creating a central API platform for individual opcos [operating companies]to link into for example, content services or IoT. But because the platform was not built using standard open APIs, when individual opcos came to try to integrate into this central platform, they found that they needed specialized tools to do so. If, instead, they choose to adopt standard APIs across the group, then whatever service-creation tools the opcos have in place become standard plug-and-play elements.
Another example of this is the OASIS TM Forum Catalyst project [OASIS stands for Open APIs for a Vibrant IoT Ecosystem], which we are involved in. As things stand with the IoT today, you can’t get the network effect of IoT applications development, IoT platforms and IoT devices, because they are all using individualized non-standard ways of talking. With open standard APIs, I, as an operator, could have my own mobile apps development team creating my own applications. I could go out and buy any IoT platform that supports these standards-based APIs and then pick and choose from the endless list of IoT devices. It means that I would not be stuck with the siloed end-to-end approach that defines IoT today.
MN: But even if you had global APIs, you as an app developer would still need to go and agree commercial terms with all the operators whose APIs you are using, right?
CN: Yes, that is absolutely right. But maybe you will see global players emerging that sit between the apps developers and the operators specifically acting as a commercial enabler for APIs. Look at roaming, for example. When roaming was first introduced, you had this potential to make global roaming agreements, and then new companies emerged to do financial clearing on behalf of all the operators. You could easily see similar companies going in and doing the same thing with APIs. Maybe it will be the same companies as for roaming. It could be their savior because roaming is dying.
MN: Is there a risk with this open API approach that operators will lose their end-user relationships and simply turn into enablers?
CN: You say it’s a risk, but it’s actually been in the cards for some time now. There are plenty of operators out there who are doing no more than providing data connectivity for a fixed monthly fee, while the services are provided are on top. But if they are to remain relevant they still need to ensure that the data that they collect – or that is collected by third parties – about their customers is exposed in a standard way. This data also helps with the optimization of the network and improvement in customer experience.
MN: Are there any companies from the digital world that telcos should be looking at for inspiration when it comes to APIs?
CN: It’s not easy for operators to look directly at the web industry as a whole and say we should be like them. Their business models are very different. But they should be able to look at web companies and see that adopting an API strategy is how you go about building a network effect. Looking at telecoms operators globally, there is really no one out there today that has the same level of success with the adoption of APIs as internet companies.
MN: So, what does a roadmap look like for the adoption of an open API strategy?
CN: The first thing you need to do is adopt a microservices architecture. If you are not willing to do this or expose yourself to the outside world, then there is no real point of adopting APIs. The second thing is to adopt a standard for APIs. We recommend TM Forum’s approach. Then you need to start thinking about the services you want to create. One area where we can see services, and the adoption of APIs, taking hold fairly quickly is in IoT.
The work in OASIS involves creating a whole range of APIs for IoT, for example, how devices communicate using different protocols. One other interesting TM Forum project is the creation of a microservices lab. This will allow operators who are missing a specific microservice element to emulate that element.