What I’m going to do is walk you through this concept of quantum duality of API as a business and API as a technology because a lot of organisations are focusing on API programmes, but they are looking at only one aspect of this problem. Either the business side, or the technology side, but we need to have a balance. So that’s where I’m going to discuss and share some of my experience working with different types of enterprises around the globe. First thing we’ll talk about is the Federation and Business Models around APIs, and then 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 modernise the development. All these four pieces are tied with a successful API programme 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. So 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. So the traditional supply chain contains sourcing, manufacturing, distribution, sales and consumption type of flow. However, the digital supply chain is completely different. It’s about the discovery of the ideas, going into development, then into deployment. The consumer will come and register for that particular service or the product, and they will get an experience. And they have the experience, they will provide the feedback back to the product team. It will then go in this iterative cycle. That’s how 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 apps that you download 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, either it can be a centralised architecture or a decentralised one.
The centralised architecture has different types of layers connected using APIs, whereas the decentralised one has different types of components in the distributed architecture, connected with APIs as well. I have categorised them as Utility APIs, Domain APIs and Edge APIs based on the behaviour 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, or OLE or COM that came in, I think, in 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 21st century because the core of this product development happened through the APIs. If you have a rich API, exposed through your API programme, 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. We have direct monetization, indirect monetization, combined physical/digital, and how those create the backbone for digital transformation and API Products.
Direct monetization: basically, 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 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 organisations even connect with their competitors as well, and then get these ecosystem capabilities into the consumers through APIs. The marketplace is a really good example of this exchange. 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, like 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 by using that. 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 organisation. 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 basically 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. “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. If you take one example, e.g a financial Institute, using this partner model and the ecosystem capabilities, you can provide a seamless experience for your end users, because banks can connect to third party providers like payment gateways, mobile wallets, and then new credit cards so on and so forth, and provide that single experience for the end user rather than having to switch to these different type of service providers. Another example is that Telco can create aggregated marketplaces by combining the different types of APIs that they provide, and 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. And the supply chain management can relate to API Integration and Enablement as well as 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. And then as I explained earlier, these cloud native technologies and how you use the cloud native technologies, and what is the role of the API can be highlighted here. So if you look at the traditional way of using stuff, as well as how you can use the cloud native technologies, you can see the relationships in between, and most of these relationships are built on top of the APIs like you run this stuff in containers, and most of the time on a platform like Kubernetes. APIs later decentralised integrations because you are moving from layered architecture into a more decentralised architecture. You will see APS everywhere, like from the utility level into domain level, into each level, with different types of API and it will bring more edge gateways into the picture. You can secure those like that, you can leverage the cloud as a technology and improve your API programme for a better and scalable usage.
The API Federation is another area that we have to look at, because if you carefully 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 that. 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 APIs preferences. Technology-wise, you can even categorise them into request/response type of APIs, web-based APIs, streaming APIs. There are different types of protocols available like HTTP, GraphQL. And now the latest standards are going with more event driven types of APIs, like AsyncAPIs. So all these things can be considered when you’re picking a gateway. Nevertheless, the beauty of 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 summarise 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 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. Then it is the governance across different API layers that you have or different API deployments that you have 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, the technology side, we talked about the cloud, how you can leverage the cloud, then we talked about Kubernetes containers where automation is playing a huge role. If you look at the API lifecycle, you can map the API lifecycle 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 API Management System, the programmability is a key because programmability 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 were to be 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. because you can’t stick to one standard as I explained earlier, e.g. you might use GraphQL, AsyncAPI, gRPC, and then other protocols like Kafka and NATS based on your needs. The system should support to cater for all these types of protocols and all different types of APIs. It also has to support aggregation and integration, because 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, how you can leverage things, like microgateways, especially when you are in a decentralised environment. You also need to pay attention to technology life service, data mesh, how you can use them in your API programme, because if you can’t use that type of technologies with the API platform that you are using, you have a bottleneck! You can’t incorporate those architecture styles, architecture patterns, as well as the implementation-related things based on the flexibility you get from that platform. We talk about automation and 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 as I mentioned earlier, and whichever technology will come in the future, what are the extensibilies that you will have in your API platform? That is basically how you can connect these API business models with the API technologies, and then have this balance because if you put more weight into one side, you will not get the maximum out of it, as well as not having a successful API programme. As an API strategy store project manager who is responsible for the API programme, you have to look at both these two sides and find the balance. And 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 analyse 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. From my side, I wrote a detailed article about this concept which you can find here: The Importance of Building an Integrated Supply Chain for APIs.
Q&A Section
Q: With the API as a technology viewpoint, obviously, if you think about the technology side of things, if you’re building the implementation as a new application, or a new Business capability, it’s relatively straightforward to think about the API first. I guess a lot of organisations will have a lot of COTS applications in their building. But they want to expose the business value as APIs’ more of, and that’s a bit more of a different challenge. Do you have any tips and tricks as to how you approach when an API is locked away inside a COTS application somewhere?
A: I would say, it has to be APIs first, I completely agree, but before that, we have a step in approach that is the consumer first. Look at what your consumers are looking at. And then look at the APIs, whether these APIs already exist. If not, you have to design those APIs. And then look at how you are going to fetch the information required to support those APIs, like the systems and the subsystems. Because a lot of people do this approach in the reverse order that they look at the capabilities already existing in these systems and subsystems and data, create APIs, and then ask people to use it. In some cases, some organisations that I know have hundreds of APIs that nobody consumes because of this problem. The consumer will first naturally tie the API programme into the business model. That way, you can have a meaningful set of APIs as well as adding value to the value chain of your organisation by using your APIs.
Q: I guess, if we have a lot of APIs, it’s really about how do I make something that’s reusable by configuration? And ultimately, if the COTS applications themselves haven’t thought about how to make something that is agnostic of the business process or the consumer, is there any particular way that you would look at how to work with those COTS applications, as opposed to, when it’s a Greenfield, and you’ve got a back end implementation to build yourself?
A: So I think the composability of the enterprise comes with the APIs. API is the glue. And it is not only the Greenfield, it glues with the Brownfield, as you said, these kinds of legacy systems. Depending on the integration points a back-end system has, either you can just put API gateways in front of that particular back end system and expose those capabilities. If you don’t have integration points, you need some kind of a Domain Services layer, or kind of conversion layer that will convert those back-end capabilities and expose the API, that way, you create the API endpoint, and use the API programme to expose those capabilities. And I think that’s a challenge. That’s why I highlighted that integration is tied with API Management. Without integration, you can’t have a proper API programme because the backend systems are really complicated, and we have to deal with that.
