Integración de aplicaciones empresariales

Este artículo tiene varios problemas. Ayúdenos a mejorarlo o a discutir estos problemas en la página de discusión . ( Aprenda cómo y cuándo eliminar estos mensajes ) Este artículo necesita citas adicionales para su verificación . Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Enterprise application integration" – news · newspapers · books · scholar · JSTOR (February 2020) (Learn how and when to remove this message) This article possibly contains original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (February 2020) (Learn how and when to remove this message) (Learn how and when to remove this message)

La integración de aplicaciones empresariales ( EAI ) es el uso de principios arquitectónicos de software y sistemas informáticos para integrar un conjunto de aplicaciones informáticas empresariales . ^[1]

La integración de aplicaciones empresariales es un marco de integración compuesto por una colección de tecnologías y servicios que forman un middleware o "marco de middleware" para permitir la integración de sistemas y aplicaciones en toda una empresa. ^[1]

Muchos tipos de software empresarial, como las aplicaciones de gestión de la cadena de suministro , los sistemas ERP , las aplicaciones CRM para la gestión de clientes, las aplicaciones de inteligencia empresarial , las nóminas y los sistemas de recursos humanos , normalmente no pueden comunicarse entre sí para compartir datos o reglas empresariales. Por este motivo, a estas aplicaciones se las suele denominar islas de automatización o silos de información . Esta falta de comunicación genera ineficiencias, ya que se almacenan datos idénticos en varias ubicaciones o no se pueden automatizar procesos sencillos. ^{[ cita requerida ]}

La integración de aplicaciones empresariales es el proceso de vincular dichas aplicaciones dentro de una misma organización con el fin de simplificar y automatizar los procesos empresariales en la mayor medida posible, evitando al mismo tiempo la necesidad de realizar cambios radicales en las aplicaciones o estructuras de datos existentes. Las aplicaciones se pueden vincular en el back-end a través de API o (raramente) en el front-end ( GUI ). ^{[ cita requerida ]}

En palabras de la firma de investigación Gartner : "[EAI es] el intercambio sin restricciones de datos y procesos comerciales entre cualquier aplicación o fuente de datos conectada en la empresa". ^[2]

Los distintos sistemas que deben conectarse entre sí pueden residir en sistemas operativos diferentes , utilizar distintas soluciones de bases de datos o lenguajes informáticos , o distintos formatos de fecha y hora, o pueden ser sistemas heredados que ya no reciben soporte del proveedor que los creó originalmente. En algunos casos, estos sistemas se denominan " sistemas de conductos " porque constan de componentes que se han ensamblado de tal manera que es muy difícil modificarlos de cualquier forma. ^{[ cita requerida ]}

Si se aplica la integración sin seguir un enfoque EAI estructurado, las conexiones punto a punto crecen en toda la organización. Las dependencias se agregan de manera improvisada, lo que da como resultado una estructura compleja que es difícil de mantener. Esto se conoce comúnmente como espagueti, una alusión al equivalente en programación del código espagueti .

Por ejemplo, el número de conexiones necesarias para tener conexiones punto a punto completamente malladas, con n puntos, está dado por (ver coeficiente binomial ). Por lo tanto, para que diez aplicaciones estén completamente integradas punto a punto, se necesitan conexiones punto a punto, siguiendo un patrón de crecimiento cuadrático .${\displaystyle {\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}}$${\displaystyle {\tfrac {10\times 9}{2}}=45}$

Sin embargo, la cantidad de conexiones dentro de las organizaciones no necesariamente crece de acuerdo con el cuadrado de la cantidad de puntos. En general, la cantidad de conexiones a cualquier punto solo está limitada por la cantidad de otros puntos en una organización, pero en principio puede ser significativamente menor. La EAI también puede aumentar el acoplamiento entre sistemas y, por lo tanto, aumentar los costos y la sobrecarga de administración. ^{[ cita requerida ]}

