La mentalidad de plataforma en la gestión de productos API

No es ningún secreto que la pandemia amplificó significativamente la necesidad de que las organizaciones adopten una estrategia digital primero. Las transformaciones digitales a las que se les había quitado prioridad en favor de otros objetivos organizacionales cambiaron al frente y al centro de la noche a la mañana, con una urgencia sin precedentes. Según una encuesta global de ejecutivos de McKinsey de 2020, las empresas aceleraron el ritmo al que digitalizaron las operaciones internas y ampliaron las carteras de productos digitales en varios años, a pesar de los importantes desafíos que plantea el COVID-19.

En el corazón de estas transformaciones digitales se encuentra la integración, facilitada por las interfaces de programación de aplicaciones (API). Antes consideradas simplemente como "mensajeros" o "intermediarios" que transmitían datos entre sistemas de software, las API ahora se reconocen como el "tejido conectivo" de los ecosistemas digitales, que ofrecen integración ilimitada y oportunidades comerciales a las organizaciones que las crean y las aprovechan. Debido al potencial único que representan las API, los gerentes de productos que supervisan su desarrollo deben adoptar un enfoque que desbloquee su valor latente, que enfatice la flexibilidad y la extensibilidad para garantizar experiencias de integración perfectas.

Hacer más con menos

Incluso antes del último año sin precedentes, el valor de las API para las organizaciones estaba bien documentado y la economía de las API había estado prosperando durante algún tiempo. Para comprender el panorama actual de las integraciones, es útil explorar los orígenes de la filosofía Best of Breed (BoB). Antes de la década de 1990, los proveedores de software comercializaban soluciones de conjuntos de planificación de recursos empresariales (ERP) que intentaban resolver una amplia variedad de desafíos organizacionales. Cada vez más, estas suites llegaron a ser vistas como engorrosas y poco prácticas, porque no abordaban los casos de uso específicos de la organización. Como resultado, los proveedores comenzaron a crear herramientas más enfocadas que resolvían los desafíos de un área funcional, en lugar de suites más grandes que intentaban hacer todo para todos. Las empresas aceptaron la idea de elegir entre una variedad de herramientas más pequeñas y especializadas y comenzaron a ensamblar colecciones de soluciones individuales que mejor se adaptaban a sus necesidades particulares.

Conectando los puntos

A medida que el enfoque BoB ganó fuerza, las integraciones se convirtieron en una parte crucial de las estrategias de productos. Una herramienta que fuera excelente para resolver problemas en un área de una empresa tenía que poder integrarse bien con otros productos de BoB que probablemente se utilizarían junto con ella. Considere HubSpot, el software de ventas y CRM implementado por las organizaciones para rastrear y optimizar sus canales de ventas y relaciones con los clientes. HubSpot se integra fácilmente con otro software BoB como DocuSign (firmas digitales), Twilio (notificaciones por correo electrónico/SMS) y Zendesk (atención al cliente) sin necesidad de desarrollo adicional por parte de los equipos de ingeniería del cliente.

La necesidad de herramientas complementarias para conectarse sin problemas entre sí estuvo acompañada de un cambio en toda la industria hacia la adopción de la apertura en lugar de limitar las interacciones entre los sistemas. En algún punto del camino, la cantidad de integraciones admitidas por un producto se convirtió en una métrica que valía la pena comercializar.

La propuesta de la plataforma

Sin embargo, el verdadero valor de las integraciones va más allá de su capacidad para coordinar herramientas y sistemas dispares. En el mejor de los casos, las API son el mecanismo colectivo para convertir productos en plataformas. Los productos, por definición, son herramientas que tienen una aplicación específica; por lo tanto, "aplicaciones". Tienen una capacidad limitada para crear múltiples propuestas de valor y, por extensión, múltiples fuentes de ingresos. Las plataformas, por otro lado, agregan valor de una manera diferente: proporcionando la capa de infraestructura sobre la cual se pueden construir numerosos productos.

