Comment intégrer au mieux plusieurs systèmes?

Question

Ok où je travaille, nous avons un nombre assez important de systèmes écrits au cours des deux dernières décennies que nous maintenons. Les systèmes sont divers: systèmes d'exploitation multiples (Linux, Solaris, Windows), bases de données multiples (plusieurs versions d'oracle, sybase et mysql) et même plusieurs langues (C, C++, JSP, PHP et un hôte). d'autres) sont utilisés.

Chaque système est assez autonome, même au prix d'entrer les mêmes données dans plusieurs systèmes.

La direction a récemment décidé que nous devions étudier ce qu'il faudrait faire pour que tous les systèmes se parlent entre eux et partagent des données. Gardez à l'esprit que, même si nous pouvons apporter des modifications logicielles à l'un des systèmes individuels, une réécriture complète d'un système (ou plus) n'est pas quelque chose que la direction est susceptible de divertir. La première pensée de plusieurs des développeurs ici était la suivante: Si le système A a besoin de données du système B, il devrait simplement se connecter à la base de données du système B et l'obtenir. De même, s'il doit donner des données B, il suffit de l'insérer dans la base de données de B. En raison du désordre des bases de données (et des versions) utilisées, d'autres développeurs étaient d'avis que nous devrions avoir une nouvelle base de données, combinant les tables de tous les autres systèmes pour éviter d'avoir à jongler avec plusieurs connexions. En faisant cela, ils espèrent pouvoir consolider certaines tables et se débarrasser de l'entrée de données redondante.

C'est à peu près au moment où j'ai été amené à donner mon opinion sur tout ce bazar.

L'idée d'utiliser la base de données comme moyen de communication système me semble drôle. La logique métier devra être placée dans plusieurs systèmes (si le Système A veut ajouter des données au Système B, il comprendra mieux les règles de B concernant les données avant de faire l'insertion), plusieurs systèmes devront probablement faire une sorte de sondage de base de données pour trouver Toute modification de leurs données, la maintenance continue sera un casse-tête, comme toute modification à un schéma de base de données propage maintenant plusieurs systèmes. Ma première pensée était de prendre le temps et d'écrire des API/services pour les différents systèmes, qui, une fois écrits, pouvaient facilement être utilisés pour transmettre/récupérer des données. Beaucoup d'autres développeurs pensent que c'est un travail excessif et beaucoup plus que de simplement utiliser la base de données.

Alors, quelle serait la meilleure façon de faire communiquer ces systèmes entre eux?

Answer 1

L'intégration de systèmes hétérogènes est mon travail quotidien.

Si j'étais vous, je ferais beaucoup d'efforts pour éviter d'accéder aux données du système A directement dans le système B.Mise à jour La base de données du système A du système B est extrêmement imprudente. C'est exactement le contraire de la bonne pratique pour rendre votre logique métier si diffuse. Vous finirez par le regretter.

L'idée de la base de données centrale n'est pas nécessairement mauvaise ... mais la quantité d'effort impliquée est probablement dans un ordre de grandeur de réécrire les systèmes à partir de zéro. Ce n'est certainement pas quelque chose que je tenterais, du moins dans la forme que vous décrivez. Cela peut réussir, mais c'est beaucoup, beaucoup plus difficile et il faut beaucoup plus de discipline que l'approche d'intégration point à point. C'est drôle de l'entendre suggérer dans le même souffle que l'approche «cow-boy» consistant simplement à envoyer des données directement dans d'autres systèmes.

Dans l'ensemble, votre instinct semble assez bon. Il y a plusieurs approches. Vous en mentionnez un: la mise en place de services. Ce n'est pas une mauvaise façon de procéder, surtout si vous avez besoin de mises à jour en temps réel. L'autre est une application d'intégration distincte qui est responsable du mélange des données. C'est l'approche que je prends habituellement, mais généralement parce que je ne peux pas changer les systèmes que j'intègre pour demander les données dont il a besoin; Je dois pousser les données. Dans votre cas, l'approche des services n'est pas mauvaise. Une chose que je voudrais dire qui pourrait ne pas être évidente pour quelqu'un qui arrive à l'intégration du système pour la première fois est que chaque élément de données dans votre système devrait avoir un point de vérité unique et faisant autorité. Si les données sont dupliquées (et qu'elles sont dupliquées), et que les copies ne sont pas en accord, la copie dans le point de vérité pour ces données doit être considérée comme correcte. Il n'y a tout simplement pas d'autre moyen d'intégrer des systèmes sans que la complexité ne crie vers le ciel à un rythme exponentiel. L'intégration des spaghettis est comme le code spaghetti, et il faut l'éviter à tout prix.

