¿Cómo integrar mejor varios sistemas?

Question

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

Los sistemas son diversos en cuanto a múltiples sistemas operativos (Linux, Solaris, Windows), múltiples bases de datos (varias versiones de Oracle, Sybase y MySQL) e incluso múltiples idiomas (C, C ++, JSP, PHP y una gran cantidad de otros) se utilizan.

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

Recientemente, la gerencia decidió que deberíamos investigar qué se necesitará para que todos los sistemas se comuniquen entre sí y compartan datos.

Tenga en cuenta que si bien podemos realizar 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.

El primer pensamiento de varios de los desarrolladores aquí fue sencillo: si el sistema A necesita datos del sistema B, simplemente debe conectarse a la base de datos del sistema B y obtenerlos. Del mismo modo, si necesita proporcionar datos B, solo debe insertarlo en la base de datos de B.

Debido al desorden de las bases de datos (y las 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 varias conexiones. Al hacer esto, esperan que podamos consolidar algunas tablas y deshacernos de la entrada redundante de datos.

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

La idea general de usar la base de datos como un medio de comunicación del sistema me huele raro. La lógica de negocios tendrá que ubicarse en múltiples sistemas (si el Sistema A desea agregar datos al Sistema B, entenderá mejor las reglas de B con respecto a los datos antes de realizar el inserto), es probable que varios sistemas tengan que hacer algún tipo de sondeo de la base de datos para encontrar cualquier cambio en sus datos, el mantenimiento continuo será un dolor de cabeza, ya que cualquier cambio en un esquema de base de datos ahora propaga varios sistemas.

Mi primer pensamiento fue tomarme el tiempo y escribir API / Servicios para los diferentes sistemas, que una vez escritos podrían usarse fácilmente para pasar / recuperar datos de un lado a otro. Muchos de los otros desarrolladores consideran 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 fuera usted, haría un gran esfuerzo para evitar acceder a los datos del Sistema A directamente desde el Sistema B. Actualización La base de datos del Sistema A desde el Sistema B es extremadamente imprudente. Es exactamente lo contrario de las buenas prácticas hacer que su lógica de negocios sea tan difusa. Terminarás arrepintiéndote.

La idea de la base de datos central no es necesariamente mala ... pero la cantidad de esfuerzo involucrada probablemente esté dentro de un orden de magnitud de reescribir los sistemas desde cero. Ciertamente no es algo que intentaría, al menos en la forma que usted describe. Puede tener éxito, pero es mucho más difícil y requiere mucha más disciplina que el enfoque de integración punto a punto. Es divertido escuchar que se sugiere en el mismo aliento que el enfoque 'vaquero' de simplemente introducir datos directamente en otros sistemas.

En general, tus instintos parecen bastante buenos. Hay un par de enfoques. Mencionas uno: implementando servicios. Ese no es un mal camino, especialmente si necesita actualizaciones en tiempo real. La otra es una aplicación de integración separada que se encarga de barajar los datos. Ese es el enfoque que suelo tomar, pero generalmente porque no puedo cambiar los sistemas que estoy integrando para solicitar los datos que necesita; Tengo que introducir los datos. En su caso, el enfoque de servicios no es malo.

Una cosa que me gustaría decir que podría no ser obvio para alguien que viene a la integración del sistema por primera vez es que cada pieza de datos en su sistema debe tener un único punto de verdad autorizado. Si los datos están duplicados (y están duplicados), y las copias no están de acuerdo entre sí, la copia en el punto de verdad para esos datos debe tomarse como correcta. Simplemente no hay otra forma de integrar sistemas sin que la complejidad grite hacia el cielo a una velocidad exponencial. La integración de espagueti es como el código de espagueti, y debe evitarse a toda costa.

Buena suerte.

EDITAR:

Middleware aborda el problema del transporte, pero ese no es el problema central de la integración. Si los sistemas están lo suficientemente cerca como para que una aplicación pueda insertar datos directamente en otra, probablemente estén lo suficientemente cerca como para que un servicio ofrecido por uno pueda ser llamado directamente por otro. No recomendaría middleware en tu caso. Es posible que obtenga algún beneficio, pero eso sería superado por la mayor complejidad. Necesita resolver un problema a la vez.

Answer 2

Parece que es posible que desee investigar Message Queue Server y middleware orientado a mensajes .

MSMQ y Java Message Service son ejemplos.

Answer 3

Parece que estás buscando opiniones, así que te proporcionaré las mías.

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 sobre él si simplemente toma la otra sugerencia de crear una sola base de datos.

Answer 4

Uno de los desafíos que tendrá es alinear los datos en cada uno de los diferentes sistemas para que pueda integrarse en primer lugar. Es posible que cada uno de los sistemas que desee integrar contenga conjuntos de datos completamente diferentes, pero lo más probable es que los datos se superpongan. 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 crear un modelo de datos lógico para los datos que deben integrarse. Este modelo de datos lo ayudará a aprovechar los datos que tiene en los diferentes sistemas y lo hará más útil para las otras bases de datos.

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

Answer 5

La interfaz directa a través de las bases de datos push / poking expone muchos detalles internos de un sistema a otro. Hay desventajas obvias: la actualización de un sistema puede romper el 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 debe decidir es la plataforma donde se encuentra la " base de datos maestra " residirá, y lo mismo para el middleware que proporciona el pegamento necesario. En lugar de ir hacia la integración de middleware de nivel de API (como CORBA), le sugiero que considere el 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. Es posible que desee leer un poco sobre el patrón de Enterprise Entity Aggregation .

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

Answer 6

Si va hacia la estrategia de Middleware + Single Central Database, es posible que desee considerar lograr esto en varias fases. Aquí hay un proceso lógico escalonado que puede considerarse:

1. Implementación de servicios / API para diferentes sistemas que exponen la funcionalidad para cada sistema
2. Implementación de Middleware que accede a estas API y proporciona una interfaz a todos los sistemas para acceder a los datos / servicios desde otros sistemas (accede a los datos de la fuente central si está disponible, de lo contrario los obtiene de otro sistema)
3. Implementación de la base de datos central solamente, sin datos
4. Implementación de servicios de almacenamiento en caché / almacenamiento de datos en el nivel de middleware que puede almacenar / almacenar datos en la base de datos central cada vez que se accede a esos datos desde cualquiera de los sistemas, p. SI el Sistema B obtiene los registros 1-5 del Sistema A a través de Middleware, los Servicios de almacenamiento en caché de datos de Middleware 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 enviar datos de múltiples sistemas a la base de datos central diariamente (automatizado o manual)

De esta forma, el esfuerzo se distribuye entre múltiples hitos y los datos se almacenan gradualmente en la base de datos central en el primer acceso al primer almacenamiento.