Las API abren nuevos canales comerciales al capitalizar la experiencia de los terceros que las aprovechan. Los desarrolladores consumidores pueden diseñar una aplicación inmobiliaria que utilice las API de lugares de Google Maps para ayudar a los usuarios a buscar una casa, o pueden aprovechar las API de vuelo de Skyscanner y las API de hotel de Expedia para crear un sitio de ecoturismo que se especialice en viajar a un lugar específico. Estos desarrolladores y socios externos se benefician al obtener acceso a datos y servicios existentes que pueden adaptar para sus negocios, y los propietarios de API como Expedia amplían su alcance y monetizan oportunidades que no existirían si continuaran, por ejemplo, enumerando solo hoteles en su producto.

Haciéndolo modular

Para los líderes de productos, desarrollar una estrategia de API exitosa requiere un cambio de mentalidad del pensamiento de producto al pensamiento de plataforma. Esto significa crear productos de forma modular y abierta que permita recombinar su funcionalidad y que priorice la flexibilidad para los desarrolladores consumidores. Piense en los sistemas de estanterías de IKEA, que los clientes pueden comprar, ensamblar y personalizar de diferentes maneras para satisfacer una variedad de necesidades. Los buenos gerentes de productos de API ven las API por lo que son: herramientas para escalar el negocio y desarrollar asociaciones valiosas. Reconocer este potencial significa implementar las mejores prácticas para garantizar la adopción.

Deleitando a los desarrolladores

Si hay un pilar fundamental de una estrategia de API sólida, es la experiencia del desarrollador (DX). Para las integraciones de API, los gerentes de producto de los "clientes" deben deleitar a los desarrolladores consumidores. Estos son los usuarios que finalmente llaman/se integran con una API, los socios potenciales que pueden ayudar a realizar una visión de producto a plataforma. Etiquetar su experiencia como "DX" en lugar de "UX" reconoce que no son usuarios finales típicos, son significativamente más expertos técnicamente. Para empatizar con ellos, es fundamental comprender sus necesidades y expectativas específicas.

Mejores prácticas

Las siguientes, aunque de ninguna manera representan una lista exhaustiva, son prácticas esenciales para crear API de primer nivel que garanticen experiencias de integración predecibles, consistentes y sin fricciones para los desarrolladores consumidores. Los gerentes de productos deben abordar el diseño de API de manera escalable, definiendo un marco de mejores prácticas y publicándolo como un documento que los equipos pueden consultar al crear nuevas API.

Convenciones de nomenclatura y puntos finales coherentes

Establecer convenciones de nomenclatura coherentes para los extremos de la API que identifiquen claramente la naturaleza y el propósito de la API elimina la ambigüedad y contribuye a una DX positiva y predecible. Lo mejor es elegir una URL base común para todas las API y un marco para la URL final que evite la jerga y las abreviaturas. Nordic APIs ofrece una lista útil de consejos para nombrar puntos finales.

Estructuras detalladas de respuesta de éxito y fracaso

Los desarrolladores quieren y esperan objetos de datos familiares y códigos de estado para respuestas de éxito y fracaso. Eso significa un código de estado 2xx para escenarios de éxito, un código 4xx para fallas del lado del cliente y un código 5xx para errores del lado del servidor. Sin embargo, la especificidad es clave. Una llamada a una API de "envío de correo electrónico" que simplemente devuelve una respuesta 4xx sin información adicional hace que la experiencia del desarrollador sea deficiente, porque simplemente confirma que el error estaba en la solicitud del cliente sin brindar información adicional sobre qué salió mal exactamente.

 { "status": 400, "message": "incorrect request" }

Por el contrario, una respuesta que ofrece detalles específicos en formato legible por humanos y en forma de un código de error único puede ayudar a los desarrolladores a decidir rápidamente cómo rectificar el escenario de error, escribir código para abordar el problema y volver a intentar la llamada a la API.

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

