Comienzos de las APIs

Durante el Año 2002 pasaron diversos acontecimientos para recordar: Brasil se convierte en pentacampeón de la copa mundial de fútbol, la burbuja del puntocom explota y muchas empresas de tecnología se fusionan, algunas otras cierran, pocas sobrevivieron y una de ellas logra superar las expectativas en el cuarto trimestre del 2002.

Dado que fueron tiempos difíciles y con todo en contra para fallar.

El aumento de las ventas navideñas, un constante tráfico y el aumento de las ventas internacionales pudo haber sido la fórmula perfecta para lograrlo, para esta empresa sobreviviente. Pero poca gente podría saber, bajo qué cimientos tecnológicos estaba parada.

La empresa había construido sistemas repetibles y escalables que le permitieron potenciar su crecimiento. Facilitando la comunicación entre sus equipos de tecnología y sus sistemas internos. Para vender cualquier producto de la A a la Z.

Previo a lograr llegar al punto de cosechar resultados, durante el 2002 sucedió un evento dentro de esta empresa. Durante el cual de manera tajante, el CEO de la empresa envió un correo para establecer las nuevas reglas del juego a nivel ingeniería. Este cambio, posiblemente muchos lo consideran como el canon tecnológico del momento.

Ese fue solo el comienzo de una etapa de innovación y crecimiento acelerado. Además del nacimiento de servicios tecnológicos que permiten innovar a muchas de las empresas en la actualidad.

El correo compartía los 6 puntos de lo que hoy conocemos como el mandato API de Amazon.

El mandato API

La esencia del mandato fue crear interfaces. O sea, crear conexiones que sigan estándares definidos por los equipos para agilizar las integraciones entre servicios / sistemas.

(1) Después de recibir el email, todos los sistemas debían exponer su datos y funcionalidades a través de interfaces. (2) Y todos los equipos debían usar estas interfaces para comunicarse entre ellos. (3) No debía existir ninguna otra manera de conectar servicios entre sí, que no fueran las interfaces. Nada de conectarse directo a la base de datos, implementar puertas traseras, nada de ese tipo. (4) Un punto muy importante del mandato era que podían usar cualquier tecnología que los equipos considerarán para resolver un problema. Siempre y cuando, la comunicación fuera usando interfaces. (5) Algo crucial para el crecimiento de Amazon fue que sin excepción alguna, estas interfaces debían ser expuestas. O sea, el equipo tenía que planear, diseñar y desarrollar las interfaces para habilitar su exposición a desarrolladores en todo el mundo. (6) Por si fuera poco, quien no hiciera caso al mandato sería despedido.

El mandato API hace sentido para muchos desarrolladores de APIs, aborda puntualmente el desafío de muchas iniciativas.

Todos queremos crear soluciones innovadoras basadas en APIs, pero pocos son los que quieren invertir en crearlas.

Un producto que el cliente necesita

Una API que resuelva un problema

Cómo personas compramos productos para resolver un problema, esto es: contratamos la funcionalidad de un producto para que nos ayude a resolver nuestro problema de manera eficiente.

Imagina el siguiente escenario.

Tienes que manejar de tu casa a la oficina a las 5 de la mañana, un camino de 60 minutos, el cual tienes que realizar solo. Es un periodo de tiempo lo suficientemente largo para sentir pesado el trayecto y generar más cansancio. Existe la posibilidad de quedarte dormido y provocar un accidente. Por lo tanto, lo que haces es comprar un café con azúcar suficiente para mantenerte despierto. La funcionalidad que estás contratando del café es acompañarte para llegar al trabajo sano y salvo.

En un principio las APIs se crearon para resolver problemas técnicos, realizar integraciones complejas entre servicios o sistemas. Sucede que las APIs se han convertido en algo más que una solución técnica, se han convertido en un producto.

Un producto que debe conocer quién es su usuario, cuales son sus necesidades y cuando lo necesitan. Para lograr que las APIs sean un producto, debemos agregarle marketing, distribuirlas y que se puedan vender. Este proceso se conoce como Productize (Productificar).

Pilares de API como Producto

Un punto importante para mudar las APIs como un Producto, es tener presente tres pilares fundamentales:

Mercado y sus necesidades, quién será nuestro usuario. De manera interna el usuario es el desarrollador de APIs. Se tiene que mejorar la experiencia del desarrollador, creando excelente documentación, ejemplos descriptivos sobre cómo usar nuestro producto, me refiero a nuestras APIs. Y por supuesto, nuestro usuario final.

Objetivos del negocio, ¿Cómo una API como Producto puede llegar a beneficiar a la empresa? En la reducción del tiempo de liberación de un nuevo producto al mercado. En aumentar el valor de la marca al abrir nuevas líneas de negocio basadas en APIs

Funcionalidades clave y diferenciadores, ¿Cuáles serían las ventajas competitivas de desarrollar una API como Producto y diferenciarnos en el mercado? Exponer datos y servicios que son exclusivos de la empresa, puede sumar a nuestros partners via integraciones y en conjunto generar nuevos productos.

¿Cómo diseñar un Ecosistema API para uso interno y externo?

Una de las primeras razones o necesidades para crear un ecosistema es la unificación del negocio como una única plataforma tecnológica

Contrario a la creencia popular sobre la API economy, que en resumen trata sobre crear un modelo de negocio basado en las APIs de la compañía, publicarlas y esperar a que lleguen los consumidores de las API. La realidad es otra, (1) se tiene que iniciar un recorrido "de afuera hacia adentro" pensar en las necesidades del cliente. (2) De esa forma, la compañía debe empezar a identificar las funcionalidades clave que ofrece para crear diversas soluciones que generen valor a multiples clientes.

(3) Y en este punto, nos encontramos con dos lados de la moneda. Seguir por el camino de la API Economy, que es exponer nuestras capacidades y servicios core por medio de APIs. Y atender nuestras necesidades internas por medio de APIs privadas, (4) el cual requiere un proceso de reingeniería (As-Is, To-Be, To-Do) para realizar integraciones internas entre los sistemas de la compañía.

(5) Construir una API como Producto que evolucione a un Ecosistema API requiere tener paciencia, tiempo, dinero y un equipo de tecnología enfocado.

Conforme evoluciona y madura nuestra API como Producto, pensar en APIs para nuestros partners. Mejorar la experiencia del desarrollador. Y cuando llegue el momento, comenzar a construir SDKs. Claro, solo si eso resuelve las necesidades de nuestros clientes.

Colecciona, conecta, comparte