Most consumers indirectly use application programming interfaces every day, to check weather, make travel arrangements, use social networks or search, make payments or log in to sites using another existing account. Use of Google Maps or shopping provide other examples where APIs are used.
Basically, APIs allow different applications to exchange data.
Connectivity providers now believe they can make revenue, and increase the value of their services, while possibly building bigger ecosystems of value, by exposing network functions as APIs. Value added will determine how successful operators are at unlocking value from exposing network features for use by third parties.
In the internet era, connectivity is essential for almost all applications, use cases and functions. So we should never be surprised that app developers note the value of access to the internet, and connectivity in general. Without internet access, most apps will not work.
But there is a key distinction. Internet access does not hinge on a business relationship between the app and the access or transport networks. By design, any app compliant with TCP/IP, and any user with access to TCP/IP networks, will be able to use internet-supported apps, so long as they have the credentials to do so.
So access providers hope that new network APIs will create a new revenue stream, while possibly increasing the value of network features.
Initially, for example, the GSMA Open Gateway APIs support SIM Swap, Quality on Demand, Device Status (Connected or Roaming Status), Number Verify, Edge Site Selection and Routing, Number Verification (SMS 2FA) and Carrier Billing features such as Check Out and Device Location (Verify Location). Other APIs will be added, of course.
The issue, as with all engineering choices, is whether there are other proxies or substitutes for those sorts of functions. Payments can be made in other ways than using carrier billing. Device location might be available using device or application features.
In other cases, the use of an API might, or might not, be a feature of some other service, such as a network slice. In some cases, quality issues will be rectified by use of edge computing or content delivery networks.
In other words, it remains to be seen whether, and how much, app developers see value in the new APIs, and where value can be created using substitute methods.
APIs have been used to “voice enable” other apps, for example. The hope is that many other network-based parameters or functions likewise can be exposed, with access to those features generating revenue for network operators.
Architecturally, of course, APIs are a way of reintegrating functions that are separated into layers. Also, to the extent that many industries evolve towards ecosystems, APIs add value in allowing ecosystem partners to interoperate.
The issue for connectivity providers is the additional value apps gain when network functions are available to exchange data. Generally speaking, it is application-to-application data that adds the most value.
The thinking is that latency-sensitive functions and apps will benefit most from edge computing, as they have benefitted from content delivery networks. Perhaps such apps also will benefit from network APIs.
Everything hinges on value added. So the big question right now is where value can be generated when network functions are available.
No comments:
Post a Comment