API Business Models

Battle-tested APIs – Tech and Business working together

Image by ar130405 from Pixabay
Image by ar130405 from Pixabay

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.

Jean Burellier
Being associated with the industry since 2012, I have worked as a Developer, Leader, Architect and now Principal Engineer to build, architect and improve solutions based on APIs and real time communication. I have been thanked for my work around automation of processes allowing the companies to greatly increase the efficiency of their workflows while improving the developer experience and the quality in the final product. My colleagues know me as a good communicator who likes to use an interactive approach for understanding the requirements and solving problems of varied scope. Working with a plethora of roles - both technical and business - such as lead architect, staff engineer, project manager and CxO but also legal team I have been able to develop keen eyes for various technicalities which helped me in maximizing our products impact's for our customers.

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 1,000+ companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture