Lienzo del modelo de API: la experiencia del desarrollador es un ingrediente clave de las API de calidad

 

Según The State of API Survey Report 2016 de Smartbear, casi el 85% de los encuestados está de acuerdo en que la calidad de la API es crucial para su organización. La misma encuesta identifica las tres razones principales que impiden que las organizaciones entreguen API de calidad son:

1) Aumento de la demanda de velocidad

2) Falta de integración entre herramientas y sistemas

3) Gestión de las expectativas de las diferentes partes interesadas

Se puede encontrar un remedio para la primera razón ajustando la arquitectura y optimizando el código. La segunda razón requiere un enfoque DevOps para las operaciones y las soluciones automatizadas, que en un punto de vista centrado en API se pueden etiquetar como APIOps . La tercera razón es un poco más complicada y se analiza en esta publicación. Parte de la solución es utilizar la idea todavía bastante nueva del API Model Canvas .

API Model Canvas - descendiente de Lean Canvas

El API Model Canvas debería ser familiar para las personas que comienzan, ya que se parece a Lean Canvas . El Lean Canvas propuesto por Ash Maurya es un enfoque para emprendedores y empresas emergentes que se centra más en los problemas que su antecesor Business Model Canvas. Los modelos Canvas tienen en cuenta las necesidades del cliente, obligan a que el diseño empresarial sea iterativo y desbloquean métodos de construcción rápidos y adaptables .

A primera vista, estas metodologías pueden parecer bastante similares. API Model Canvas está, como su nombre indica, más centrado en la economía de API y para situaciones en las que la API es un producto. Lo que diferencia a API Model Canvas de sus antepasados ​​es el enfoque en los desarrolladores , las estrellas de rock de la economía API.

Los desarrolladores son las estrellas de rock de la economía API

Reinterpretado del lienzo de Manfred Bortenschlager

 

La experiencia del desarrollador es un concepto al que se hace referencia en el mundo de las API con mucha frecuencia y por una buena razón. Los consumidores desarrolladores son el elemento vital de la economía basada en API. El API Model Canvas refleja esta importancia con tres secciones dedicadas a mantenerlos en el centro de atención: Relaciones con los desarrolladores, Programa de desarrolladores y Segmentación de desarrolladores.

Relaciones con los desarrolladores

Como lo ve Phillipp Schöne de Axway, los proveedores de API deben ir más allá de un excelente diseño y documentación de API , y trabajar para crear experiencias superiores de extremo a extremo:

“Si se encuentra en una situación competitiva, puede convertirse en un diferenciador tener una experiencia buena y bien pensada, incluso si el precio es un poco más alto. Cuando los proveedores de API consideran la experiencia del desarrollador, a menudo solo se tiene en cuenta el diseño de API, lo cual es incorrecto ".

Ejecutar una API con relaciones de desarrollo de calidad significa conocer íntimamente a su consumidor, sus necesidades y defenderlo en su nombre. Para la participación activa de la comunidad, Phillipp ve los hackatones como una "excelente manera de aprender lo que piensan las personas externas sobre su oferta ... comience con grupos más pequeños y aumente si se siente más seguro con su oferta".

Más sobre relaciones con desarrolladores: día en la vida de un desarrollador de API evangelista

Programa para desarrolladores

Mantener DX significa tener un enfoque de producto holístico para las API; parte de esto significa formar un equipo de producto interno, con la responsabilidad del mantenimiento y marketing del programa API. Sintonizar los comentarios de los consumidores es importante, pero Phillipp también cree que "si los proveedores 'comen su propia comida para perros', generalmente experimentan las advertencias y los obstáculos de su oferta con bastante rapidez".

Segmentación, orientación y posicionamiento de desarrolladores

Hemos visto cómo el mercado de consumidores de desarrolladores se ha diversificado en los últimos años. Al igual que con cualquier producto, se debe considerar la segmentación correcta. Esto implica una comprensión íntima de su consumidor y dónde encaja dentro de la economía API . La forma en que se dirige a desarrolladores específicos depende del mercado y la audiencia:

“Por ejemplo, si intenta crear algo específico para una vertical o un nicho, intente aprovechar foros, sitios web y eventos específicos de la industria para promover la idea. Si se dirige a una audiencia más amplia, es más complicado y tiene que buscar desarrolladores que sientan más dolor y se beneficien más de su servicio ".

Schöne añade que recopilar rápidamente las referencias y los testimonios de los clientes es fundamental para establecer una imagen de buena reputación.

Abordar todo el lienzo del modelo de API

El API Model Canvas es fácil de seguir y completar. Tener respuestas breves para cada sección puede ayudarlo a concretar sus propuestas de valor y estrategias específicas. No debe hacerlo solo o completar todo como si estuviera escribiendo un ensayo, sino que debe estar diseñado en equipo.

Más importante aún, no diseñe un modelo de negocio API solo en el cubículo de la oficina. Debe involucrar al personal de TI, al personal de estrategia empresarial y a algunos desarrolladores de los clientes candidatos. Debido a que se espera que su API aporte valor a estos clientes, el objetivo principal debe ser resolver su problema y resolverlo bien.

Estudio de caso: Biblioteca Nacional de Finlandia

El uso del API Model Canvas ha sido un activo probado en varios equipos. Uno de los últimos equipos en utilizarlo fue la Biblioteca Nacional de Finlandia. Tienen millones de objetos de datos sobre revistas y periódicos finlandeses que datan del siglo XVII. Toda esta información necesitaba ser accesible de manera que los editores de periódicos, investigadores y ciudadanos actuales pudieran consumir de manera eficiente. En resumen, necesitaban una API de calidad.