Bonne chance.

EDIT:

Middleware aborde le problème du transport, mais ce n'est pas le problème central en matière d'intégration. Si les systèmes sont suffisamment proches les uns des autres pour qu'une application puisse envoyer des données directement dans une autre, ils sont probablement suffisamment proches pour qu'un service offert par l'un puisse être appelé directement par un autre. Je ne recommanderais pas middleware dans votre cas. Vous pourriez en tirer profit, mais cela serait compensé par la complexité accrue. Vous devez résoudre un problème à la fois.

Answer 2

Il semble que vous cherchez des opinions, alors je vais fournir le mien. Je suis d'accord avec les autres développeurs sur le fait qu'écrire une API pour tous les différents systèmes est excessif. Vous obtiendrez probablement plus rapidement et vous aurez plus de contrôle si vous prenez simplement l'autre suggestion de créer une base de données unique.

Answer 3

Il semble que vous souhaitiez rechercher Message Queuing et message-oriented middleware.

MSMQ et Java Message Service étant des exemples.

Answer 4

L'interfaçage direct via des bases de données push/poking expose beaucoup de détails internes d'un système à un autre. Il y a des inconvénients évidents: la mise à niveau d'un système peut casser l'autre. De plus, il peut y avoir des limitations techniques dans la façon dont un système peut accéder à la base de données de l'autre (considérez comment une application écrite en C sur Unix interagira avec une base de données SQL Server 2005 exécutée sous Windows 2003 Server). La première chose que vous devez décider est la plate-forme où la "base de données principale" résidera, et la même chose pour le middleware fournissant la colle nécessaire. Au lieu d'aller vers l'intégration de middleware au niveau de l'API (comme CORBA), je vous suggère de considérer le Middleware orienté message. MS Biztalk, eGate de Sun et Oracle Fusion peuvent être quelques-unes des options.

Votre idée d'une nouvelle base de données est un pas dans la bonne direction. Vous pourriez aimer lire un peu sur le modèle Enterprise Entity Aggregation.

Une combinaison de «l'intégration de données» avec un intergiciel est la voie à suivre.

Answer 5

L'un des défis que vous aurez à relever est d'aligner les données dans chacun des différents systèmes afin qu'ils puissent être intégrés en premier lieu. Il se peut que chacun des systèmes que vous souhaitez intégrer contient des ensembles de données entièrement différents, mais il est plus probable que ce soit des données qui se chevauchent.Avant de plonger dans l'écriture de l'API: s (qui est la route que je prendrais aussi étant donné votre description), je vous recommande d'essayer de trouver un modèle de données logique pour les données qui doivent être intégrées. Ce modèle de données vous aidera ensuite à exploiter les données que vous avez dans les différents systèmes et à les rendre plus utiles aux autres bases de données.

Je recommande également fortement une approche itérative de l'intégration. Avec les systèmes existants, il y a tellement d'incertitudes qu'il est trop risqué d'essayer de concevoir et de mettre en œuvre tout cela en une fois. Commencez petit et travaillez votre chemin vers un système raisonnablement intégré. "Entièrement intégré" ne vaut presque jamais la peine d'être visé.

Answer 6

Si vous allez vers la stratégie Middleware + Base de données centrale unique, vous pouvez envisager d'y parvenir en plusieurs phases. Voici le développement du processus logique qui peut être considéré:

1. Mise en œuvre des services/API pour les systèmes différents qui exposent la fonctionnalité pour chaque système
2. La mise en œuvre de Middleware qui accède à ces API et fournit une interface pour tous les systèmes de accéder aux données/services provenant d'autres systèmes (les accès des données de source centrale si elle est disponible, sinon il obtient d'un autre système)
3. Mise en œuvre de la base de données centrale uniquement, sans données
4. Application Caching/services de stockage de données au niveau de Middleware qui peut stocker/mettre en cache des données dans la base de données centrale se chaque fois que l'on accède à ces données à partir de l'un des systèmes, par ex. Si les enregistrements du système A 1-5 sont récupérés par le système B via le middleware, les services de mise en cache des données Middleware peuvent stocker ces enregistrements dans la base de données centralisée et la prochaine fois que ces enregistrements seront extraits de la base de données centrale.
5. Vous pouvez également créer un mécanisme d'importation pour pousser les données de plusieurs systèmes à la base de données centrale sur une base quotidienne (automatique ou manuel)

de cette façon, l'effort est réparti sur plusieurs étapes et les données sont progressivement stockées dans la base de données centrale sur la première base accédée en premier.