Para una DX óptima, las estructuras de respuesta y las claves que comunican el estado deben ser coherentes en todas las API. Por ejemplo, el campo de código de error en lo anterior debe denominarse invariablemente "código" en cada API, no "código" en algunas API y "código de error" en otras.

Límites de tasa configurables

Los límites de velocidad gobiernan qué tan accesible es una API al determinar cuántas veces un usuario puede llamarla en una sola unidad de tiempo. Los límites de velocidad que son demasiado altos pueden inundar los sistemas con una cantidad inmanejable de solicitudes que degradan el rendimiento, mientras que los límites de velocidad excesivamente bajos pueden hacer que las transacciones pendientes se acumulen en la cola de los sistemas de los usuarios. Ambos contribuyen a un DX deficiente. Al diseñar API, es mejor permitir límites de velocidad que se puedan ajustar en función de circunstancias y casos comerciales específicos. Los clientes de gran volumen, por ejemplo, pueden tener una necesidad genuina de llamar a las API con más frecuencia.

Para determinar mejor los límites de velocidad apropiados, es útil agrupar primero las API en categorías significativas de acuerdo con la frecuencia y el volumen con el que se llaman. Por ejemplo, las API que configuran los datos principales del cliente (perfil/creación de cuenta) se llaman con menos frecuencia y pueden manejar límites de tasa más bajos, mientras que las API de transacciones ("crear pedido", "enviar correo electrónico") se llaman con más frecuencia y requieren límites de tasa más altos. Establecer categorías o niveles para diferentes casos de uso hace que las API sean más confiables y escalables. Para ver un ejemplo de límites de frecuencia claramente definidos, consulta la documentación de la API de Slack.

Documentación completa

La documentación sirve como manual de usuario para una API. Explica claramente a los desarrolladores qué hace una API, cómo usarla y qué esperar de ella. La buena documentación está escrita en un lenguaje claro y accesible, es detallada e interactiva y ofrece muchas demostraciones y fragmentos de código para simplificar la integración. De esta manera, facilita la incorporación fácil y un tiempo rápido para el primer saludo mundial (TTFHW), una métrica importante que representa la rapidez con la que un desarrollador puede llamar con éxito a su primera API.

La documentación debe identificar claramente qué campos en la solicitud de API son obligatorios y cuáles son opcionales, así como la longitud mínima y máxima y el tipo de datos para esos campos. Esencialmente, debe incluir todo lo necesario para establecer expectativas y eliminar obstáculos para los desarrolladores consumidores. Los desarrolladores que crean esquemas de bases de datos en sus sistemas, por ejemplo, no deberían tener que ajustar posteriormente la longitud de las columnas en las tablas porque la documentación no especificaba los parámetros.

La documentación de la API puede aumentar la adopción no solo al servir como una referencia confiable para los desarrolladores consumidores, sino también al actuar como una herramienta de marketing para la propia API. A menudo, la primera persona que se encuentra con la documentación de la API es una parte interesada orientada al negocio, que la examina durante las fases iniciales de la evaluación del producto. Por lo tanto, no solo debe incluir detalles sobre los elementos técnicos de la API, sino que también debe articular claramente los casos de uso comercial que la API hace posibles.

Hay una serie de herramientas en el mercado que pueden ayudar a generar una documentación API completa. También es útil revisar ejemplos de documentación de alta calidad, como la de Stripe.

Reuniéndolo todo

Las integraciones representan un vasto dominio con muchos componentes, pero comprender los principios básicos de una buena API es fundamental para desarrollar una estrategia sólida. Las API son mucho, mucho más que meros conectores del sistema. Son los componentes básicos de las redes digitales expansivas y las claves para abrir nuevas fuentes de ingresos y liberar valor sin explotar. Debido a esto, una estrategia de API exitosa no se trata solo de crear productos; se trata de construir potencial. Un gerente de producto de API debe adoptar una mentalidad de plataforma y priorizar los factores que facilitarán la adopción para los socios potenciales que luego pueden tomar su API, integrarla y ejecutarla.