El proyecto fue un proceso de tres pasos, con el API Model Canvas utilizado en la segunda fase:

• Defina una estrategia de API. Evidentemente la estrategia surge de la organización, que en este caso era la Biblioteca Nacional de Finlandia.
• Utilice API Model Canvas para crear un modelo de negocio para las API necesarias.
• Describir API con lenguaje basado en diseño como RAML o Swagger.

Por supuesto, una vez finalizado el diseño y probado con un servidor de maquetas, la API también debe implementarse. Para este proyecto, decidimos dejar la implementación en esta etapa y enfocarnos en el modelo de negocio y el diseño de API.

MVP para el siguiente paso

Durante el primer campamento de APIOps, no revisamos todas las casillas del API Model Canvas. En su lugar, adoptamos un enfoque de puesta en marcha ajustada y comenzamos desde el medio en "Estrategia para la API y los objetivos". Después de eso, saltamos las cajas para recopilar un Producto mínimo viable (MVP) para el siguiente paso. Esto fue posible porque teníamos experiencia en el desarrollo de estilo Lean Startup y modelos de lienzo. Por ejemplo, no tocamos "Estructura de costos", "Programa para desarrolladores" o "Relaciones con desarrolladores" en este momento.

La idea era recopilar la información suficiente para la próxima iteración de la descripción Swagger de la API y no planificar nada innecesario. En el proceso, se identificaron dos colecciones a partir de datos y comentarios recopilados de los consumidores de datos: periódicos y revistas. En base a eso, decidimos definir interfaces de lectura para ambos con una estructura similar. En la práctica, primero definimos los puntos finales de los periódicos y luego clonamos la estructura en el diseño Swagger. No tocamos las interfaces de escritura en absoluto, ya que redujimos el alcance a solo los consumidores de API y excluimos a los administradores de datos.

Después de agregar algunos puntos finales básicos a la API, recopilamos comentarios de los desarrolladores con los que nos habíamos comprometido anteriormente. Incluir a los consumidores de API en la fase de diseño de API nos brindó información sobre lo que buscaban los desarrolladores en la documentación, y arrojó información sobre las palabras clave y el estilo de escritura que llamaron su atención. También convenció a The Library of Finland de profundizar en DX que solo proporcionar buena documentación: ejemplos de código para utilizar API, descripciones de casos y brindar soporte al cliente. En otras palabras, el cliente entendió la necesidad y el valor de un portal para desarrolladores adecuado .

Este ciclo va y viene: completando y alterando el API Model Canvas , volviendo al diseño de Swagger y las pruebas de desarrolladores. Después de algunas rondas, tendrá un plan de negocios sólido y un diseño de API dorado que adoran los desarrolladores . En ese momento, está listo para implementarlo.

Más sobre modelos comerciales : ciclo de vida de API: preparación de su estrategia previa al lanzamiento

Gana velocidad y hazlo divertido

API Model Canvas es una herramienta importante y en este caso particular funcionó muy bien. Para un equipo con una mentalidad de startup y familiarizado con Lean Canvas, comenzar es fácil. Al final del día, API Model Canvas puede hacer que el diseño de modelos de negocio sea divertido; incluso las personas que participan en este tipo de proceso por primera vez verán API Model Canvas como una herramienta sólida para el diseño empresarial centrado en API.

La incorporación de desarrolladores externos en el proceso de modelado desde el principio elimina el riesgo de perder su enfoque en la experiencia del desarrollador . Tenga en cuenta que los desarrolladores son las personas a través de las cuales llegará a acuerdos comerciales y convencerá a los gerentes de nivel superior. Si los desarrolladores odian su API, perderá ingresos; cada desarrollador perdido es pérdida de ingresos.

Pensamientos finales

Existen muchas teorías sobre el modelado de negocios API; La filosofía de práctica de las API nórdicas, por ejemplo, implica 6 principios básicos . Ya sea siguiendo estos Insights, el API Model Canvas u otros conjuntos de herramientas, Phillipp señala que "la verdadera importancia es que el proveedor de API comience a pensar en las diferentes dimensiones e implicaciones de su API". Para él, los rasgos principales que debe considerar un diseño de MVP de API ajustada son:

• Idea y preparación del producto
• Proyecciones de monetización y crecimiento
• Aspectos legales: ¿existen obligaciones legales o mandatos regulatorios de los que debamos preocuparnos?
• Preguntas de infraestructura: cómo conectarnos a fuentes de datos existentes, cómo gestionamos los consumidores de API, cómo queremos escalar, cómo supervisamos nuestro SLA y la calidad del servicio.
• Preguntas de seguridad: ¿necesitamos medidas de seguridad como la limitación de velocidad y otros mecanismos de protección y cómo las aplicamos?
• Preguntas de backoffice: ¿cómo facturamos a nuestros consumidores?
• Preguntas de marketing: ¿cómo promocionamos nuestro producto y cómo podemos impulsar su adopción?

Listas como estas continúan y se pueden ampliar fácilmente. Modelar una empresa en torno a una API puede parecer abrumador, pero el proceso es realmente similar al de desarrollar otro software o productos. Muchas áreas requieren una mejora continua , por lo que la estrategia APIOps es tan útil, ya que los servicios de desarrollo y ejecución se pueden basar o automatizar completamente con API.

Para obtener más información sobre DX, DevOps y la estrategia de API, asista a nuestra API Stack Conference, que contará con charlas de Jarkko Moilanen, Phillipp Schöne y otros expertos en API.