API stands for Application Programming Interface. The APIs help developers since they connect two softwares together and not only that, the APIs allow the distribution to be massive and with a very fast time2market.
But what do APIs have to do with prêt-à-porter, and why do I say they are so beneficial?
What is prêt-à-porter? ??♂️
The French term prêt-à-porter means “ready to wear”. It was introduced to the fashion industry in its evolution from a model of tailor-made haute couture garments to democratization of fashion in order to reach a larger number of consumers.
There are many examples like this. Like the evolution from handcrafted models to chain production models that revolutionized industries. Another example was in the automotive industry with the launch of the Fort-T production.
These industrial evolutions are based on the production of products under standards and patterns. Thus, we move from a custom-made production to a model in which products are developed to be adapted to the vast majority of consumers.
Software democratization ?
In the software world the term API has existed since the beginning of computing. In short, an API is the contract established between two machines/systems/programs to exchange data or functionality.
Just as in the fashion world where clothes were customized, APIs were geared towards providing each consumer with what they needed on a customized way.
With the disruption in communications between machines/systems/programs brought about by the Internet, the concept of APIs has also evolved into a model of standardization. It has moved from APIs created ad-hoc for one consumer to APIs oriented to mass consumer use. Ultimately democratizing the development of software for anyone to consume.
API Economy as an ecosystem ⚡️
The concept of API Economy arises from the idea of having a market for ready-to-use APIs. It represents the idea that the API is a product that has a consumer market creating an ecosystem, an industry around it.
The API Economy has two key points:
1. Industrializing the development of APIs allows you to reach millions of people
Like any product, the process of developing a model of standards can be more costly than simply a craft process. Since the process of industrialization means that where the main cost is the hours of the craftsman, we now have to build a factory. But the business associated with the product clearly favors that of a standardized model, because the number of consumers increases, going from one customer who orders a suit to thousands or millions of customers who wear standardized garments.
2. The time2market is infinitely reduced
Today’s consumer doesn’t wait. They prefer to go to a clothing store, see what’s there, try it on and buy it on the spot, rather than go to a tailor’s shop and spend some time explaining what they want, have it measured and a few days or weeks later have the clothes they want.
And what happens if the result of the craftsman or tailor is not the desired one after the waiting time? In a shop the consumer sees exactly what he is going to wear and can try it on.
Having the Software ready to use ??
This is precisely what prêt-à-porter implies: ready to wear, ready for any consumer to buy and use. The business case implies that the production costs are higher but having so many consumers the cost is diluted. The more consumers we have, the cheaper the product will be. It may not be the clothes (or API) of your dreams, but it sure fits your needs.
The simile in the software world to this process is what the industry today knows as APIs. Developing software in a standardized way that any consumer can use and test it before buying
The objective of making APIs is not to make software with less cost, it is to make software more reusable, with more consumers. The business case for developing APIs is, as in the fashion world, in the number of consumers. In the end, the cost of making software is reduced, but not because the software that is made is cheaper, but because less software is made. That is, instead of making ad hoc functionalities per consumer, functionalities are developed so that any consumer can use them.
The ideation of an API: its key point ???
The key point of any product is the ideation of it, to make a product that will have a market, an ecosystem of consumers. Therefore, in the development of APIs it is necessary to invest in the ideation and design of the API. This means that, in addition to thinking about input and output fields, we have to think about:
- That these are understandable by any consumer
- Define the behavior that the data will have
- The functionality of the API
In this era of digitalization, consumers want to have products available when they want, where they want and how they want. That is to say, they want to buy when they get home at night and do it from a mobile phone or a tablet. This is where the great technologies are taking over the world market, as they make products available to any consumer from web or mobile applications.
The Marketplace: a link between customers and developers ⚔️
In this regard, Santander Group has a financial business in a global market and its objective is to evolve in order to provide customers with its financial products when and where they want. Like the consumer in other industries, the consumer of financial products no longer goes to the office and wants to consume their products from their mobile phone or tablet when they get home or at the weekend.
To this end, the bank’s objective is to provide customers with the mobile/web applications necessary to meet their needs.
A regular customer of the bank is not going to be the consumer of the APIs, it is going to be a consumer of the bank’s applications, but for the bank to have the ability to develop applications for the customers fast enough it is necessary that the bank’s functionalities are ready to be used from the applications.
Like the prêt-à-porter in fashion, the developers of the final customer applications need the APIs, and these developers are the real customers of the APIs as products.
The most immediate use case for API development is to create an internal model, looking for efficiency, but not for the API developer, but for the customer application developer. Expose the basic functionalities of the bank in the form of APIs so that any application can use them, going from a traditional model to a standardized model where multiple applications use the same functionality, the same APIs.
Following this reasoning, nowadays APIs are not only functionalities exposed to interact between machines/systems/programs, they are functionalities that can be used by any consumer. That is to say, not all the functionalities that are developed would qualify as APIs, only those that are going to be used by other developers.
Following this transformation in the development model, it is possible to extrapolate to other ecosystems, such as the exposure of the bank’s functionalities to consumers outside the bank.
This is aligned with the Group’s strategy of creating an open financial services platform, where the group is creating global products that will need to have the functionalities of the banks ready to be used and the efficiency will be achieved with the exposure of APIs, which are consumable for the different global products versus doing services on a per product basis.
Let’s follow the example and the evolution of the industry ?
This same model has been followed by companies such as Amazon, which was transformed so that each department exposed its functionality in the form of APIs and thus some departments became consumers of others.
Part of Amazon’s success lies in the fact that what began as an internal model for its internal functionalities, such as infrastructure services, has been exposed to external customers and has turned a book-selling business into a technological giant that provides services of all kinds as infrastructure.
For this reason, and you may already be thinking about it, it is basic to focus on the definition of the APIs for any consumer even if its initial use is only internal, since the same API could be exposed to the outside. Moreover, as I have told you above, the consumers of the APIs are the developers, not the bank’s customers, and these have knowledge of the functionality of the application they develop but are not experts in the functionality of other departments or products of the bank that they need to integrate into their application.
If a ready-to-wear model has to be achieved, it would be necessary for the developer:
- Get to the Marketplace
- Easily find the functionality you need
- Understand their characteristics
- Prove it
- And at the end used it
If we want all this to happen it is fundamental that the developer of the API designs it with the objective of making the consumer independent: with the objective of self-consumption.
In a model where each service is tailored to each consumer there is no such requirement for self-consumption since the consumer has contacted the developer and asked for what he needs (the tailor has taken measurements and explained what suit he wants). As with the suit, there is an interaction between the developer and the consumer until the consumer gets the service he needs. Since we know that this takes time, it sounds logical that application development takes longer.
API Management ⚙️
However, in our model where the objective is that the consumer goes to a store and chooses the clothes that are available there is not so much time invested. In the world of software the need is similar. This is where the concept of API Management comes in. You need a Marketplace where you can find the offer of all products, all APIs. Where the consumer can see the catalogue of them, see all the information needed to consume them and understand how they work, as well as to test them before using them; what is known as a sandbox.
This standardized model requires a comprehensive product management by the developer. Manage the different versions, the consumers of the APIs, the production of them, monitor them and analyze them.
What sense does it make that it is easier and faster for developers to integrate functionalities from Google or Microsoft, companies that are miles away, than functionalities that are developed by colleagues from neighbouring departments in the same company?
In short, today the concept of APIs has evolved similarly to how other industries have evolved. API development is the prêt-à-porter of software.
Rafa Poza
Santander Global Tech
Computer engineer by profession and by vocation. Currently I’m part of the APIs architecture team.
