A few years ago, the term “API commercialisation” was foggy and unclear for most organisations. There were also few companies that actually increased their profitability by commercialising API. Today, it is universally accepted that data and internally used services are valuable and you can simply make profit on them. This applies not only to companies in the Internet industry, but virtually every larger organisation.
In this post, I will present:
What API Economy is
Basic business models in this concept
A possible way to implement it
What is API Economy?
Let’s start by explaining what API (Application Programming Interface) actually is. It can be defined as an interface enabling various separate systems to communicate and exchange information. API Economy, in turn, is a concept that assumes that the information is exchanged in a commercial manner. However, this term should be understood broadly.
How can you share it
The commercial exchange of information resources does not have to be based on the direct payment for access to services and data. API may be shared in a different form (also publicly – generally available). It is important that this sharing positively affects the organisation’s profitability.
API Economy in real life
An example is sharing data with partners who, offering them further, will increase the availability of our services and, as a result, will have a positive impact on our sales. Partners can also combine our services with theirs, thus increasing their attractiveness.
Types of final benefits in API Economy
Depending on the shared resources, the final benefits may be direct (sales of products for money) or indirect (advertising, attractiveness in the eyes of clients, attachment). All the above examples result from a given API Economy business model.
API Economy business models
In 2013, John Musser put together the API Economy models available on the market, divided into four main types:
#1 Publicly available:
A model that, according to statistics, is not dominant at all. It consists in making the API available free of charge. Examples of organisations that provide services in this way are, for example, Facebook and public institutions.
#2 Paid access:
Business model consisting in paid access to services. In order to use the service, you have to pay a fee, which can be calculated in any way (for time spent, number of calls, percentage of completed transaction, etc.)
#3 Rewards to its loyal users:
In this business model, the developer (external company) that uses the API may be rewarded as it will benefit the hosting organisation. An example may be rewarding a developer who, using the API, creates a platform enabling customers to subscribe to our services or transferring them to our products. It should be noted that individual fees are usually very small and rely on “sharing” what we earn on the customer.
#4 An intermediate system:
This model includes all other ways of benefiting from the API, such as providing API for a selected target group (e.g. the one that has purchased the license – Salesforce.com) or enabling third parties to use the API to increase their position in the market by acquiring content (e.g., Twitter).
A detailed breakdown of the API Economy business models proposed by John Musser can be seen in the figure below.
Before you implement the API Economy concept, it is necessary to remember a few key elements:
#1 Selection of shared data and services:
That is, the analysis of what services and in what manner can constitute a factor of competitive advantage for an organisation. After selecting them, it may also be worth rethinking in what order they should be made available.
#2 Choosing the API business model:
That is, using one or several models to maximise benefits.
#3 Measuring efficiency:
That is, defining the parameters which will enable the assessment of the potential and possible success of the adopted API Economy concept.
#4 API strategies:
All of the above elements should be compiled in writing in the form of a document defining the organisation’s strategies in the context of the API. This API strategy should result from the company’s IT strategy and contain all elements characteristic for this type of documents (goals, framework schedule, etc.).
#5 Adaptation of the API to the expectations of users and developers:
The interest of end application users and developers creating these applications will decide about the success or failure of the entire project. It is therefore necessary to identify what requirements these groups can have in the area in which we intend to share the API. Both functional requirements (which will be indirectly used, among others, by end users) and non-functional requirements (important for developers) are important.
#6 Determining the architecture and choosing the implementation technology:
There are many possible general architectural concepts that facilitate providing services in a heterogeneous IT infrastructure. Most of them are based on the data bus (ESB), constituting the central component of this architecture. Many manufacturers offer secure and efficient solutions under an open-source license. Good examples here are Mulesoft or WSO2 products, which additionally offer API Gateway solutions. This is important considering the fact that API Gateway functionalities (design, publishing, management, limitation, analysis, security) are particularly important for some of the API Economy business models.
If you want to learn more about API Management, contact us directly!
Integration Consultant in Unity Group, specialises in the implementation of solutions based on Mule ESB, data integration (data warehouses, MDM, ODS), application integration (SOA, ESB) and automation and optimisation of business processes. He has extensive experience in implementing IT and consulting projects for leading Polish enterprises (including ones in the fuel, energy, pharmaceutical, insurance, production, service and administration industries) in the areas of supervision (audit), IT system implementation, modelling and improvement of business processes (using UML elements, BPMN) and pre-implementation analysis.