Integración de aplicaciones empresariales

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]

Descripción general

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 una empresa. ^[1]

Muchos tipos de software empresarial, como aplicaciones de gestión de la cadena de suministro , sistemas ERP , aplicaciones CRM para gestionar clientes, aplicaciones de inteligencia empresarial , sistemas de nómina y recursos humanos , normalmente no pueden comunicarse entre sí para compartir datos o reglas comerciales. Por este motivo, a veces se hace referencia a estas aplicaciones como islas de automatización o silos de información . Esta falta de comunicación genera ineficiencias, en las que datos idénticos se almacenan en múltiples ubicaciones o no se pueden automatizar procesos sencillos. ^{[ cita necesaria ]}

La integración de aplicaciones empresariales es el proceso de vincular dichas aplicaciones dentro de una sola organización para simplificar y automatizar los procesos comerciales en la mayor medida posible, evitando al mismo tiempo tener que 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 necesaria ]}

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 diversos sistemas que deben vincularse pueden residir en diferentes sistemas operativos , utilizar diferentes soluciones de bases de datos o lenguajes informáticos , o diferentes formatos de fecha y hora, o podrían ser sistemas heredados que ya no son compatibles con el proveedor que los creó originalmente. En algunos casos, estos sistemas se denominan " sistemas de tubo de estufa " porque consisten en componentes que han sido atascados entre sí de una manera que hace muy difícil modificarlos de alguna manera. ^{[ cita necesaria ]}

Mejorando la conectividad

Si la integración se aplica sin seguir un enfoque estructurado de EAI, las conexiones punto a punto crecen en toda la organización. Las dependencias se agregan de forma 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, viene dado por (ver coeficiente binomial ). Así, para que diez aplicaciones estén totalmente integradas punto a punto, se necesitan conexiones punto a punto, siguiendo un patrón de crecimiento cuadrático . ${\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}$ ${\tfrac {10\times 9}{2}}=45$

Sin embargo, el número de conexiones dentro de las organizaciones no necesariamente crece según el cuadrado del número de puntos. En general, el número de conexiones a cualquier punto sólo está limitado por el número de otros puntos de una organización, pero en principio puede ser significativamente menor. EAI también puede aumentar el acoplamiento entre sistemas y, por lo tanto, aumentar los gastos generales y los costos de gestión. ^{[ cita necesaria ]}

EAI no se trata solo de compartir datos entre aplicaciones, sino que también se centra en compartir datos y procesos comerciales. Un analista de middleware que se ocupa de EAI a menudo observará el sistema de sistemas . ^{[ cita necesaria ]}

Propósitos

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

Integración de datos : garantiza que la información en múltiples 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, las reglas comerciales no tienen que volver a implementarse.
Fachada común: un sistema EAI puede implementar un grupo de aplicaciones, proporcionando una única interfaz de acceso consistente a estas aplicaciones y protegiendo a los usuarios de tener que aprender a usar diferentes paquetes de software.

Patrones

Esta sección describe patrones de diseño comunes para implementar EAI, incluidos los patrones de integración, acceso y vida útil. Estos son patrones abstractos y se pueden implementar de muchas maneras diferentes. Hay muchos otros patrones comúnmente utilizados en la industria, que van desde patrones de diseño abstractos de alto nivel hasta patrones de implementación altamente específicos. ^[3]

Patrones de integración

Los sistemas EAI implementan dos patrones: ^[4]

Mediación (intracomunicación): Aquí, el sistema EAI actúa como intermediario entre múltiples aplicaciones. Cada vez que ocurre 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 en el sistema EAI. Luego, 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 entre 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 solo 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 al mismo tiempo. El mismo sistema EAI podría mantener sincronizadas varias aplicaciones (mediación), mientras atiende solicitudes de usuarios externos contra estas aplicaciones (federación). ^{[ cita necesaria ]}

Patrones de acceso

EAI admite patrones de acceso tanto asincrónicos (disparar y olvidar) como sincrónicos, siendo el primero típico en el caso de mediación y el segundo en el caso de federación. ^{[ cita necesaria ]}

Patrones de vida

Una operación de integración podría ser de corta duración (por ejemplo, mantener los datos sincronizados en 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 su aprobación). de un préstamo que tarda horas o días en completarse). ^{[ cita necesaria ]}

Topologías

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

La mayoría de las grandes empresas utilizan redes zonificadas para crear una defensa en capas contra las 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 que no es PCI, una zona de datos, una zona DMZ para representar el acceso de usuarios externos y una zona IWZ para representar el acceso de usuarios internos. Las aplicaciones deben integrarse en múltiples zonas. El modelo Hub and Spoke funcionaría mejor en este caso. ^{[ cita necesaria ]}

