Header Ads Widget

Ticker

6/recent/ticker-posts

Escalando su legado: cómo las API internas ayudan a la transformación digital

 Adriano Mota, arquitecto de soluciones de Ford Motor Company, demuestra cómo una estrategia interna de primera API ha impulsado sus esfuerzos de transformación digital. 


La transformación digital permite a las empresas acelerar modelos antiguos que necesitan modernizarse, ayudándoles a afrontar nuevos mercados globales. Mantener la agilidad con la ayuda de tales estrategias digitales se ha vuelto fundamental para todas las organizaciones, pequeñas y grandes.

Un aspecto vital de la transformación digital es el uso de API . En este artículo, demostraremos cómo trabajamos en Ford con las API para resolver problemas y modernizar nuestro negocio. Al seguir estas prácticas, otros pueden realizar cambios positivos de manera similar en su trabajo diario.

Los primeros pasos

Nuestra primera experiencia con las API comenzó con el requisito de acelerar el proceso de compartir información . Queríamos hacerlo de una manera más precisa y sin la necesidad de esperar procesos por lotes.

Como ya sabrá, los procesos por lotes de un entorno de mainframe pueden ejecutarse durante la noche o dos veces al día, según el volumen de datos y la actividad del trabajo. Trabajamos en la industria del automóvil y continuamente necesitamos el estado de producción de nuestros vehículos. Aunque la mayoría de nuestros sistemas principales eran mainframe heredados, nos dimos cuenta de que no podíamos trabajar en esta estructura para siempre; nuestros clientes no deberían tener que esperar a través de lentos procesos por lotes. Sabíamos que el escenario había cambiado en el mercado del automóvil y necesitábamos nuevas formas de trabajar.

Ese fue el momento en que comenzamos a pensar en las API . Las API son la forma más eficiente de entregar información precisa y actualizada al cliente u otras aplicaciones en la web o dispositivos móviles. Identificamos que esta era una oportunidad para utilizar este nuevo enfoque.

Sin embargo, antes de comenzar a desarrollar nuestra primera API, necesitábamos hacer nuestra tarea para comprender cómo se crearon los datos que entregaríamos.

En la capa de mainframe heredada, tenemos varias interfaces con otros sistemas, utilizando archivos de texto e información escrita en formularios de solicitud. Una vez que toda esta información se carga en la base de datos, se consolida en los procesos por lotes. Ese fue nuestro principal desafío: comprender el flujo de la información y compartirla en línea.

Una vez que comprendimos este escenario, estábamos listos para buscar una mejor arquitectura de software para desarrollar y alimentar las API que necesitábamos construir. Además, pensamos en el futuro; queríamos que las nuevas versiones de API fueran compatibles con versiones anteriores.

Lea más de este escritor: 8 consejos para diseñar API REST de calidad

Adoptando la mentalidad de API-First

Comenzamos esto como un MVP (Minimal Valuable Product), utilizando un enfoque de API primero, diseñando la API y definiendo cómo interactuaría con las aplicaciones que la consumen.

Lección: Diseño de API base en las necesidades del consumidor

Como lo vemos, un enfoque de API primero debe colocar el  pensamiento de API primero en el lado del cliente , colocando las necesidades de los consumidores como una prioridad máxima. Para hacer eso, uno debe considerar: ¿Cuál es la información más valiosa? ¿Cómo puede agregar valor? Trabajar desde la perspectiva de un consumidor de API es esencial, ya que esto ayudará a evitar reelaboraciones y minimizará el impacto de los cambios en sus versiones de API. Esta fue nuestra primera lección aprendida.

Una vez que nuestra API estuvo bien diseñada y documentada, comenzamos a trabajar en la arquitectura que recuperaría los datos del sistema heredado y cómo podríamos traducirlos a un estándar común.

Lección: Siga los estándares y las mejores prácticas

Uno de los requisitos de nuestra API era compartir información en un estándar común para permitir que otros sistemas (heredados o nuevos) lean los datos y los usen sin la necesidad de un segundo nivel de trabajo. Una vez más, aprendimos lo importante que es tener buenas prácticas para el diseño de API. Al usar códigos de error correctos  formato JSON y seguir otras prácticas recomendadas de la industria, pudimos mejorar la usabilidad general.

Lección: Elija sabiamente sus herramientas

Con respecto al código, comenzamos una prueba de concepto utilizando Spring Boot Framework (nuestros desarrolladores más capacitados trabajan con Java) y lo implementamos en nuestro entorno de nube. También usamos Swagger para la documentación web. OpenAPI (fka Swagger) se ha convertido en un estándar para la documentación de API y es imperativo involucrar a los desarrolladores en esta tarea).

Después de algunas mejoras, nuestra prueba de concepto fue lo suficientemente estable y lista para ser probada y consumida por una aplicación web. Comenzamos a monitorear el uso de esta API, compartiendo métricas internamente. Después de todo este trabajo, comenzamos a notar una mejora en la satisfacción del cliente, ya que estaban recibiendo la información más inmediata y precisa posible, nuestro logro más significativo.

La segunda API

Esta primera API ayudó a generar otras ideas, por lo que se desarrolló una segunda, capaz de devolver la información del ciclo de vida de un vehículo. Al igual que en el primero, usamos el concepto de API-first para diseñarlo. También se utilizó una pila similar (Java + Spring Boot + Swagger) en el desarrollo de esta nueva API.

Como teníamos la arquitectura con la que trabajar, la nueva API fue más fácil de desarrollar sin interrumpir el negocio de rutina. Ahora, los clientes ya no deben esperar a que los procesos por lotes se ejecuten por la noche para recibir la última información. Esto le otorga al cliente una mayor eficiencia para agilizar las decisiones tomadas a lo largo del proceso de ventas. Además, esta API es reutilizable por otros sistemas, y cada uno puede utilizar los datos según sus necesidades.

Una vez más, monitoreamos las métricas de acceso y tráfico de datos a través de esta nueva API, y estábamos convencidos de que esta era la forma correcta de escalar nuestro legado, mejorando la eficiencia y también, lo más importante, entregando valor a su negocio en el proceso de toma de decisiones. .

Al final de este MVP, se lo entregamos a nuestro liderazgo y compartimos nuestro viaje a través del desarrollo de API. Ahora nos queda claro que, para sumergirnos en la transformación digital y escalar el negocio sin interrumpir nuestro núcleo, se debe adoptar un enfoque de API primero.

Las barreras

Al liderar la transformación digital, la cultura a  menudo puede ser la barrera más desafiante. Tratar de convencer a su equipo y a su liderazgo para que rompa conceptos profundamente arraigados puede ser más difícil que los problemas técnicos. Sin embargo, cuando comenzamos a demostrar la cultura API, junto con todos los beneficios que podría traer al negocio, las puertas comienzan a abrirse y finalmente comenzamos a trabajar en ello con más apoyo.

El futuro

Y después de todo, queremos más. Ahora estamos trabajando para cambiar la cultura de la empresa, tratando de compartir el conocimiento que aprendimos durante el desarrollo de nuestra API. Hemos presentado dos conferencias para todo el departamento de TI, y ahora otros equipos están a bordo, pensando en el valor que pueden ofrecer a sus clientes utilizando API. Ahora nuestro objetivo principal es crear un conjunto de API útiles para uso interno y, después de eso, habilitar esta lista en un administrador de API. El siguiente paso es aumentar la madurez de la cultura API en nuestra empresa y comenzar a abrir   API de socios .

Publicar un comentario

0 Comentarios