La EAI no se limita a compartir datos entre aplicaciones, sino que también se centra en compartir datos y procesos empresariales. Un analista de middleware que se ocupe de la EAI a menudo analizará el sistema de sistemas . ^{[ cita requerida ]}

La EAI se puede utilizar para diferentes propósitos: ^{[ cita requerida ]}

• Integración de datos : garantiza que la información en varios sistemas se mantenga consistente. Esto también se conoce como integración de información empresarial (EII).
• Independencia del proveedor: extrae políticas o reglas comerciales de las aplicaciones y las implementa en el sistema EAI, de modo que incluso si una de las aplicaciones comerciales se reemplaza por la aplicación de un proveedor diferente, no es necesario volver a implementar las reglas comerciales.
• Fachada común: un sistema EAI puede actuar como interfaz frontal de un grupo de aplicaciones, brindando una única interfaz de acceso consistente a estas aplicaciones y evitando que los usuarios tengan que aprender a usar diferentes paquetes de software.

En esta sección se describen los patrones de diseño más comunes para implementar EAI, incluidos los patrones de integración, acceso y duración. Se trata de patrones abstractos que se pueden implementar de muchas maneras diferentes. Existen muchos otros patrones que se utilizan comúnmente en la industria, desde patrones de diseño abstractos de alto nivel hasta patrones de implementación muy específicos. ^[3]

Los sistemas EAI implementan dos patrones: ^[4]

Mediación (intracomunicación)

En este caso, el sistema EAI actúa como intermediario entre varias aplicaciones. Siempre que se produce un evento interesante en una aplicación (por ejemplo, se crea nueva información o se completa una nueva transacción), se notifica a un módulo de integración del sistema EAI. A continuación, el módulo propaga los cambios a otras aplicaciones relevantes.

Federación (intercomunicación)

En este caso, el sistema EAI actúa como fachada general en múltiples aplicaciones. Todas las llamadas de eventos del "mundo exterior" a cualquiera de las aplicaciones son gestionadas por el sistema EAI. El sistema EAI está configurado para exponer únicamente la información y las interfaces relevantes de las aplicaciones subyacentes al mundo exterior, y realiza todas las interacciones con las aplicaciones subyacentes en nombre del solicitante.

Ambos patrones se utilizan a menudo de forma simultánea. El mismo sistema EAI podría mantener sincronizadas varias aplicaciones (mediación), mientras atiende las solicitudes de usuarios externos a estas aplicaciones (federación). ^{[ cita requerida ]}

EAI admite patrones de acceso tanto asincrónicos (disparar y olvidar) como sincrónicos, siendo los primeros típicos en el caso de mediación y los segundos en el caso de federación. ^{[ cita requerida ]}

Una operación de integración podría ser de corta duración (por ejemplo, mantener sincronizados los datos entre dos aplicaciones podría completarse en un segundo) o de larga duración (por ejemplo, uno de los pasos podría implicar que el sistema EAI interactúe con una aplicación de flujo de trabajo humano para la aprobación de un préstamo que demora horas o días en completarse). ^{[ cita requerida ]}

Existen dos topologías principales: hub-and-spoke y bus . Cada una tiene sus propias ventajas y desventajas. En el modelo hub-and-spoke, el sistema EAI está en el centro (el hub) e interactúa con las aplicaciones a través de los radios. En el modelo bus, el sistema EAI es el bus (o se implementa como un módulo residente en un bus de mensajes ya existente o middleware orientado a mensajes ). ^{[ cita requerida ]}

La mayoría de las grandes empresas utilizan redes zonificadas para crear una defensa en capas contra amenazas orientadas a la red. Por ejemplo, una empresa normalmente tiene una zona de procesamiento de tarjetas de crédito (compatible con PCI), una zona no PCI, una zona de datos, una zona DMZ para proxy de acceso de usuarios externos y una zona IWZ para proxy de acceso de usuarios internos. Las aplicaciones deben integrarse en varias zonas. El modelo de concentrador y radios funcionaría mejor en este caso. ^{[ cita requerida ]}

