1. Can your product help me solve my problems with legacy systems? This article will not tackle this question. A separate article will follow on this channel addressing how to deal with legacy systems and succeeding with large refactoring projects.

2. What is the excitement that you can bring to our organization with your product, an API Enterprise Marketplace? This is the question that this article will focus on. However, it is relevant to start by addressing how leaders should interpret what APIs represent for an organization.

API as Interfaces

Interfaces allow us to divide and conquer complexity. When an interface is defined, it immediately allows to place the associated complexity of the system behind into a black box. When we think about this system, we no longer need to bring to the limited working memory of our brain its complexity but only its interface, the handle that we need to use to get the system to deliver its intended function. 

The first benefit of interfaces is that they allow us to design and build large and complex systems as a combination of interconnected (through interfaces) subsystems (black boxes).

No less importantly, the modularity provided by clearly defined (and respected) interfaces serves to maintain and evolve these large and complex systems. Indeed, any large and complex system has the potential to become a huge liability for the organization in the form of a dreaded legacy system. On the contrary, a subsystem with a well-defined and respected interface and a size that two software engineers, without prior knowledge of the software, can get to understand, will never come to represent an unmanageable risk for the organization.

APIs as digital products

Traditional companies create value through products and services. However, a growing number of companies are creating value today through digital products and services (going forward, we will only refer to digital products). Some of these digital products remain tangible because they have a mechanical support associated. Smartphones are a great example of this category of digital products.

A second very popular category of digital products are applications (mobile applications, web applications, desktop applications). These digital products do not have a tangible support associated but they do materialize by colonizing a different digital product with mechanical support such as a smartphone or laptop.  

Finally, a third most relevant category of digital products does not ever materialize. They have neither a material support associated nor they colonize the material support of another digital product. In this category, Google search ($149 billion revenue in 2021) is probably the most successful product to this day. 

These intangible products are typically consumed by calling their exposed interface which is, typically, a REST API. A traffic analysis report of the Internet conducted by Akamai in October 2018 states that API traffic represents 83% of the total traffic on the Internet. Postman´s 2021 state of the API report indicates that 67% of companies are heavily invested on API-first development, and this is a 60% increase compared to the 2020 report.

We should therefore consider that APIs are the facade of a certain category of digital products and understand that, as any other product, they bring along opportunities and risks.

• APIs may bring the opportunity of revenue generation. For example IDNow, the European provider of identification services reported an increase of more than 100% in the transactions recorded in 2021.

• APIs may bring along the opportunity or cost optimizations. For example, an insurance company may use an OCR service to automatically process the hand-written text introduced in the European standard form used by its customers to report a car accident.

• APIs bring along business risks in the form of quality issues, security attacks, unacceptable delays in the responses or simply service unavailability. Going back to Google services, eight different outages are documented in Wikipedia. The key message is that if it happens to Google, for sure it can happen and it will happen to your company. 

Moreover, digital products or user experiences with major impact on your revenue stream such as e-commerce or user registration routes make use of multiple and different 3rd party API services: Personal identification services, services validating the existence of an IBAN, creditworthiness services like German Schufa or the tools used for web analytics and user tracking. Any of these services may become unavailable and bring down your registration route, typically in an evil and silent way: While the registration route seems to be functional, and it actually is for the most part, users will not be able to complete their applications and your business is bleeding.

The challenges of API immateriality

I do not believe it can be a coincidence that all the languages I know have the same adage:

• What the eyes don't see the heart doesn't grieve. 
• Ojos que no ven corazón que no siente. 
• Loin des yeux, loin du coeur. 
• Aus dem Auge, aus dem Sinn
  
  

The significance and growing relevance of APIs as digital products coupled with the immateriality of the APIs is a major problem for organizations that should not  be underestimated. Most people (and certainly most engineers) are visual. We are much better at managing objects that we can see and are tagged with a name that we can remember.

How can you possibly know or remember the APIs your organization produces, exposes to the outside world or consumes when you cannot see them anywhere? How can you keep in mind every single API service, internal or external, that fundamental business domains such as the registration route which brings new customers to your business depend upon in order to function properly?

At apinity, we strongly focus on user experience and product design in order to:

