Header Ads Widget

Ticker

6/recent/ticker-posts

Arqueología de API: uso de API accidentales para informar el viaje de API

 



Las grandes organizaciones a menudo hablan de "comenzar su viaje de API" como si aún no tuvieran API. En un sentido estricto de la palabra, esto puede ser cierto si consideramos las API como algo que (a) está diseñado para su reutilización y (b) que está diseñado como una interfaz en red (dos aspectos fundamentales de las API que señalo en un video sobre qué es una API ).

Pero también podemos ver las API en un sentido más pragmático: ¿para qué se utilizan ? Hablando en términos generales, las API se utilizan para interconectar componentes para realizar tareas o implementar procesos que abarcan más de un componente individual. Si observa las API desde este ángulo, puede identificar muchas " proto-API" que pueden no utilizar la tecnología y los estándares que tenemos hoy, pero que fueron creadas con el mismo espíritu de interconexión de componentes. Estas proto-API logran objetivos comerciales similares y abarcan más de un componente. Los ejemplos típicos de estas proto-API incluyen:

  • Transferencia de archivos : la transferencia de archivos es la forma más antigua de hacer que los sistemas intercambien datos. Todavía se usa ampliamente, aunque hoy en día a menudo se incluye en sofisticadas soluciones de transferencia de archivos administradas que brindan capacidades de seguridad y administración que van mucho más allá de mover archivos manualmente entre componentes.
  • Integración de datos : Un paso adelante de la transferencia de archivos son las actividades de integración en las que dos componentes están habilitados para comunicarse sin el desvío del archivo, pero con la ayuda de un intermediario. La versión empresarial a menudo se conoce como Extraer, Transformar, Cargar (ETL) ETL logra interconexiones haciendo que un componente exporte los datos, masajeándolos para que otro componente pueda leerlos y enviándolos a otro componente para que los comprenda. Este es un proceso asincrónico y es un patrón que todavía se usa ampliamente para interconectar componentes.
  • Integración de aplicaciones : en este caso, los componentes se comunican de forma síncrona, pero aún con la ayuda de un intermediario que proporciona la conectividad en ambos extremos. Hay muchos nombres para estos intermediarios; middleware y Enterprise Service Bus (ESB) son dos populares. Al final, estos intermediarios no son tan diferentes de ETL, pero en lugar de hacerlo en modo por lotes, admiten interacciones sincrónicas.

Las API son un poco diferentes de estos enfoques porque en lugar de centrarse en conexiones 1: 1 (asíncronas en el escenario de transferencia de archivos y síncronas en el escenario de integración de aplicaciones), se centran en conexiones 1: n. Las API también asumen que los componentes están diseñados para comunicarse con otros componentes, eliminando la necesidad de métodos tradicionales.

Pero este artículo no trata de explicar las API o sus ventajas. Se trata de mostrarte un buen camino para tu viaje de API. La observación importante aquí es que ya tiene un panorama de componentes de comunicación ; puede darse el caso de que esos componentes no utilicen la forma más moderna de comunicarse. Podemos llamar a estas rutas de comunicación existentes " API accidentales " , porque alguien creó un canal de comunicación, pero no de la mejor manera posible (dado lo que sabemos hoy sobre las ventajas de las API).

Podría pensar que descubrir API accidentales es un experimento mental interesante, pero no tan consecuente. Sin embargo, analizar sus sistemas de comunicación de esta manera trae muchos beneficios. Muestra cómo fluye actualmente el valor en su organización. Revela cuellos de botella y posibles formas de eliminarlos. Al involucrar a los co-conspiradores para optimizar la infraestructura, su organización se vuelve más competente en su conjunto. Al final, estas acciones desbloquearán gradualmente más y más valor que actualmente está atrapado en los silos de su organización.

Comenzando su viaje de API

Antes de entrar en detalles: este artículo lo alienta a comenzar finalmente con su viaje de API si aún no lo ha hecho. Le anima a mirar todas las cosas que ya están en su lugar y mantener su organización en funcionamiento. Pero también lo alienta a analizar críticamente lo que puede estar frenando y cómo puede abordarlo. Lo digital no tiene por qué ser disruptivo , pero requiere la voluntad de cambiar y comprender los mayores obstáculos que lo están frenando. Debes empezar con algo pequeño pero pensar en grande. Una inversión futura en API probablemente se verá impulsada por la observación de sus prácticas actuales y las oportunidades que identifique.

También es importante enfatizar que las API son un componente esencial de su viaje digital, pero no son lo único importante. Las API no resolverán todos sus problemas , aunque son un aspecto necesario para resolver muchos de ellos. Aún debe dar un paso atrás para ver los problemas empresariales y organizativos, y sin solucionarlos, no puede esperar que su viaje de API brinde el valor que espera de él. Dicho esto, ¡profundicemos en la arqueología de API!

