Operators have long sought to monetise their networks through the exposure of APIs to enterprises and other third parties. While there have been different approaches to this, in practice, all depend on exposure layers – often dedicated gateways with integrated security processes – that enable different stakeholders to build new applications using network capabilities, which, in turn, can drive revenue streams for the host operator.
Generally, monetisation can be realised either directly (where a charge is applied due to a transaction executed via an API, or an API consumer pays a supplier for access to an invocation of an API), or indirectly (where a consumer pays a supplier for an offering that has APIs bundled as part of the product).
The problem is that, while the industry has held the view that significant value can be accrued from API enablement programmes that enable the capabilities of the core network to be exposed to new applications that deliver added functionality to existing solutions, for more than 20 years, relatively few operators have managed to do so successfully and secure the expected revenue.
Perhaps one reason for this has been that there have been various efforts to introduce standardised approaches – which, perversely, has had the result of introducing delays (wait until the standard has been approved) and friction to the process (who is compliant to the new standard, and how do we prove this?). However, there have been some notable exceptions.
Based on our long experience in this domain – right back to early experiments with Parlay – we’ve learnt a great deal about what succeeds. The truth is that the API is just a tool; it doesn’t matter whether it’s compliant with standard x or y: what matters is that it is supported, documented and protected. Different stakeholders will use APIs in different ways, so they are less concerned with format, than with substance.
As a result, one key ingredient to the API strategy is a range of APIs, not necessarily a single, all-encompassing solution. Sometimes, aiming for unified interface is not the right approach – multiple solutions can deliver what’s required. And that’s what we’ve been doing, for more than a decade.
In many ways, the landscape we’ve described above should come as no surprise. The idea that adding communications capabilities like voice, location, call recording, conferencing and others to enterprise applications (for example, CRM, ERP, etc.) to create new efficiencies and enhance productivity has been understood for some time so the problem hasn’t been one of demand but of meeting it.
Commercial API access can help make leveraging new opportunities a reality when the operator can enable its enterprise customers to innovate and build their own solutions while at the same time unlocking added value in its networks (and encouraging third parties to pick up the mantle of innovation).
However, though the “pull” is there, for enterprise CIOs considering deploying commercial APIs, ensuring that the strategy pays off remains challenging. Realising the full value of technology infrastructures, the problem that API monetisation helps to address, requires a mix of both business and technology inputs.
That’s in part why, as Gartner’s research shows, “at least 84% of companies and 59% of government entities have set up fusion teams — multidisciplinary teams that blend technology and other domain expertise and are often designed to deliver products rather than projects”. As such structures become more common, they will likely be one factor helping to speed the development of the market for and uptake of commercial APIs and API monetisation.
As their enterprise customers evolve, operators have an important role to play in meeting the challenges they face.
So, if API monetisation is your goal – and it should be - what should participants – operators and enterprises alike – keep in mind? Five key considerations have emerged that will likely govern the success of early initiatives. These are:
1 As noted above, business and IT goals must be synchronised. This means identifying where API-based products can deliver value and establishing how outcomes can be quantified. That’s not always straightforward because APIs may enable entirely new products without comparable predecessors so new metrics will need to be agreed and tracked.
2 Time should be invested to determine where the most immediate opportunities/benefits can be accrued. In the short term, the focus should probably be on quick wins rather than long-term new product development. API monetisation is most likely to establish itself where existing capabilities are rapidly enhanced or improved rather than where new, grand-scale and unfamiliar plans are imagined.
3 A security and governance plan needs to be developed in advance of deploying commercial APIs. The latter must be able to demonstrate security for all HTTP/HTTPS traffic, monitoring and testing of all monetised APIs, and clear policies around issues of access and credential sharing.
4 APIs are essentially building blocks of products and while the deployment of such building blocks from third party providers is increasingly common, how they are used and, subsequently, ownership of the product needs to be clear from the start when using commercial rather than self-developed APIs.
5 APIs are digital products so a service aspect must be considered when planning. APIs help create and underpin new value streams and when issues arise, it doesn’t necessarily make sense that internal API developers are best placed to resolve them. Where monetised, commercial APIs are concerned, roles and responsibilities should be established in advance.
With the right API partner gateways, operators can deliver monetised APIs that their enterprise customers are keen to leverage - but successful consideration of the above (and other) issues is likely to lead them to greater commercial success.
Gintel’s has a long history here, with our solutions behind some of the most successful API monetisation strategies. We provide secure reliable platforms for exposing APIs for network resources to enterprise and systems integration partners. They are tightly integrated with the underlying network and provide different levels of access, to meet different stakeholder needs.
Our customers have benefited from our innovation. Now, they benefit from the innovation of their partners. It’s a win-win. Why not get in touch and see how we can help unlock your network and help you build profitable new partnerships?
Interested in learning more? Let us know and we’ll show you how we can help.
Want to learn more about Gintel, our mission and our technology