Se utilizan múltiples tecnologías para implementar cada uno de los componentes del sistema EAI: ^{[ cita requerida ]}

Autobús/centro

Esto generalmente se implementa mejorando los productos de middleware estándar ( servidor de aplicaciones , bus de mensajes) o se implementa como un programa independiente (es decir, no utiliza ningún middleware) y actúa como su propio middleware.

Conectividad de aplicaciones

El bus/hub se conecta a las aplicaciones a través de un conjunto de adaptadores (también denominados conectores ). Estos son programas que saben cómo interactuar con una aplicación empresarial subyacente. El adaptador realiza una comunicación unidireccional, realizando solicitudes desde el hub contra la aplicación y notificando al hub cuando ocurre un evento de interés en la aplicación (un nuevo registro insertado, una transacción completada, etc.). Los adaptadores pueden ser específicos de una aplicación (por ejemplo, creados contra las bibliotecas de cliente del proveedor de la aplicación) o específicos de una clase de aplicaciones (por ejemplo, pueden interactuar con cualquier aplicación a través de un protocolo de comunicación estándar, como SOAP , SMTP o Action Message Format (AMF)). El adaptador podría residir en el mismo espacio de proceso que el bus/hub o ejecutarse en una ubicación remota e interactuar con el hub/bus a través de protocolos estándar de la industria, como colas de mensajes, servicios web o incluso usar un protocolo propietario. En el mundo Java, estándares como JCA permiten que los adaptadores se creen de manera neutral con respecto al proveedor.

Formato y transformación de datos

Para evitar que cada adaptador tenga que convertir datos a/desde los formatos de todas las demás aplicaciones, los sistemas EAI suelen estipular un formato de datos independiente de la aplicación (o común). El sistema EAI suele proporcionar también un servicio de transformación de datos para ayudar a convertir entre formatos específicos de la aplicación y comunes. Esto se hace en dos pasos: el adaptador convierte la información del formato de la aplicación al formato común del bus. A continuación, se aplican transformaciones semánticas a esto (conversión de códigos postales a nombres de ciudades, división/fusión de objetos de una aplicación en objetos de las otras aplicaciones, etc.).

Módulos de integración

Un sistema EAI podría participar en múltiples operaciones de integración simultáneas en cualquier momento, y cada tipo de integración sería procesada por un módulo de integración diferente. Los módulos de integración se suscriben a eventos de tipos específicos y procesan las notificaciones que reciben cuando ocurren estos eventos. Estos módulos podrían implementarse de diferentes maneras: en sistemas EAI basados ​​en Java , podrían ser aplicaciones web o EJB o incluso POJO que cumplan con las especificaciones del sistema EAI.

Soporte para transacciones

Cuando se utiliza para la integración de procesos, el sistema EAI también proporciona consistencia transaccional entre aplicaciones al ejecutar todas las operaciones de integración en todas las aplicaciones en una única transacción distribuida general (utilizando protocolos de confirmación de dos fases o transacciones de compensación ).

En la actualidad, existen muchas variaciones de pensamiento sobre qué constituye la mejor infraestructura, modelo de componentes y estructura de estándares para la integración de aplicaciones empresariales. Parece haber consenso en que cuatro componentes son esenciales para una arquitectura de integración de aplicaciones empresariales moderna: ^{[ cita requerida ]}

1. Un agente centralizado que se encarga de la seguridad, el acceso y la comunicación. Esto se puede lograr a través de servidores de integración (como los servidores de integración de zona del marco de interoperabilidad escolar [SIF] ) o a través de un software similar, como el modelo de bus de servicios empresariales (ESB), que actúa como administrador de servicios.
2. Un modelo de datos independiente basado en una estructura de datos estándar, también conocido como modelo de datos canónico . Parece que XML y el uso de hojas de estilo XML se han convertido en el estándar de facto y, en algunos casos, de iure para este lenguaje empresarial uniforme.
3. Un conector o modelo de agente donde cada proveedor, aplicación o interfaz puede crear un único componente que puede comunicarse de forma nativa con esa aplicación y con el agente centralizado.
4. Un modelo de sistema que define las API, el flujo de datos y las reglas de interacción con el sistema, de modo que se puedan crear componentes para interactuar con él de manera estandarizada.

