¿Cuál es la mejor manera de integrar varios sistemas?

Question

Ok, donde trabajo tenemos una cantidad bastante importante de sistemas escritos en las últimas décadas que mantenemos.

Los sistemas son diversos en los múltiples sistemas operativos (Linux, Solaris, Windows), múltiples bases de datos (varias versiones de Oracle, sybase y mysql) e incluso varios idiomas (C, C++, JSP, PHP y un host de otros) se usan.

Cada sistema es bastante autónomo, incluso a costa de ingresar los mismos datos en múltiples sistemas.

La administración recientemente decidió que deberíamos investigar qué se necesitará para lograr que todos los sistemas se comuniquen entre sí y compartan datos.

Tenga en cuenta que si bien podemos hacer cambios de software en cualquiera de los sistemas individuales, una reescritura completa de cualquier sistema (o más) no es algo que la administración pueda entretener.

La primera idea de varios de los desarrolladores fue simple: si el sistema A necesita datos del sistema B, simplemente debe conectarse a la base de datos del sistema B y obtenerlo. Del mismo modo, si necesita dar datos B, debería simplemente insertarlos en la base de datos de B.

Debido al desorden de las bases de datos (y versiones) utilizadas, otros desarrolladores opinaron que deberíamos tener una nueva base de datos, combinando las tablas de todos los demás sistemas para evitar tener que hacer malabarismos con múltiples conexiones. Al hacer esto, esperan que podamos consolidar algunas tablas y deshacernos de la entrada de datos redundantes.

Esto es casi el momento en que me trajeron mi opinión sobre el desastre.

La idea de usar la base de datos como medio de comunicación del sistema me resulta graciosa. La lógica empresarial tendrá que colocarse en múltiples sistemas (si el Sistema A quiere agregar datos al Sistema B, comprender mejor las reglas de B con respecto a los datos antes de insertarlos), es probable que varios sistemas tengan que hacer alguna forma de sondeo de bases de datos para encontrar Cualquier cambio en sus datos, el mantenimiento continuo será un dolor de cabeza, ya que cualquier cambio en el esquema de una base de datos ahora propaga varios sistemas.

Lo primero que pensé fue en tomarse el tiempo y escribir API/servicios para los diferentes sistemas, que una vez que se escriben podrían utilizarse fácilmente para pasar/recuperar datos de ida y vuelta. Muchos otros desarrolladores piensan que es excesivo y mucho más trabajo que solo usar la base de datos.

Entonces, ¿cuál sería la mejor manera de lograr que estos sistemas se comuniquen entre sí?

Answer 1

La integración de sistemas dispares es mi trabajo diario.

Si yo fuera usted, haría un gran esfuerzo para evitar acceder a los datos del Sistema A directamente desde el Sistema B.Actualizando La base de datos del sistema A del sistema B es extremadamente imprudente. Es exactamente lo opuesto a las buenas prácticas hacer que la lógica de su negocio sea tan difusa. Terminas arrepintiéndote.

La idea de la base de datos central no es necesariamente mala ... pero la cantidad de esfuerzo involucrado es, probablemente, en un orden de magnitud de la reescritura de los sistemas desde cero. Ciertamente, no es algo que intente, al menos en la forma que describes. Puede tener éxito, pero es mucho, mucho más difícil y requiere mucha más disciplina que el enfoque de integración punto a punto. Es gracioso escucharlo sugerido al mismo tiempo que el enfoque de "vaquero" de simplemente enviar datos directamente a otros sistemas.

En general, sus instintos parecen bastante buenos. Hay un par de enfoques. Usted menciona uno: implementar servicios. No es una mala forma de hacerlo, especialmente si necesita actualizaciones en tiempo real. La otra es una aplicación de integración separada que se encarga de mezclar los datos. Ese es el enfoque que generalmente uso, pero generalmente porque no puedo cambiar los sistemas que estoy integrando para pedir los datos que necesita; Tengo que ingresar los datos. En su caso, el enfoque de los servicios no es malo.

Una cosa que me gustaría decir que puede no ser obvio para alguien que viene a la integración del sistema por primera vez es que cada dato en su sistema debe tener un punto de verdad único y autoritario. Si los datos están duplicados (y están duplicados), y las copias no concuerdan entre sí, la copia en el punto de verdad para esos datos debe considerarse correcta. Simplemente no hay otra manera de integrar sistemas sin tener que gritar la complejidad hacia el cielo a un ritmo exponencial. La integración de Spaghetti es como el código de spaghetti, y debe evitarse a toda costa.

