Quantum Duality of API as a Business and a Technology

As an API strategy store project manager who is responsible for the API program, you have to look at both of these two sides and find the balance. It’s really hard to say what the correct balance is because it totally depends on the current landscape, on the business models, as well as on the technology maturity that you have. So you have to analyze it, and then look at the maturity model, and have a proper way of increasing or improving the business models as well as improving your technology stack.

What I’m going to do in this article is walk you through the concept of quantum duality of API as a business and API as a technology because a lot of organizations are focusing on API programs, but they are looking at only one aspect of this problem: either the business side or the technology side. However, we need to have a balance. This is where I’m going to discuss and share some of my experience working with different types of enterprises around the globe. The first thing we’ll talk about is the federation and business models around APIs, and then we will move on to how this polyglot and heterogeneous nature affects API development. From the technology side, it will be how you can move to the cloud and leverage cloud-native technologies and how you can modernize the development. All of these four pieces are tied together for a successful API program, so I’m going to discuss these concepts.

Before jumping to the APIs, let’s look at this concept of a supply chain because that connects with some of the business models we are discussing for our APIs, and supply chains are really important to produce a product or a service. It’s talking about the production side of the productive service development or distribution side of the service development. In some cases, it will be both. If you look at the supply chain, it has changed with the digital products and services we are consuming and providing in the current market context. The traditional supply chain contains sourcing, manufacturing, distribution, sales, and consumption types of flow. 

However, the digital supply chain is completely different. It’s about the discovery of the ideas, going into development, and then into deployment. The consumer will come and register for that particular service or the product, and they will get an experience. And when they have the experience, they will provide feedback back to the product team. It will then go in this iterative cycle. That’s what the current digital supply chain looks like. If you look at the new product experience again, it has changed so much that you can even buy a car online today by configuring different kinds of features. Most of those experiences come through downloading apps from an app store, swiping your credit card, and suddenly, the new product experience is happening. So how are these products built? These digital products are built by using architecture, it can be either a centralized architecture or a decentralized one.  

The centralized architecture has different types of layers connected using APIs, whereas the decentralized architecture has different types of components in the distributed architecture, connected with APIs as well. I have categorized them as utility APIs, domain APIs, and edge APIs based on the behavior and the capabilities that they provide. So if I repeat what I said earlier, the digital products are built using these types of architectures and APIs, enabling this application to develop. If you look at the evolution of the APIs, it happened like this: We started with technical APIs in a very isolated manner, and then it moved towards semi-technical APIs with different types of distributed computing technologies like CORBA, OLE, or COM that came in around the late '90s. Then we moved to service-oriented architecture and we had web APIs with that. Finally, in the 2011/2012 timeframe, this new concept of managed API scheme emerged and we are now at the API product.

Since the digital products are created by consuming these APIs, we say the APIs are the products of the twenty-first century because the core of this product development happened through the APIs. If you have a rich API, exposed through your API program, and provide your business capabilities through these APIs, developers can build applications and provide a seamless experience for the users using your products and services. There are different types of API models — direct monetization, indirect monetization, combined physical/digital — and those create the backbone for digital transformation and API products. 

Direct monetization is when the applications will provide the capability for the consumers and they will use it like you are buying a product or a service through an application. Indirect monetization, especially in the banking sector, or the aero sector, is where they will do different types of transactions. Then you have the connected-car type of concept that combines physical and digital. Finally, the larger digital transformation platforms are using API as a product to combine digital transformation initiatives as well. Those are a few subcategories that we can see when it comes to APIs or products. 

Nevertheless, products need ecosystems because, without the ecosystem, you can’t leverage the full power of the APIs. In today’s business models, isolation doesn’t work. You need to connect with your partners’ networks, and then with other counterparties that will help your business. That’s where the ecosystem comes into the picture. In some cases, some of these organizations even connect with their competitors and then get these ecosystem capabilities into the consumers through APIs. 

The marketplace is a really good example of this exchange. The marketplace is different from a typical API store because people ask this question: “What is the difference between an API marketplace and an API store?” My answer is that it’s like a typical marketplace that you see in your day-to-day life. It’s an exchange, as in you have multiple producers and multiple consumers. In the API store, it is a single producer and multiple consumers. So the marketplace is where these exchanges happen. There are conversations, and it is a more interesting place than the one-side experience that you’ll have in most API stores. 

When you have these marketplaces, you can create multi-party business models. The first category is called internal federated marketplace where one consumer will provide all these capabilities and push them to an API marketplace. It can happen through different business units inside the same organization. The second category is the partner marketplace where the producer will provide sets of APIs and their partners will provide some sets of APIs as well. All these APIs will go into a common API marketplace. Another category is called the closed group marketplace where you don’t expose all these APIs, and the creation of APIs to the public, you just pick certain sets of trusted parties and allow them to do certain activities, such as creating APIs or consuming them within your marketplace. The shared revenue marketplace comes with how we will share the revenue and, depending on who’s the producer, you will have a plan with them. And the monetization of the APIs will connect with that particular agreement that you have with your API partner. Finally, we have the aggregated marketplace. Basically, you create a common public marketplace with all these different types of parties. You and your partners will publish to the same public marketplace and allow the consumers to use these capabilities. 

