Comment intégrer au mieux plusieurs systèmes?

Question

Ok, là où je travaille, nous maintenons un nombre assez important de systèmes écrits au cours des deux dernières décennies.

Les systèmes sont diversifiés en ce sens que plusieurs systèmes d’exploitation (Linux, Solaris, Windows), plusieurs bases de données (plusieurs versions d’Oracle, Sybase et mysql) et même plusieurs langages (C, C ++, JSP, PHP et une multitude de autres) sont utilisés.

Chaque système est assez autonome, même au prix de la saisie des mêmes données dans plusieurs systèmes.

La direction a récemment décidé que nous devions déterminer ce qu’il faudrait faire pour que tous les systèmes se parlent et se partagent des données.

N'oubliez pas que, bien que nous puissions apporter des modifications logicielles à l'un des systèmes individuels, une réécriture complète d'un système (ou de plusieurs) n'est pas envisageable pour la direction.

La première pensée de plusieurs développeurs ici était la suivante: si le système A a besoin de données du système B, il doit simplement se connecter à la base de données du système B et l’obtenir. De même, si elle doit fournir des données à B, elle doit simplement les insérer dans la base de données de B.

En raison du fouillis de bases de données (et de versions) utilisées, d'autres développeurs étaient d'avis qu'il fallait créer une nouvelle base de données, combinant les tables de tous les autres systèmes pour éviter de devoir jongler avec plusieurs connexions. Ce faisant, ils espèrent que nous pourrons peut-être consolider certaines tables et éliminer l’entrée de données redondante.

C’est à peu près le moment où j’ai été invité à donner mon opinion sur l’ensemble du gâchis.

L’idée d’utiliser la base de données comme moyen de communication avec le système me semble étrange. La logique métier devra être placée dans plusieurs systèmes (si le système A souhaite ajouter des données au système B, il comprend mieux les règles de B relatives aux données avant de procéder à l'insertion), plusieurs systèmes devront probablement effectuer une interrogation de base de données pour trouver toute modification de leurs données, la maintenance continue sera un casse-tête, car toute modification apportée à un schéma de base de données propage désormais plusieurs systèmes.

Ma première idée a été de prendre le temps nécessaire pour écrire des API / services pour les différents systèmes, lesquels, une fois écrits, pourraient facilement être utilisés pour transmettre / récupérer des données dans les deux sens. De nombreux autres développeurs estiment que cela est excessif et qu’il nécessite beaucoup plus de travail que la simple utilisation de la base de données.

Alors, quel serait le meilleur moyen de faire en sorte que ces systèmes se parlent?

Answer 1

Intégrer des systèmes disparates est mon travail quotidien.

Si j'étais vous-même, je ferais des efforts considérables pour éviter d'accéder aux données du système A directement à partir du système B. Mettre à jour La base de données du système A à partir du système B est extrêmement peu judicieuse. C’est exactement le contraire de la bonne pratique pour rendre votre logique d’affaires si diffuse. Vous finirez par le regretter.

L’idée de la base de données centrale n’est pas forcément mauvaise. Toutefois, la quantité d’efforts nécessaire est probablement d’un ordre de grandeur pour réécrire les systèmes à partir de zéro. Ce n’est certainement pas quelque chose que je tenterais, du moins sous la forme que vous décrivez. Cela peut réussir, mais c'est beaucoup, beaucoup plus difficile et cela demande beaucoup plus de discipline que l'approche d'intégration point à point. Il est amusant de l’entendre suggérer dans le même souffle que l’approche «cow-boy» consistant à transférer des données directement dans d’autres systèmes.

Globalement, vos instincts semblent plutôt bons. Il y a plusieurs approches. Vous en mentionez un: la mise en œuvre de services. Ce n'est pas une mauvaise façon de faire, surtout si vous avez besoin de mises à jour en temps réel. L’autre est une application d’intégration distincte chargée de réorganiser les données. C’est l’approche que j’adopte 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 à l'intérieur. Dans votre cas, l'approche par les services n'est pas mauvaise.

Une chose que je voudrais dire et qui n’est peut-être pas évident pour une personne qui s’intéresse à l’intégration de système pour la première fois est que chaque donnée de votre système doit avoir un seul point de vérité faisant autorité. Si les données sont dupliquées (et elles sont dupliquées) et que les copies ne sont pas compatibles, la copie exacte des données doit être considérée comme correcte. Il n’existe tout simplement aucun autre moyen d’intégrer des systèmes sans faire en sorte que la complexité crie au ciel à une vitesse exponentielle. L’intégration des spaghettis est comme un code spaghetti et il faut l’éviter à tout prix.

Bonne chance.

EDIT:

Le middleware aborde le problème du transport, mais ce n’est pas le problème central de l’intégration. Si les systèmes sont suffisamment proches les uns des autres pour qu'une application puisse transférer des données directement dans une autre, ils sont probablement suffisamment proches pour qu'un service offert par l'une d'elles puisse être appelé directement par une autre. Je ne recommanderais pas le middleware dans votre cas. Vous en tirerez peut-être des avantages, mais la complexité accrue de la situation l’emportera. Vous devez résoudre un problème à la fois.

Answer 2

Vous voudrez peut-être explorer le Message Queuing et middleware orienté message .

MSMQ et Service de messagerie Java , à titre d'exemples.

Answer 3

Il semble que vous recherchiez des opinions, je vais donc fournir les miennes.

Je suis d'accord avec les autres développeurs pour dire qu'il est excessif d'écrire une API pour tous les systèmes. Vous le feriez probablement plus vite et en auriez beaucoup plus le contrôle si vous preniez simplement l’autre suggestion de créer une base de données unique.

Answer 4

L’un des défis à relever consiste à aligner les données de chacun des différents systèmes de manière à ce qu’elles puissent être intégrées en premier lieu. Il se peut que chacun des systèmes que vous souhaitez intégrer contienne des ensembles de données entièrement différents, mais il est plus probable que ce soient des données qui se chevauchent. Avant de plonger dans l’écriture d’API: s (c’est la voie que j’aimerais emprunter compte tenu de votre description), je vous recommanderais d’essayer de créer un modèle de données logique pour les données à intégrer. 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 recommanderais également fortement une approche itérative de l'intégration. Avec les systèmes existants, l'incertitude est telle qu'il est trop risqué d'essayer de concevoir et de mettre en œuvre tout cela en même temps. Commencez petit et travaillez à un système raisonnablement intégré. " Entièrement intégré " vaut à peine la peine de viser.

Answer 5

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 limites techniques à la manière 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 va interagir avec une base de données SQL Server 2005 exécutée sur Windows 2003 Server).