Buena suerte.

EDIT:

Middleware aborda el problema de transporte, pero eso no es el problema central en la integración. Si los sistemas están lo suficientemente cerca como para que una aplicación pueda enviar datos directamente a otra, es probable que estén lo suficientemente cerca como para que un servicio ofrecido por uno pueda ser llamado directamente por otro. No recomendaría middleware en su caso. Puede obtener algún beneficio de ello, pero eso se vería compensado por la mayor complejidad. Debes resolver un problema a la vez.

Answer 2

Parece que está buscando opiniones, por lo que voy a proporcionar la mía.

Estoy de acuerdo con los otros desarrolladores en que escribir una API para todos los diferentes sistemas es excesivo. Es probable que lo haga más rápido y tenga mucho más control si toma la otra sugerencia de crear una única base de datos.

Answer 3

Parece que es posible que desee investigar Message Queuing y message-oriented middleware.

MSMQ y Java Message Service siendo ejemplos.

Answer 4

La interconexión directa mediante bases de datos de empuje/inserción expone una gran cantidad de detalles internos de un sistema a otro. Hay desventajas obvias: actualizar un sistema puede romper al otro. Además, puede haber limitaciones técnicas sobre cómo un sistema puede acceder a la base de datos del otro (considere cómo una aplicación escrita en C en Unix interactuará con una base de datos de SQL Server 2005 que se ejecuta en Windows 2003 Server).

Lo primero que tiene que decidir es la plataforma donde residirá la "base de datos maestra", y lo mismo para el middleware que proporciona el pegamento necesario. En lugar de ir hacia la integración de middleware de nivel API (como CORBA), le sugiero que considere Middleware orientado a mensajes. MS Biztalk, Sun's eGate y Oracle's Fusion pueden ser algunas de las opciones.

Su idea de una nueva base de datos es un paso en la dirección correcta. Le gustaría leer un poco en el patrón Enterprise Entity Aggregation.

Una combinación de "integración de datos" con un middleware es el camino a seguir.

Answer 5

Uno de los desafíos que tendrá es alinear los datos en cada uno de los diferentes sistemas para que pueda integrarse desde el principio. Es posible que cada uno de los sistemas que desee integrar contenga conjuntos de datos completamente diferentes, pero es más probable que se superpongan los datos.Antes de sumergirme en la escritura de API: s (que es la ruta que tomaría también dada su descripción), le recomendaría que intente y cree un modelo de datos lógicos para los datos que deben integrarse. Este modelo de datos lo ayudará a aprovechar los datos que tiene en los diferentes sistemas y a hacerlos más útiles para las otras bases de datos.

También recomendaría encarecidamente un enfoque iterativo para la integración. Con los sistemas heredados hay tanta incertidumbre que tratar de diseñarlo e implementarlo de una sola vez es demasiado arriesgado. Comience poco a poco y avance hacia un sistema razonablemente integrado. "Completamente integrado" casi nunca vale la pena apuntar.

Answer 6

Si va hacia la estrategia Middleware + Single Central Database, es posible que desee considerar lograr esto en múltiples fases. Aquí está un proceso escalonado lógico que puede ser considerado:

1. implementación de servicios/API para diferentes sistemas que exponen la funcionalidad para cada sistema
2. Aplicación de Middleware que accede a estas API y proporciona una interfaz para todos los sistemas a acceder a los datos/servicios de otros sistemas (acceso a datos de fuente central, si está disponible, de lo contrario lo consigue desde otro sistema)
3. Implementación de única base de datos central, sin datos de
4. Implementación de almacenamiento en caché/servicios de almacenamiento de datos a nivel de middleware que puede almacenar/almacenar en caché los datos en el databa central se cada vez que se accede a estos datos desde cualquiera de los Sistemas, p. Si los sistemas A registran los registros 1-5 en el middleware, los Middleware Data Caching Services pueden almacenar estos registros en la base de datos centralizada y la próxima vez que estos registros se obtengan de la base de datos central
5. La limpieza de datos puede ocurrir en paralelo
6. también puede crear un mecanismo de importación para empujar los datos de varios sistemas a la base de datos central sobre una base diaria (automático o manual)

de esta manera, el esfuerzo se distribuye a través de múltiples hitos y los datos se almacenan gradualmente en la base de datos central en el primer acceso al primer archivo almacenado.