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".
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 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.
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.
0 Comentarios
Dejanos tu comentario para seguir mejorando!