Jean Burellier is Leading a Platform Team at Sanofi. He is also a professor at Supinfo, a French University. Jean also contributes to open-source on node.js. In this article, he discusses APIs and how we can join enough people working both in technical engineering and business working together with API.
As of today, we all use or consume APIs. When we use smartphones, laptops, tablets, etc, we are using APIs. But we do not know that we are working with APIs. Only the tech people in the company are aware of the APIs that are being built and consumed. So, API is not looked at as a product in itself; usually, it is part of a global product like an application.
An API is always hidden behind some complexity. But for a company, it’s also the core of the system. You may have an API without a front-end application, but you may not be able to have a complex application without an API. For example, if we remove all APIs, say from Twitter (or X), we may have a great content interface and mobile application, but we will not have a way to process large amounts of data or send messages, etc.
Let us consider working with data. You can use a Google sheet or a Microsoft Excel sheet to gather and manipulate data. But, if the data are in large numbers, that may get difficult. It will be simpler to query a database using an API.
API should be seen as a goal of your company, not just something that is part of one project.
Before we use APIs for everything, we should change the mindset of people who work around the API, be it the engineers, the business, companies, etc. For this, we need to build the API-first mindset. API-first encompasses this idea of building an API-first approach, which means trying to build your API to be consistent and reusable. You must establish a contract for how the API is supposed to behave. This requires discussions with people who are involved in the API. How APIs are built needs to be standardized.
API-first involves planning and collaboration as opposed to directly writing code. You must plan for scale.
API allows a company to break down the capabilities of core services into many individual autonomous services. An API-first strategy allows organizations to build APIs that serve all applications, and applications can be developed and maintained efficiently for all devices, platforms, and operating systems.
So, to summarize, the benefits of an API-first approach a –
- Parallel Development
- Cost Reduction
- Standardization
- Speed to Market
- Better developer experience
- Product-oriented
To enforce API-first across the organization, you must build a governance group. This group should be created with members from engineering as well as business. The group will help in guaranteeing compliance across use cases. The group will also help validate, monitor, and discover APIs.
To make all this work, we must bridge the gap between business and engineering. Both departments have different roles to play. So, building an API should not divide us but should bring us together on the same core concept for the company. As APIs are a product, they can bring direct and indirect value to the business. This can be done by opening APIs to new customers and markets. You can have a monetization strategy. To get more benefits, you need access to more data from other customer companies. This will help you to enable other businesses to use your APIs.
The engineering side should provide data to the business about the APIs. They should be proactive about analytics and observability. By building a voice on our project about using API, we can build a better community inside the company. On the engineering side, it is important to be transparent about success and failure. You should not hide the complexity involved in creating the API.
The business should provide feedback to the engineering department as early as possible. New proposals and ideas should be discussed with the technical (engineering) team right at the start to work on the feasibility, complexity, changes, etc. The business team should also actively participate in tests and invest time learning about the APIs.
So, to bridge the gap between engineering and business, the API contract should be considered a product. The contract should be built along with the business so that it is possible to share knowledge. Both teams are clear about the use case for which the API is being built. New features can also be discussed at this stage. The business should validate the final product, so the business should be involved in testing right from creating test cases and helping with test data.