La première chose que vous devez choisir est la plate-forme sur laquelle la " base de données maître " résidera, et la même chose pour le middleware fournissant la colle nécessaire. Au lieu d’aller vers une intégration middleware de niveau API (telle que CORBA), je vous suggère d’envisager le middleware orienté message. MS Biztalk, l'eGate de Sun et la fusion d'Oracle peuvent être quelques-unes des options.

Votre idée d'une nouvelle base de données est un pas dans la bonne direction. Vous aimerez peut-être lire un peu sur le modèle Agrégation d'entités d'entreprise .

Une combinaison de "intégration de données" " avec un middleware est la voie à suivre.

Answer 6

Si vous optez pour la stratégie Middleware + Single Central Database, vous pouvez envisager de le faire en plusieurs étapes. Voici un processus logique qui peut être envisagé:

1. Implémentation de services / API pour différents systèmes exposant les fonctionnalités de chaque système
2. Implémentation d'un middleware qui accède à ces API et fournit une interface à tous les systèmes pour accéder aux données / services depuis d'autres systèmes (accède aux données depuis une source centrale si elles sont disponibles, sinon elles les obtiennent d'un autre système)
3. Implémentation de la base de données centrale uniquement, sans données
4. Mise en œuvre de services de mise en cache / stockage de données au niveau middleware permettant de stocker / mettre en cache des données dans la base de données centrale chaque fois que ces données sont accessibles à partir de l'un des systèmes, par ex. SI les enregistrements 1 à 5 du système A sont extraits par le système B via un middleware, les services de mise en cache des données du 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. Le nettoyage des données peut avoir lieu en parallèle
6. Vous pouvez également créer un mécanisme d'importation permettant de transférer quotidiennement (de manière automatisée ou manuelle) les données de plusieurs systèmes vers la base de données centrale.

De cette manière, l'effort est réparti sur plusieurs jalons et les données sont progressivement stockées dans la base de données centrale sur la base du premier accès au premier stocké.