Diasoft explica por qué apostó por la plataforma Digital Q.Integration en lugar de un ESB

Víktor Ovchínnikov, responsable de desarrollo de la plataforma de integración Digital Q.Integration en Diasoft, explicó por qué el equipo abandonó la arquitectura clásica ESB (Enterprise Service Bus) y optó por un enfoque propio para integrar sistemas corporativos.

Por qué el ESB clásico no encajaba

Según Ovchínnikov, un bus ESB clásico se basa en un núcleo monolítico que solo admite escalado vertical: el rendimiento solo puede aumentarse con hardware más potente, no añadiendo nuevos nodos. Si ese núcleo falla, se detiene toda la integración: ninguno de los sistemas conectados puede intercambiar datos con los demás.

Sin embargo, para el autor, el problema más doloroso para la operación no aparece de inmediato, sino de forma gradual. Con el tiempo, el bus se convierte en el lugar donde se acumula toda la lógica de negocio aplicada de la empresa. Al cabo de unos años, el ESB sabe más del negocio de la compañía que cualquiera de los sistemas conectados a él, y entender esa lógica se convierte en una tarea compleja por sí misma.

Qué enfoque eligió el equipo de Diasoft

El equipo se marcó otro principio: tomar lo mejor de la arquitectura point-to-point y del ESB clásico. Por un lado, servicios independientes sin lógica de negocio centralizada, como en las integraciones directas point-to-point. Por otro, un transporte, una monitorización y unas herramientas comunes, como en un bus tradicional. El concepto recibió el nombre de «servicios inteligentes y canales fiables».

• El ESB clásico solo escala verticalmente y constituye un punto único de fallo
• Con el tiempo, el ESB acumula toda la lógica de negocio aplicada de la empresa
• La plataforma Digital Q.Integration se basa en el enfoque «servicios inteligentes y canales fiables»
• Para cada sistema integrado se crea un microservicio-conector independiente
• Los adaptadores se comunican a través de una capa de transporte común, responsable de la entrega y la fiabilidad

Cómo funciona la arquitectura de la plataforma

Para cada sistema integrado, la plataforma crea un microservicio-conector independiente. Este contiene exactamente la lógica necesaria para interactuar con ese sistema concreto, y nada más. El conector no conoce los procesos de negocio de otros sistemas ni se convierte en una fuente centralizada de conocimiento sobre la empresa.

Los adaptadores se comunican entre sí a través de una capa de transporte independiente, que se encarga de la entrega de mensajes y de la fiabilidad del intercambio de datos. Esta separación resuelve la contradicción principal del ESB clásico: antes, el bus asumía a la vez la lógica de negocio y el transporte, de modo que dos tipos de responsabilidad distintos se mezclaban en un mismo núcleo monolítico. En el enfoque de Diasoft, esas tareas están separadas: la lógica de negocio reside en microservicios independientes, mientras que la entrega y la fiabilidad las garantiza una capa común.

En qué se diferencia de un simple point-to-point

La integración directa «punto a punto» resuelve el problema del núcleo monolítico: es distribuida de origen y el fallo de un enlace no tumba toda la red. Pero el point-to-point tiene su contrapartida: sin una capa común de transporte y monitorización, las conexiones directas entre sistemas se convierten rápidamente en una maraña inmanejable, y rastrear qué sistema intercambia datos con cuál resulta tan difícil como entender la lógica de un ESB monolítico. El enfoque de Diasoft toma la naturaleza distribuida del point-to-point, pero le añade una capa de transporte unificada y una monitorización común, que no existen en una arquitectura point-to-point pura.

Qué significa esto

El enfoque de Diasoft intenta resolver el principal problema de los ESB clásicos: que el bus se convierta en un monolito opaco que, con el tiempo, sabe más del negocio que los propios sistemas integrados. Para las empresas que construyen proyectos de IA y otros servicios digitales sobre múltiples sistemas corporativos, los microservicios-conectores independientes reducen el riesgo de que la propia capa de integración se convierta en un cuello de botella y en una fuente de lógica de negocio opaca y difícil de mantener.