API Arqueología : la arqueología es la práctica de desenterrar artefactos y comprenderlos en el contexto de sus orígenes en el tiempo y la ubicación. Ese concepto exacto también se puede aplicar a las API. La arqueología de API, por lo tanto, es la práctica de encontrar integraciones, comprender por qué y cómo se crearon y documentarlas como una forma de comprender mejor la historia y la estructura de sistemas de TI complejos. La práctica de la arqueología de API en las organizaciones puede ser extremadamente valiosa en términos de conocer las formas existentes en las que los componentes de TI interactúan (de alguna manera o forma).

Analizar el flujo de valor

La idea principal detrás de la arqueología de API (como se introdujo en Continuous API Management ) es que al analizar las interconexiones existentes, se obtiene una imagen excelente de dónde fluye el valor en la organización. Cada proto-API existente es una indicación de que la interconexión se consideró lo suficientemente valiosa como para invertir en esfuerzos de integración 1: 1. Por supuesto, puede que no esté claro si ese valor percibido se realizó alguna vez. No obstante, comprender su historia es un poderoso punto de partida para comprender el estado actual y decidir sobre futuras inversiones para la modernización del panorama organizacional.

Antes de comenzar a asignar valores a las interconexiones existentes, suele ser una buena idea crear algún tipo de catálogo imparcial que sirva como punto de partida. No hay necesidad de obsesionarse demasiado con que este catálogo esté completo: podría llevar mucho tiempo encontrar todas las interconexiones existentes. Por otro lado, muchas organizaciones ya tienen alguna forma de esto, por lo que tal vez pueda usar esto como un punto de partida en lugar de tener que investigar mucho usted mismo.

Identificar cuellos de botella y potencial

Una vez que comprenda los flujos de valor en toda la organización (y con sus socios), ahora es el momento de comenzar a evaluar qué tan bien están funcionando las cosas. Hay dos cosas principales a tener en cuenta cuando se trata de identificar posibles cuellos de botella:

  • Calcificación de la integración: muchas "integraciones de la vieja escuela" eran proyectos únicos que conectaban componentes. Estas integraciones luego se calcificaron. Debido a su construcción personalizada, es difícil realizar cambios en ambos lados, lo que significa que tanto el proveedor como el consumidor tienen dificultades para realizar cambios porque temen romper cosas. En el diseño de sistemas, esto se denomina acoplamiento estrecho porque los componentes están acoplados a través de muchas facetas diferentes de su interconexión. Las API tienen una sólida cultura de acoplamiento flexible , lo que facilita el cambio de componentes sin romper las interconexiones existentes.
  • Potencial de reutilización : algunas interconexiones existentes pueden tener un potencial evidente de reutilización. Por ejemplo, si tiene datos sobre productos, clientes e historiales de compras, es posible que estos datos se incluyan actualmente en catálogos de productos y sistemas de contabilidad. Si esa información fuera accesible de manera más abierta, es posible que pueda incorporarla en los componentes de análisis y aprendizaje automático para comprender mejor a sus clientes y sus compras. Cuanto más fácilmente se pueda consumir este tipo de información, más fácilmente podrá construir estas nuevas interconexiones. La reutilización facilita la mejora de las cadenas de valor y elimina los costosos proyectos de integración únicos.

El propósito de este paso es permitirle identificar el potencial de las inversiones en API. En muchas organizaciones grandes y antiguas, no es realista trasladar todas las interconexiones existentes a enfoques basados ​​en API. Por lo tanto, es vital comprender cuáles tienen el mayor potencial para desbloquear nuevos valores cuando los progresa a las API. Sin embargo, como cualquier esfuerzo de modernización, los viajes de API son un arte. Dado que, por definición, todas las interconexiones involucran más de un componente, la siguiente consideración es cómo lograr que los equipos participen.

Involucrar a los co-conspiradores

La propuesta de valor de las API es fundamentalmente diferente de los enfoques de integración tradicionales. En los enfoques de integración convencionales, las organizaciones crean valor interconectando componentes, y tanto la interconexión como el valor realizado se conocen porque es un sistema cerrado.

Para las API, el valor es una propuesta abierta. Aunque las API pueden estar diseñadas para una pequeña base de consumidores inicial, idealmente, son útiles y también están disponibles para otros consumidores. Esto hace que la propuesta de valor y el cálculo sean un poco más complicados. Por lo tanto, siempre es mejor crear un MVP para un subconjunto de consumidores iniciales para que no tenga que "diseñar en el vacío".

Esta observación general de cómo identificar y crear API valiosas también es válida para nuestro escenario de arqueología de API. En estos escenarios, es importante ubicar a los consumidores que deseen y puedan trasladar sus interconexiones a las API. Al identificar a estos consumidores e incluirlos en su proceso de diseño, asegúrese también de estar atento a las pautas de su API. Después de todo, desea que estas nuevas API estén en línea con el panorama de API que está administrando, lo que significa que la coherencia a nivel del panorama debería convertirse en parte del proceso de diseño.

