API Lifecycle: Moving from a Product as API to API as a Product
Francois Lasne is the Director of Open APIs Strategy at Finastra. In the article, Francois talks about moving from a product that has an API to an API becoming the product. We will learn about the API lifecycle through the lens of the Finastra model.
Usually, everyone has a product. Consider a TV. It has some characteristics, color, costs, etc., It is then connected to a power plug, and we get a service. Your TV is nothing without being connected to power. The remote control is an API from the human to the TV. Even if the TV is excellent but does not have a remote control, no one will buy it. So, there is a difference between just adding a product that can be good and having a service that people desire. The final solution is an ecosystem with Wi-Fi, Netflix, and YouTube on your TV. So now, we have a product, and then it has a service and then a smart interface to make it an ecosystem. This is the evolution from a product to an ecosystem.
This is the new reality even with Finance. In France alone, as per recent numbers, there are 700 declared FinTechs. It has a lot of factors. We are not the best at everything, and we need to work with partners, especially in fraud detection.
Most of our companies have products. Sometimes we want to put APIs on top of our products.
But you have to think about what you are best at, doing things at the beginning or the end. In the end, usually, there is a rush. So, it is better to switch from product to APIs. We need not build our server or a complete solution. We can expose a domain that enables Business-Driven Development. In business-driven development, you need to be consistent. The API needs to be discoverable. Most importantly, you need to have a feedback loop. We sometimes need to expose our APIs even before the product is here. If it’s a product, you need to build it first. Do you need to build API in the first stage, mock, get feedback, and then implement it?
Clients usually ask, “I have APIs. Can I publish them as Open APIs?” Usually, it’s a bad idea. You cannot paint on your API. Why? Because of the past. Most products have technical debt. Reduce your technical debts. Don’t expose feeds that you don’t need. So it’s important first to acknowledge that you have APIs that have been designed in the past. If you expose legacy APIs, you expose your dinosaur, your technical debt, and that’s not the goal.
Simple is beautiful. If you expose your complexity, you give your complexity to your clients, and they do not appreciate it. They want good service.
You can also have a design-first approach. Your product was designed a long time ago. So, you can redesign it. Think of it as an investment to save time and costs later. API is mostly about API design. API implementation usually becomes the mechanics.
The API design would make the business simple. Redesigning an API is a technical piece. You hear about Swagger, CS, JSON, HTTP, Implementation, etc. It looks very technical. If you want to have an API strategy, you need your developer portal to have players register to it; you have to have an API gateway, self-registration, security, database, etc. We need a monitoring platform, a billing platform, and a publications pipeline to ensure a good API. Though it looks like a technical piece, it is not. It also has an interface. It is about business to business, business to the customer; it is about a connection. If you do not want API as a product, you need to understand market demands and focus on how people will consume your product. That’s a key difference. As you need to understand the market demand, it is about partnership. You need to know the market and your competitors in the ecosystem. To summarize, API is a business. An API is built to respond to market demand. It is a business interface for your consumer. It is a network interface of your product.
To have API as a business, you need to have a design approach. It is both technical as well as business. Business analysts would bring their understanding of markets; architects will bring the constraints. They would then reach an agreement that becomes the specification of your API. So, the role of an API manager is about connecting products and connecting people. You need to work with a partner enablement team because, in the end, some partnerships need to be built. You need a legal team to understand regulations about exposing APIs and information. You need to speak to the HR team, technology team, data security team, etc.
Open API Journey
We have an initial state when we expose the business niche and the business definition, and we do the feasibility and prioritization. We also have a defined state when all that has been settled. We have an interface definition, KPI definition, and validation. We now know what we are building. That’s the beginning of the journey. After that, we have the development phase, where we code, deploy and test. Security is also implemented in this phase. Then we have the integration stage. Here you need to have real testing environments. You perform performance testing, security testing, penetration testing, etc. You need to check data privacy. You then perform a marketing review. The API is moved to production and is available to the public. This is then monitored using SLAs.
APIs are a value solution but may create friction with an organization. An API world is a competitive world. For good APIs, you need to be an advisor and an enabler.