Aunque se han explorado otros enfoques, como la conexión a nivel de base de datos o de interfaz de usuario, no se ha demostrado que sean escalables ni que se puedan ajustar. Las aplicaciones individuales pueden publicar mensajes en el agente centralizado y suscribirse para recibir determinados mensajes de ese agente. Cada aplicación solo requiere una conexión al agente. Este enfoque de control central puede ser extremadamente escalable y altamente evolucionable . ^{[ cita requerida ]}

La integración de aplicaciones empresariales está relacionada con tecnologías de middleware como el middleware orientado a mensajes ( MOM ) y tecnologías de representación de datos como XML o JSON . Otras tecnologías de EAI implican el uso de servicios web como parte de una arquitectura orientada a servicios como medio de integración. La integración de aplicaciones empresariales tiende a estar centrada en los datos. En un futuro cercano, llegará a incluir la integración de contenido y los procesos comerciales . ^{[ cita requerida ]}

En 2003 se informó que el 70% de todos los proyectos de EAI fracasan. La mayoría de estos fracasos no se deben al software en sí ni a dificultades técnicas, sino a problemas de gestión. El presidente del Consorcio Europeo de Integración, Steve Craggs, ha esbozado los siete principales obstáculos que corren las empresas que utilizan sistemas EAI y explica las soluciones a estos problemas. ^[5]

1. Cambio constante: la naturaleza misma de EAI es dinámica y requiere gerentes de proyectos dinámicos para gestionar su implementación.
2. Escasez de expertos en EAI : la EAI requiere conocimientos de muchos temas y aspectos técnicos.
3. Estándares en competencia: Dentro del campo de EAI, la paradoja es que los estándares de EAI en sí mismos no son universales.
4. EAI es un paradigma de herramientas: EAI no es una herramienta, sino un sistema y debe implementarse como tal.
5. La creación de interfaces es un arte: diseñar la solución no es suficiente. Es necesario negociar las soluciones con los departamentos de los usuarios para llegar a un consenso común sobre el resultado final. La falta de consenso sobre los diseños de interfaces genera un esfuerzo excesivo para establecer un mapa de los requisitos de datos de los distintos sistemas.
6. Pérdida de detalles: la información que parecía poco importante en una etapa anterior puede volverse crucial más adelante.
7. Responsabilidad: Dado que muchos departamentos tienen muchos requisitos conflictivos, debería haber una responsabilidad clara por la estructura final del sistema.

Pueden surgir otros problemas potenciales en estas áreas: ^{[ cita requerida ]}

• Falta de coordinación centralizada del trabajo de EAI. ^[6]
• Requisitos emergentes: Las implementaciones de EAI deben ser extensibles y modulares para permitir cambios futuros.
• Proteccionismo: Las aplicaciones cuyos datos se integran a menudo pertenecen a diferentes departamentos que tienen razones técnicas, culturales y políticas para no querer compartir sus datos con otros departamentos.

• Marco de arquitectura empresarial
• Estrategias para la integración de aplicaciones empresariales
• Gestión de la semántica empresarial
• Integración de datos
• Integración de información empresarial
• Integración empresarial
• Patrones de integración empresarial
• Bus de servicios empresariales
• Arquitectura y metodología de referencia empresarial generalizada
• Dispositivo de integración
• Centro de competencias de integración
• Plataforma de integración
• Integración de sistemas

• Nivel de salud 7
• Iniciativa de conocimiento abierto
• OSS a través de Java
• Marco de interoperabilidad escolar (SIF)