Agilidad, agilidad y agilidad. Este es el mantra que se repite con mucha frecuencia en todos los discursos de transformación digital. Pero ¿realmente la estamos abordando correctamente? ¿Hemos “agilizado” todo lo pertinente? Claramente, la respuesta es no. Cuando se trata de agilidad em­presarial no existe una solución que sea única para todos. Más bien al contrario, la agilidad se puede conseguir abordando distintas iniciativas tales como la mejora en el autoaprovisionamien­to o una mayor velocidad a través de la inte­gración continua y el despliegue (CI/CD), entre otras. Pero, en mi experiencia, en la mayoría de las ocasiones se limita a una mejora en la capa de código. ¿Y qué hay de la integración?

Hoy en día, las aplicaciones rara vez existen en si­los, ya sea internos o externos: deben integrarse con numerosos sistemas y servicios y, al igual que con el código, la agilidad puede ser útil en esta capa intermedia. Exis­ten numerosos cam­bios que pueden ocu­rrir fuera del control del propietario de la aplicación, como mo­dificaciones y nuevos socios. En este entorno, aparecen tres fuerzas que pueden desafiar la agilidad de la integración:

• Integración en el corazón de la aplicación. En muchísimas ocasiones, el core de las aplica­ciones se basa en conectarse con otros servicios existentes que, a menudo, son una parte central de los sistemas de una organización y que, por lo tanto, deberían estar aquí para quedarse. Cam­biar la aplicación puede significar hacer cambios en la capa de integración.
• Procesos organizacionales. Algunas confi­guraciones heredadas pueden ser una barrera para seguir adelante. Si la integración entre ser­vicios es gestionada por un centro de excelencia, que a su vez es gestionado por un equipo centra­lizado, es muy probable que ello cause cuellos de botella cuando se necesite una mayor velocidad o cantidad de cambio. Estos equipos centralizados pueden ir en contra de la filosofía de la “agilidad”.
• Cambios tecnológicos. Una arquitectura tradicional en la capa de integración es la de un bus de servicio empresarial (enterprise service bus o ESB por sus siglas en inglés). El ESB tien­de a implementarse de manera monolítica, don­de la lógica de integración se centraliza en una implementación grande y es menos capaz de adaptarse a diferentes aplicaciones y requisitos.

Esto puede obstaculizar los cambios rápidos y frecuentes, que tienden a ser cada vez más im­portantes y necesarios para el éxito empresarial.

Las capacidades y habilidades en la gestión de la integración deben distribuirse en equipos

Pilares clave

Al observar cómo las organizaciones están abrazando esta integración ágil, en Red Hat he­mos identificado estos tres pilares clave:

• Integración distribuida. Es importante que las capacidades/habilidades en la gestión de la integración se distribuyan en diferentes equi­pos en vez de estar en un equipo centralizado, y que sean accesibles allá donde se necesiten en la organización. La arquitectura de desplie­gue también debe descentralizarse para que cada equipo que realice la integración pueda hacerlo de forma independiente, sin ninguna restricción que pueda ser causada por una ar­quitectura centralizada y monolítica. Además, en el entorno que se necesite: on-premise, nube híbrida o pública, desplegable donde sea nece­sario y disponible para quien lo requiera.
• Basado en API. La gestión de API puede ser un punto clave para lograr la integración distribuida. De esto se deduce que las organi­zaciones necesitan poder autorizar el uso de servicios, controlar el acceso, cumplir con la go­bernanza, mejorar la seguridad, saber cómo se utilizan, etc. Todo uso de un servicio debe estar bajo control. Sin ello, podemos encontrarnos a nosotros mismos volviendo al mundo de las co­nexiones punto a punto, con los problemas que pueden ocasionar.
• Entorno de ejecución basado en contene­dores. Los puntos anteriores ayudan a poner or­den en casa, pero, para ayudar a conseguir una mayor agilidad, es importante tener en cuenta las ventajas que los contenedores pueden pro­porcionar en la capa de integración: tener un en­torno más consistente que permita desplegar de forma sencilla y automátizada, hacer bursting, que se pueda escalar automáticamente según sea necesario… Además, una plataforma de con­tenedores proporciona una capa de abstracción de la infraestructura subyacente. Los equipos pueden administrar aplicaciones de forma más uniforme en todos los entornos, ya sea on-premise, en máquinas virtuales o en la nube pública.

Con estas soluciones han conseguido una mayor elasticidad en sus infraestructuras

Democratizar la integración

Pero para conseguir estos tres pilares no basta con contenerizar el ESB, porque lo que final­mente se busca es una democratización de la capa de integración: empoderar al “ciudadano integrador”, hacer accesible la capacidad de integración para aquellos que no son grandes expertos en el tema, pero que la necesitan para convertir en realidad sus ideas sobre nuevas aplicaciones y servicios. Por lo tanto, las organi­zaciones pueden buscar tecnologías que no solo se distribuyan y se integren con la administra­ción de la API y en contenedores, sino que tam­bién sean más fáciles de usar, sin la necesidad de programar líneas de código.

Para dar una respues­ta a este contexto existen soluciones como las plataformas cloud iPaaS (integra­ción como servicio), que se centran justo en los aspectos co­mentados para los proyectos de integración de aplicaciones, datos y procesos. Estas plataformas permiten a los desarrolladores, y al “ciudadano integrador no experto”, conectar sus aplicaciones mediante un navegador web. Estas plataformas sin código ayudan a los usuarios a crear solucio­nes más rápidamente, reduciendo la complejidad al proporcionar elementos gráficos o plantillas.

Ejemplos de uso

Esta es la dirección correcta y he visto empresas que ya siguen esta metodología. En esta carrera por ayudar a simplificar la integración entre las aplicaciones y a optimizar los procesos de desa­rrollo y despliegue de nuevas soluciones en un entorno cloud, empresas como SEUR han implan­tado Red Hat Openshift Container Platform y Red Hat Fuse. Con estas soluciones han consegui­do una mayor elasticidad en sus infraestructuras, con el fin de responder mejor a las fluctuaciones de su negocio, así como proporcionar soluciones en un entorno de integración continua.

Como conclusión, las empresas pueden buscar nuevas soluciones de software para desarrollar nuevas aplicaciones y servicios que respondan mejor a las necesidades de sus clientes, y para ello deberían hacer que los datos se conecten con aplicaciones y servicios existentes. Es en este punto donde la integración ágil y moder­na, entre los sistemas heredados y las nuevas infraestructuras y aplicaciones, puede ser cada vez más importante a la hora de utilizar entor­nos de nube híbrida y multicloud para ayudar a satisfacer de manera flexible sus necesidades de negocio.