So those are the five types of marketplaces and business models associated with that. Take a financial institute as an example. Using this partner model and the ecosystem capabilities, you can provide a seamless experience for your end-users. Banks can connect to third-party providers like payment gateways, mobile wallets, new credit cards, etc., and provide that single experience for the end-user rather than having to switch to these different types of service providers. Another example is that Telco can create aggregated marketplaces by combining the different types of APIs that they provide. When another partner of Telco takes those APIs, they can recreate or recompose some of these APIs and provide them as a capability to their customers, as well. Those are two examples of how you can leverage these business models. 

Now, if we go back to the physical supply chain and the API supply chain, you can see a really good connection, like product lifecycle management in the physical supply chain map of API product management, ERP, and financial systems that govern the physical supply chain map of API insights and monetization. The supply chain management can relate to API integration and enablement, and logistics in a physical supply chain can map to API DevOps and management. So we can see a parallel and a good relationship between these traditional models and API models that we will see in the market. As I explained earlier — how you use these cloud-native technologies and the role of the API — can be highlighted here. If you look at the traditional way of using the stuff, as well as how you can use the cloud-native technologies, you can see the relationships in between. Most of these relationships are built on top of the APIs, as in you run this stuff in containers and most of the time on a platform like Kubernetes. APIs later decentralize integrations because you are moving from layered architecture into a more decentralized architecture. You will see APS everywhere, from the utility level into domain level, into each level, with different types of API. It will bring more edge gateways into the picture. You can secure those like that. You can also leverage the cloud as technology and improve your API program for improved and scalable usage. 

The API federation is another area that we have to look at. If you notice API gateways becoming a commodity, you can see there are multiple gateways (TN: AWS, Azure, NGINX, WSO2). These types of API gateways can provide API exchange capability, but it is more than that. That’s because once you have a proper API marketplace in API lifecycle management and monetization, all those types of cool API management capabilities, and allow these different gateways to connect to the same system, you can have this multi-party business model on top of it. That creates a lot of flexibility for the developers. If you look at large enterprises, different groups might prefer to use different types of gateways based on the APIs that they expose, as well as based on their actual API preferences. Technology-wise, you can even categorize them into request/response types of APIs, web-based APIs, or streaming APIs. There are different types of protocols available, such as HTTP and GraphQL. Now the latest standards are going with more event-driven types of APIs, like AsyncAPIs. All these things can be considered when you’re picking a gateway. Nevertheless, the beauty of the API marketplace and multiparty business model is that you can connect any of these different types of API gateways and leverage those capabilities within the same business model. 

To summarize this concept now, the first section is about the federation and business models that we looked at. Federation and multiparty capabilities are coming into the picture. That’s where the heterogeneous APIs are coming into play, so you can create different kinds of APIs that will support your technical capabilities as well as your business capabilities. This is how you can deliver value by using different types of business matters. Next, it is the governance across different API layers or different API deployments with multiple vendors coming into the picture. Based on the business model, you might need to be able to create new monetization capabilities across that. And of course, on the technology side, we talked about the cloud, how you can leverage the cloud, and about Kubernetes containers where automation is playing a huge role. 

If you look at the API lifecycle, you can map it with the automation capabilities and take an API from creation to production set up by using automation. You can also add various testing and verification capabilities so when you are looking at the API management system, programmability is key since it is the one enabling automation. In essence, the amount of things you can do depends on the level of automation that you have. You also need to take a look at the scalability, because, as I explained earlier, the applications are depending on the APIs. If there was a sudden increase of usage of your application due to some kind of condition, market or nature-related, or if there were less usage, how can you run a maximal or minimal infrastructure? Those kinds of things can be helped by using a cloud infrastructure, making the polyglot and heterogeneous capabilities really important. You can’t stick to one standard (e.g. you might use GraphQL, AsyncAPI, gRPC, and then other protocols like Kafka and NATS based on your needs). The system should cater to all these types of protocols and all different types of APIs. 

It also has to support aggregation and integration. Integration is really important when not every backend system supports API, or they don’t expose the API ready endpoint from those systems. You, therefore, have to do a lot of integration and create a meaningful API for the application developers to consume. Sometimes you have to create new APIs by aggregating sets of APIs as well. 

So that’s basically what we call the API composition. The modernization development methodologies and techniques are really important for knowing how you can leverage things, like micro-gateways, especially when you are in a decentralized environment. You also need to pay attention to technology life service, data mesh, and how you can use them in your API program because if you can’t use that type of technology with the API platform that you are using, you have a bottleneck! You can’t incorporate those architecture styles, architecture patterns, as well as implementation-related things based on the flexibility you get from that platform. When we talk about automation, CI/CD is part of that. How you can unify the API development is another thing that you need to take a look at. So if you can have a standard-based approach, then you can have a proper unified API development experience. 

Regarding technologies such as serverless Kubernetes and whichever technology will come in the future, what is the extensibility that you will have in your API platform? That is basically how you can connect these API business models with the API technologies. Then you have this balance, and if you put more weight into one side, you will not get the maximum out of it and will not have a successful API program. As an API strategy store project manager who is responsible for the API program, you have to look at both these two sides and find the balance. It’s really hard to say what the correct balance is because it totally depends on the current landscape, business models, and the technology maturity that you have. So you have to analyze it, and then look at the maturity model, and have a proper way of increasing or improving the business models as well as improving your technology stack.