• transform APIs into visible, tangible and attractive first-class digital products. 
  
  
• target not only the technical personas (developers, devops and cloud architects) but also the non technical stakeholders (product managers, business owners, marketing, legal and procurement professionals) who are responsible for all the business operations associated with APIs.
  
  
• support all the relevant user journeys for business operations of API publishers and consumers.
  
  
• standardize how APIs are published, subscribed to and securely accessed.
  
  

Driving internal quality with an API Enterprise Marketplace

If you want to improve something your first need to measure it and then you need to make these measurements visible to the organization. This is the principle of OKRs and it also applies to APIs.

An API Enterprise Marketplace should bring full transparency to the performance of every single API, consumed or published by the organization, which has business or reputational relevance.

An API has to be available and perform its intended function, but it also has to do so within a reasonable time, and consistently so. If an external or internal API is accessed during a customer sale or registration route and it takes 5 seconds to respond it is going to have a major impact on your conversion rate, the performance of your funnel and ultimately your revenue. Human perception has not changed significantly since the beginning of the Internet and different studies conducted over the last fifty years provide similar advice concerning response times:

• 0.1 seconds is the limit for the user to perceive that the system is reacting instantaneously.
  
  
• 1 second is the limit for the user´s flow of thought to stay uninterrupted, even though the delay of the system is noticed.
  
  
• 10 seconds is the limit for keeping the user's attention.
  
  

Organizations need to be sure that the latency of APIs with a business impact is consistently low, in particular during peak business hours. Average response times are not good performance indicators. At a minimum you should be measuring the 90th and 99th percentile latencies. A 99th percentile latency of 500 ms means that 1 in 100 requests will take 500 ms or more to get a response. These percentiles allow to measure the long tail latencies, which are proven to be critical for the user experience. I personally value the possibility of visualizing the probability density function of the API response delays.

Driving innovation with an API Enterprise Marketplace

The well-known properties of marketplaces to efficiently allocate resources can be directly applied to foster value creation and innovation inside the organization.

Let us assume that a team inside the organization designs a great digital product that can be of use to many other teams inside the organization. In this case:

• Exposing the API in the organization´s API service catalog will provide visibility of the service. Other teams can now discover and subscribe to this service.
  
  
• Metrics such as availability, performance and latency of the API service may be exposed by the service publisher to provide transparency and high confidence on the quality of the offered API service.
  
  
• Setting a price for the consumption of this API will allow a fair coverage of the development and run costs and provide a strong incentive for the API owner to develop with quality and properly document the API in order to maximize adoption.
  
  

An API Enterprise Marketplace makes it possible to introduce traditional market dynamics inside an organization in order to naturally promote quality and innovation, allocating more resources of the organization to the teams who are creating more value through innovation and quality.

Similarly, it is also possible to expose any of these internal API services to the external market. Every apinity API Enterprise Marketplace is a few clicks away from the Public Marketplace operated by the apinity team. As a consequence, any API service can be published on the Public Marketplace with the pricing decided by the team. Reducing the friction of the Go-to-market strategy can be a game changer in corporations. The adoption and economic success of the organization´s API services on the open market  can be considered as the ultimate acid test for the relevance of the innovation generated inside the organization.

An internal innovation program can leverage the capabilities of the API Enterprise Marketplace and build on top by defining simple and clear gates and guidelines allowing the teams to set prices and publish API services on the Public Marketplace. We believe that such an innovation program can have a transformational effect in the organization by enabling the most capable and entrepreneurial teams to demonstrate their potential. We can only encourage the definition of such innovation programs together with the metrics (number of published external APIs, generated revenue, number of customers) that can allow the organization to measure the success of such programs in a 2 to 5 year period

Conclusion

In this article we have described how API should be interpreted by organizations, both as interfaces and as immaterial digital products.

We have emphasized the problems stemming from the immateriality of APIs and how we at apinity address them, placing significant focus on the user experience of different personas (technical and non technical), the different user journeys of API publishers and consumers and covering all relevant business operations (e.g. contract storage, subscription to a plan, pricing, metering and billing).

Finally, we have illustrated how an API Management tool designed following the paradigm of a Marketplace can be effectively used to drive quality and innovation inside an organization.

Author: Dr. David Vazquez Cortizo, Managing Director of apinity