Eventos globales como la pandemia, la situación económica mundial y conflictos geopolíticos, han resaltado las debilidades del modelo de negocio de muchas empresas que fueron rentables y “eficientes” prepandemia.

De momento se volvieron lentas, frágiles… Cuando tenían que demostrar flexibilidad y capacidad para innovar.

El contexto mundial actual está empujando a las empresas a tomar decisiones más rápido y mejor informadas para sobrevivir a un mundo tan cambiante. Con un tiempo relativamente corto después de COVID-19, las empresas deben actuar, definir una estrategia y tácticas, antes de recibir otro golpe como la pandemia.

Acelerar es crucial para permitir a las empresas sobrevivir en situaciones adversas. Cuando todo va bien se generan falsos positivos que esconden las debilidades de los cimientos del modelo de negocio.

Procesos operativos que funcionaron en el pasado, se vuelven obsoletos. Las empresas deben innovar rápido, adaptar su propuesta de valor y reensamblar sus capacidades desde dentro y fuera de sí mismas.

Para lograr esto, las empresas deben ofrecer valor comercial y adaptarse al ritmo acelerado del negocio, o sea ser un Composable Business.

Composable Business, aceleración natural.

De acuerdo a Gartner analysts

 Diseñar para la resiliencia y aceptar que el cambio disruptivo 
 es la norma.

De acuerdo a la wikipedia

Composability es un principio de diseño de sistemas que se ocupa en las interrelaciones entre componentes, para que se puedan ensamblar en diversas combinaciones para satisfacer las necesidades del cliente / usuario.

En tiempos de pandemia y crisis económica, las empresas deben estar preparadas y ser rápidas, mucho más rápidas que la competencia, para adaptarse a la disrupción creada por la crisis o no, tal vez sean tiempos de oportunidades.

Entonces, Porqué ser un Composable business?

1. Para no desaparecer en una crisis mundial
2. Para crear nuestras propias oportunidades de negocio

Es responsabilidad de los directores realizar un cambio dentro de la empresa y considerar la “APIficación” del negocio o arriesgarse a que la empresa sufra o termine desapareciendo.

API centrada en el cliente para abrir nuevos mercados

vía APIStrat 2016: Moving Toward a Modular Enterprise

La API dentro de un Composable Business se enfocan en liberar las capacidades core y técnicas del negocio para crear nuevas soluciones para los clientes de los diferentes tipos de usuarios de la API.

A ellos no les importa la parte técnica, lo que quieren es tener acceso vía una API al valor ofrecido por un Composable Business para solucionar un problema de su cliente.

Como arquitecto, se deben enfocar en ambos aspectos: capacidades core y técnicas del negocio. Esto requiere un diseño de API enfocado para ofrecer los resultados deseados y no solo datos.

Y si la API será tratada como un producto, primero se debería diseñar. Si, API First se refiere a diseñar / definir los contratos como la primera tarea a realizar.

Por lo tanto, una API es una parte del “vehículo” para crear una API como Producto.

API como Producto

Una API como Producto monetiza y expone los servicios y funcionalidades core y técnicas del negocio. O sea, una API permite la integración entre un sistema A y un sistema B, pero para ser considera un producto debe ser monetizada.

Tratar una API como Producto significa que vamos a permitir a desarrolladores externos, basarse en nuestra API generar las soluciones que requieran. Sean publicas o privadas.

¿Cómo pasar de una API a un Producto?

1. Identificando las capacidades core y técnicas del negocio, que lo diferencia de la competencia
2. Creando un “vehículo” que permita el acceso a las capacidades del negocio, parte de este “vehículo” son la API
3. Identificando los tipos de usuarios de la API, empezando por los usuarios internos, o sea, los desarrolladores.
4. Comerse su propio comida de perro, o sea, crea una API privada.
5. Escuchando las necesidades de los partners para permitir construir sobre la API como Producto
6. Crea una API pública, otorgar el permiso a desarrolladores externos a construir nuevas soluciones que no se le ocurrieron al negocio.

¿Como ofrecer la mejor experiencia a nuestros usuarios (desarrolladores internos y externos)?

1. Conociendo el sentimiento del desarrollador al usar la API.
2. Fácil de entender: documentando la API de manera precisa.
3. Fácil de usar: reduciendo la escritura de código creando herramientas (SDKs, API Console, etc) que faciliten la inmersión inicial.
4. Fácil de depurar: dar feedback sobre los errores ocurridos en las peticiones realizadas vía un API Dashboard.
5. Fácil de obtener ayuda: dar rápido acceso al equipo de soporte de API
6. Ayuda a tus usuarios a contribuir a la comunidad.

Sigue iterando, sigue creciendo

Las crisis llegan en momentos inesperados, las oportunidades se toman de mejor forma cuando estamos preparados. Contar con una primera versión de API, no significa que se ha terminado el trabajo. Continua escuchando a los usuarios de la API como Producto, itera y crece constantemente.

Genera valor, Monetiza tu API.

Contáctame:

https://www.linkedin.com/in/jyrgaxiola/

Las APIs se han convertido en algo más que una solución técnica, se han convertido en un producto.

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