Cada integración preexistente que puede retirar debido a una API es una victoria. Significa que ha obtenido un valor adicional a lo largo de tres ejes:

  • Su capacidad para cambiar : al pasar a una API, la integración ahora se basa en un contrato bien definido y no en una implementación específica. Esto significa que puede realizar cambios en el lado del proveedor de API, siempre que siga cumpliendo el contrato. Incluso puede cambiar completamente la implementación si eso es lo que desea hacer.
  • La capacidad de cambio de su consumidor : al cambiar al acoplamiento flexible, su consumidor ha realizado el mismo cambio que usted: la interconexión ahora se basa en un contrato, no en la implementación. Pueden hacer cambios si es necesario, y es posible que usted ni siquiera sepa sobre esto, y no tiene que participar.
  • Habilitación de otros consumidores : dado que ahora hay un contrato para la interconexión, otros también pueden usarlo. Por supuesto, tiene que haber mecanismos de seguridad y controles de acceso a nivel técnico para asegurar la API. Pero si existe una razón comercial para permitir que otros accedan a la API, no es necesario cambiar nada en el lado del proveedor y luego puede comenzar a consumir la API.

Si observa estas ventajas con atención, notará que giran en torno al contrato que representa la API. Esto también es un fuerte indicio de que este contrato debe estar bien diseñado. No caiga en la trampa de simplemente construir una API que represente directamente lo que se intercambió en el antiguo método de interconexión. En su lugar, realice un proceso de diseño adecuado que le permita identificar cuál es el valor y la mejor manera de representar ese valor en una API extensible y bien diseñada.

Liberar, darse cuenta, responder, repetir

Como se mencionó en la última sección, es una buena idea identificar algunos candidatos iniciales con una buena propuesta de valor y co-conspiradores dispuestos. Este enfoque le permite comenzar rápidamente, aprender a lo largo del camino y mejorar su efectividad.

  • Lanza la API lo antes posible para que puedas probar las operaciones y saber qué tan bien funciona para el consumidor. Considere formas de mejorar la experiencia del desarrollador y cómo pueden ser compatibles las herramientas de API y una plataforma de API.
  • Obtenga el valor de la API asegurándose de que sea administrada de manera efectiva y que sea visible para aquellos que quieran usarla.
  • Responda a los comentarios de los desarrolladores sobre el comportamiento específico de la API, así como las brechas funcionales. Esta retroalimentación ayudará a mejorar las API o volver a priorizar las API que cree. Dado que las API deben respaldar las cadenas de valor, la escucha atenta es fundamental para mejorar la asignación de recursos.
  • Repita este proceso cubriendo gradualmente más interconexiones y moviéndolas a API. Como cualquier esfuerzo de modernización, esto llevará un tiempo, pero en este caso, es crucial comenzar lo antes posible para que pueda aprender de sus propias experiencias y los comentarios de los demás.

Con este enfoque iterativo, puede asegurarse de que su modernización comience más rápidamente, se autoajuste a medida que avanza y esté impulsada por comentarios que le permitan realizar las inversiones más valiosas. Es poco probable que las API finalmente reemplacen todas las interconexiones que tiene, pero ese no debería ser el objetivo, para empezar, de todos modos. El propósito de este enfoque es desbloquear el valor que actualmente no se realiza en su panorama organizacional , que realmente debería ser la principal medida del éxito.

Conclusiones

La arqueología de API no es algo fundamentalmente nuevo, pero sigue patrones y experiencias que hemos visto en nuestro trabajo con muchas organizaciones grandes. Con suficiente investigación, todas las organizaciones de hoy se convierten en un panorama complejo de proto-API. Comprender este panorama es esencial para dirigir las inversiones cuando se trata de comenzar con el viaje de la API.

Uno de los errores que vemos es que las organizaciones a menudo abordan su viaje de API en una "cascada", haciendo planes e inversiones de gran alcance para su panorama de API. Aunque el resultado es un cambio de TI fundamental, el viaje de la API en sí debe tratarse como un proceso evolutivo que cambia lenta pero seguramente el enfoque organizacional y la mentalidad cuando se trata de crear y administrar cadenas de valor.

Habiendo dicho todo esto, tenga en cuenta que la arqueología de API es solo una llave en la caja de herramientas del profesional de la transformación digital. Como se mencionó anteriormente, los desafíos empresariales y organizacionales también deben abordarse. Y como todo lo que comienza en el pasado, si bien es útil desarrollar un sentido de cómo mejorar el conjunto actual de componentes interconectados, no olvide que puede haber un potencial igualmente grande para habilitar cadenas de valor completamente nuevas que no se reflejan en el panorama organizacional actual.

Publicar un comentario

0 Comentarios