API significa Interfaz de Programación de Aplicaciones (en inglés, Application Programming Interface, y de ahí sus siglas). Las APIs ayudan a los desarrolladores enormemente ya que conectan entre sí dos softwares y además, las APIs permiten que la distribución sea masiva y con un time2market muy rápido.
Pero, ¿qué tienen que ver las APIs con el prêt-à-porter? y ¿por qué digo que son tan beneficiosas?
Empezemos a responder por el principio:
¿Qué es el prêt-à-porter? ??♂️
El termino francés prêt-à-porter significa “listo para llevar”. Se introdujo en la industria de la moda en su evolución desde un modelo de prendas de alta costura hechas a medida, hacia una democratización de la moda con el fin de llegar a un mayor número de consumidores.
Ejemplos como este hay muchos. Como la evolución desde los modelos artesanales a modelos de producción en cadena que revolucionaron industrias. Otro ejemplo se dio en la industria del automóvil con la puesta en marcha de la producción del Fort-T.
Estas evoluciones industriales se basan en la producción de los productos bajo unos estándares y patrones. Así se pasa de una producción a medida a un modelo en el que se desarrollan productos para que se adapten a la gran mayoría de los consumidores.
Democratización del software ?
En el mundo del software el término API ha existido desde el principio de computación. En definitiva un API es el contrato establecido entre dos máquinas/sistemas/programas para intercambiar datos o funcionalidad.
Al igual que en el mundo de la moda en el que la ropa estaba hecha a medida, las APIs estaban orientadas a proveer a cada consumidor lo que necesitaba a medida.
Con la disrupción en las comunicaciones entre maquinas/sistemas/programas que supuso internet, el concepto de API también ha evolucionado hacia un modelo de estandarización. Ha pasado de APIs creadas ad-hoc para un consumidor a APIs orientadas a un uso masivo de consumidores. Al final democratizar el desarrollo del software para que cualquiera lo pueda consumir.
API Economy como un ecosistema ⚡️
Con el concepto de API Economy surge de la idea de tener un mercado de APIs listas para consumir. Representa la idea de que el API es un producto que tiene un mercado de consumidores creando un ecosistema, una industria a su alrededor.
El API Economy tiene dos puntos clave:
1. Industrializar el desarrollo de APIs permite llegar a millones de personas
Como cualquier producto, el proceso de desarrollo de un modelo de estándares puede llegar a resultar más costoso que simplemente un proceso artesanal. Ya que el proceso de industrializar supone que donde el coste principal son las horas del artesano, ahora tenemos que construir una fábrica. Pero el business asociado al producto claramente es favorable al de un modelo estandarizado, debido a que se incrementa el número de consumidores, pasando de un cliente que pide un traje a miles o millones de clientes que usan prendas patronizadas.
2. Se reduce infinitamente el time2market
Hoy en día el consumidor no espera. Prefiere ir a una tienda de ropa ver los que hay, probárselo y comprarlo en el momento, antes que ir a una sastrería pasar un tiempo explicando lo que quiere, que le tomen medidas y unos días o semanas después tener la ropa que quiere.
Y ¿Qué pasa si el resultado del artesano o el sastre no es el deseado después del tiempo de espera? En una tienda el consumidor ve exactamente lo que se va a llevar y se lo puede probar.
Tener el Software listo para usar ??
Precisamente es lo que implica el prêt-à-porter: listo para llevar, listo para que cualquier consumidor lo pueda comprar y usar. El caso de negocio implica que los costes de producción son más altos pero al tener tantos consumidores el coste se diluye. Cuantos más consumidores tengamos, permitirá hacer productos más baratos. Tal vez no sea la ropa (o la API) de sus sueños, pero seguro que cuadra con sus necesidades.
El símil en el mundo del software a este proceso es lo que hoy en día la industria conoce como APIs. Desarrollar software de forma estandarizada que cualquier consumidor la pueda usar y la pueda probar antes de comprar
El objetivo de hacer APIs no es hacer software con menos coste, es hacer software más reutilizable, con más consumidores. El caso de negocio de desarrollar APIs está, al igual que en el mundo de la moda, en la cantidad de consumidores. Al final se reduce el coste de hacer software pero no porque el software que se hace sea más barato, sino porque se hace menos software. Es decir, en vez de hacer funcionalidades adhoc por consumidor se desarrollan funcionalidades para que cualquier consumidor las puedas utilizar.
La ideación de un API: su punto clave ???
El punto clave de cualquier producto es la ideación del mismo, hacer un producto que vaya a tener un mercado, un ecosistema de consumidores. Así pues, en el desarrollo de APIs hay que invertir en la ideación y diseño del API. Esto significa que, además de pensar en campos de entrada y salida, tenemos que pensar en:
- Que estos mismos sean entendibles por cualquier consumidor
- Que se defina el comportamiento que van a tener los datos
- La funcionalidad del API
En esta era de la digitalización los consumidores quieren tener los productos disponibles cuando quieran, donde quieran y como quieran. Es decir quieren comprar cuando llegan por la noche a casa y hacerlo desde un móvil o una tablet. Aquí es donde las grandes tecnológicas están copando el mercado mundial ya que ponen a disposición de cualquier consumidor los productos desde las aplicaciones web o móviles.
El Marketplace: nexo entre clientes y desarrolladores ⚔️
En este sentido, el Grupo Santander tiene un negocio financiero en un mercado global y su objetivo es evolucionar para dar a los clientes sus productos financieros cuando quieran y donde quieran. Al igual que el consumidor de otras industrias, el consumidor de productos financieros ya no va a las oficinas y quiere consumir sus productos desde su móvil o tablet cuando llega a su casa o en fin de semana.
Para ello, el objetivo del banco es proporcionar a los clientes las aplicaciones móviles/web necesarias para cubrir sus necesidades.
Un cliente habitual del banco no va a ser el consumidor de las APIs, va a ser un consumidor de las aplicaciones del banco, pero para que el banco tenga la capacidad de desarrollar aplicaciones para los clientes lo suficientemente rápido se necesita que las funcionalidades del banco estén listas para ser usadas desde las aplicaciones.
Al igual que el pret-a-proter en moda, los desarrolladores de las aplicaciones finales para clientes necesitan las APIs, y estos desarrolladores son los verdaderos clientes de las APIs como productos.
El caso de uso más inmediato de desarrollo de APIs no deja de ser crear un modelo interno, buscando la eficiencia, pero no la del desarrollador de APIs, si no para el desarrollador de aplicaciones para el cliente. Exponer las funcionalidades básicas del banco en forma de APIs para que cualquier aplicación las pueda usar, pasando de un modelo artesanal a un modelo estandarizado donde múltiples aplicaciones usen la misma funcionalidad, las mismas APIs.
Siguiendo este razonamiento hoy en día las APIs no solo son funcionalidades expuestas para interactuar entre maquinas/sistemas/programas, son funcionalidades que pueden ser usadas por cualquier consumidor. Es decir, no todas las funcionalidades que se desarrollen se calificarían como APIs, solo aquellas que vayan a ser usados por otros desarrolladores.
Siguiendo esta transformación en el modelo de desarrollo se puede extrapolar a otros ecosistemas, como es la exposición de las funcionalidades del banco a consumidores externos al mismo.
Esto está alineado con la estrategia del Grupo de crear una plataforma abierta de servicios financieros, donde el grupo está creando productos globales que van a necesitar tener las funcionalidades de los bancos listas para ser usadas y la eficiencia se alcanzara con la exposición de APIs, consumibles por los diferentes productos globales versus hacer servicios a media por cada producto.
Sigamos el ejemplo y la evolución de la industria ?
Este mismo modelo es el que han seguido empresas como Amazon, que se trasformó de forma que cada departamento expusiera su funcionalidad en forma de APIs y así unos departamentos se convertían en consumidores de otros.
Parte del éxito de Amazon reside en que lo que empezó como un modelo interno para sus funcionalidades internas, como pueden ser los servicios de infraestructura, los han expuesto para clientes externos y han convertido un negocio de venta de libros a un gigante tecnológico que provee servicios de todas clases como infraestructura.
Por esto, y ya lo estarás pensando, es básico enfocar la definición de las APIs para cualquier consumidor aunque su uso inicial sea solo interno, ya que el mismo API se podría exponer al exterior. Es más, como os he contado más arriba, los consumidores de las APIs son los desarrolladores, no los clientes del banco, y estos tienen conocimiento de la funcionalidad de la aplicación que desarrollan pero no son expertos de la funcionalidad de otros departamentos o productos del banco que necesitan integrar en su aplicación.
Si se quiere alcanzar un modelo prêt-à-porter, sería necesario que el desarrollador:
- Llegue al Marketplace
- Encuentre de forma fácil la funcionalidad que necesite
- Entienda sus características
- La pueda probar
- Y al final la use
Si queremos que todo esto ocurra es fundamental que el desarrollador del API la diseñe con el objetivo de que el consumidor sea independiente: con el objetivo de autoconsumo.
En un modelo donde cada servicio se hace a medida de cada consumidor no existe este requisito de autoconsumo ya que el consumidor se ha puesto en contacto con el desarrollador y le ha pedido lo que necesita (ha ido la sastrería le han tomado medidas y ha explicado que traje quiere). Al igual que con el traje, hay una interacción entre desarrollador y el consumidor hasta que el consumidor obtiene el servicio que necesita. Como sabemos que esto requiere su tiempo, suena lógico que el desarrollo de aplicaciones se alarga.
API Management ⚙️
Sin embargo, en nuestro modelo donde el objetivo es que el consumidor vaya a una tienda y elija la ropa que está disponible no cabe tanta inversión de tiempo. En el mundo del software la necesidad es similar. Aquí es donde entra el juego el concepto de API Management. Se necesita un Marketplace donde está la oferta de todos los productos, de todas las APIs. Donde el consumidor pueda ver el catálogo de las mismas, ver toda la información necesaria para consumirlas y entender cómo funcionan, así como para probarlas antes de usarlas; lo que se conoce como sandbox.
En este modelo estandarizado se necesita una gestión integral del producto por parte del desarrollador. Gestionar las diferentes versiones, a los consumidores de las APIs, la producción de las mismas, monitorizarlas y analizarlas.
¿Qué sentido tiene que sea más fácil y rápido para los desarrolladores integrar funcionalidades de Google o Microsoft, compañías que están a kilómetros de distancia, que funcionalidades que desarrollan compañeros de departamentos vecinos en la misma empresa?
En resumen, hoy en día el concepto de API ha evoluciona de forma similar a como han evolucionado otras industrias. El desarrollo de API es el prêt-à-porter del software.
Rafa Poza
Santander Global Tech
Informático de profesión y vocación. Actualmente parte del equipo de arquitectura de APIs.