Tecnologías

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

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), actuando 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 (unidireccional), realiza solicitudes del concentrador a la aplicación y notifica al concentrador 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 (p. ej., construidos con las bibliotecas cliente del proveedor de la aplicación) o específicos de una clase de aplicaciones (p. ej., pueden interactuar con cualquier aplicación a través de un protocolo de comunicación estándar, como SOAP , SMTP o formato de mensaje de acción (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 utilizar un protocolo propietario. En el mundo Java, estándares como JCA permiten que los adaptadores se creen de manera neutral respecto al proveedor.
Formato y transformación de datos.: Para evitar que cada adaptador tenga que convertir datos hacia/desde los formatos de cualquier otra aplicación, los sistemas EAI suelen estipular un formato de datos independiente de la aplicación (o común). El sistema EAI generalmente también proporciona un servicio de transformación de datos para ayudar a convertir entre formatos comunes y específicos de la aplicación. Esto se hace en dos pasos: el adaptador convierte la información del formato de la aplicación al formato común del bus. Luego, se aplican transformaciones semánticas a esto (convertir códigos postales en nombres de ciudades, dividir/fusionar objetos de una aplicación en objetos de otras aplicaciones, etc.).
Módulos de integración: Un sistema EAI podría participar en múltiples operaciones de integración simultáneas en un momento dado, siendo procesado cada tipo de integración 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 se ajusten a las especificaciones del sistema EAI.
Soporte para transacciones: Cuando se utiliza para la integración de procesos, el sistema EAI también proporciona coherencia transaccional entre aplicaciones al ejecutar todas las operaciones de integración en todas las aplicaciones en una única transacción distribuida global (utilizando protocolos de confirmación de dos fases o transacciones de compensación ).

Arquitecturas de comunicación

Actualmente, existen muchas variaciones de pensamiento sobre lo que 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 necesaria ]}

Un corredor centralizado que maneja 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 mediante software similar como el modelo de bus de servicios empresariales (ESB) que actúa como administrador de servicios.
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 jure para este lenguaje comercial uniforme.
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 comunicarse con el intermediario centralizado.
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 forma 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 descubierto que puedan escalar o adaptarse. Las aplicaciones individuales pueden publicar mensajes en el corredor centralizado y suscribirse para recibir ciertos mensajes de ese corredor. Cada aplicación sólo requiere una conexión con el corredor. Este enfoque de control central puede ser extremadamente escalable y altamente evolucionable . ^{[ cita necesaria ]}

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 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 centrarse en los datos. En un futuro próximo, incluirá integración de contenidos y procesos de negocio . ^{[ cita necesaria ]}

Errores de implementación

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

Cambio constante: la naturaleza misma de EAI es dinámica y requiere gerentes de proyecto dinámicos para gestionar su implementación.
Escasez de expertos en EAI : la EAI requiere conocimiento de muchas cuestiones y aspectos técnicos.
Estándares en competencia: Dentro del campo de la EAI, la paradoja es que los estándares de la EAI en sí mismos no son universales.
EAI es un paradigma de herramienta: EAI no es una herramienta, sino más bien un sistema y debe implementarse como tal.
Construir interfaces es un arte: diseñar la solución no es suficiente. Es necesario negociar soluciones con los departamentos usuarios para llegar a un consenso común sobre el resultado final. La falta de consenso sobre los diseños de interfaces conduce a un esfuerzo excesivo para mapear los requisitos de datos de varios sistemas.
Pérdida de detalles: la información que parecía poco importante en una etapa anterior puede volverse crucial más adelante.
Responsabilidad: dado que tantos departamentos tienen muchos requisitos contradictorios, debe haber una responsabilidad clara sobre la estructura final del sistema.

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

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 suelen pertenecer a diferentes departamentos que tienen razones técnicas, culturales y políticas para no querer compartir sus datos con otros departamentos.

Ver también

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 sistema

Iniciativas y organizaciones

Referencias

^ ab Linthicum, David S. (2000). Integración de aplicaciones empresariales. Profesional de Addison-Wesley. ISBN 978-0-201-61583-8.
^ En su informe de abril de 2001 para AIIM International, "Aplicaciones empresariales: adopción de tecnologías de documentos y negocios electrónicos, 2000-2001: estudio de la industria mundial", Gartner define EAI como "el intercambio irrestricto de datos y procesos comerciales entre cualquier aplicación conectada y fuentes de datos en la empresa." Gable, Julie (marzo-abril de 2002). "Integración de aplicaciones empresariales" (PDF) . Revista de Gestión de la Información . Consultado el 22 de enero de 2008 .
^ Hohpe, Gregor; Woolf, Bobby (2015). "Descripción general de patrones de mensajería". Enterpriseintergationpatterns.com y Addison-Wesley . Consultado el 19 de mayo de 2016 .
^ Sistemas MSquare (21 de mayo de 2014). "Tipos de EAI". Archivado el 21 de mayo de 2014 en https://web.archive.org/web/20140521124430/http://www.msquaresystems.com/enterprise-application-2/eai. MSquare Systems Obtenido el 28 de mayo de 2014 en http://www.msquaresystems.com/enterprise-application-2/eai.
^ Trotta, Gian (15 de diciembre de 2003). "Bailando alrededor de las trampas para osos de EAI'" . Consultado el 27 de junio de 2006 .
^ Toivanen, Antti (25 de octubre de 2013). "Evitar los obstáculos de los centros de competencia en integración". Archivado desde el original el 30 de julio de 2017 . Consultado el 26 de octubre de 2013 .