Wie integriert man mehrere Systeme am besten?

Question

Ok, dort, wo ich arbeite, gibt es eine ziemlich große Anzahl von Systemen, die in den letzten Jahrzehnten geschrieben wurden und die wir pflegen.

Die Systeme sind insofern vielfältig, als sie mehrere Betriebssysteme (Linux, Solaris, Windows), mehrere Datenbanken (mehrere Versionen von Oracle, Sybase und MySQL) und sogar mehrere Sprachen (C, C++, JSP, PHP und viele andere) umfassen gebraucht.

Jedes System ist ziemlich autonom, auch wenn die gleichen Daten in mehrere Systeme eingegeben werden müssen.

Das Management hat kürzlich beschlossen, dass wir untersuchen sollten, was nötig ist, damit alle Systeme reibungslos miteinander kommunizieren und Daten austauschen.

Bedenken Sie, dass wir zwar Softwareänderungen an jedem der einzelnen Systeme vornehmen können, eine vollständige Neufassung eines Systems (oder mehrerer) jedoch wahrscheinlich nicht für das Management in Frage kommt.

Der erste Gedanke einiger Entwickler hier war Folgendes:Wenn System A Daten von System B benötigt, sollte es sich einfach mit der Datenbank von System B verbinden und diese abrufen.Wenn es B-Daten bereitstellen muss, sollte es diese einfach in die Datenbank von B einfügen.

Aufgrund des Durcheinanders der verwendeten Datenbanken (und Versionen) waren andere Entwickler der Meinung, dass wir eine neue Datenbank haben sollten, die die Tabellen aller anderen Systeme kombiniert, um zu vermeiden, dass wir mit mehreren Verbindungen jonglieren müssen.Sie hoffen, dass wir dadurch einige Tabellen konsolidieren und die redundante Dateneingabe beseitigen können.

Dies ist ungefähr der Zeitpunkt, an dem ich um meine Meinung zu dem ganzen Schlamassel gebeten wurde.

Die ganze Idee, die Datenbank als Mittel zur Systemkommunikation zu nutzen, kommt mir komisch vor.Die Geschäftslogik muss in mehreren Systemen platziert werden (wenn System A Daten zu System B hinzufügen möchte, muss es die Regeln von B bezüglich der Daten besser verstehen, bevor es das Einfügen durchführt). Mehrere Systeme müssen höchstwahrscheinlich irgendeine Form von Datenbankabfrage durchführen, um sie zu finden Bei Änderungen an ihren Daten wird die fortlaufende Wartung ein Problem darstellen, da jede Änderung an einem Datenbankschema nun mehrere Systeme propagiert.

Mein erster Gedanke war, mir die Zeit zu nehmen und APIs/Dienste für die verschiedenen Systeme zu schreiben, die nach dem Schreiben problemlos zum Hin- und Herleiten von Daten verwendet werden könnten.Viele andere Entwickler halten das für übertrieben und weitaus aufwändiger als nur die Nutzung der Datenbank.

Was wäre also der beste Weg, um diese Systeme dazu zu bringen, miteinander zu kommunizieren?

Answer 1

Die Integration von unterschiedlichen Systemen ist mein Job.

Wenn ich Sie wäre, ich große Mühe gehen würde zu vermeiden, den Zugriff auf Daten des Systems A direkt aus System B Aktualisieren System A Datenbank von System B ist äußerst unklug. Es ist genau das Gegenteil von guter Praxis, um Ihre Business-Logik so diffus zu machen. Sie werden es am Ende Bedauern darüber.

Die Idee der zentralen Datenbank ist nicht unbedingt schlecht ... aber die Menge an Aufwand ist wahrscheinlich in einer Größenordnung der Systeme von Grund auf neu zu schreiben. Es ist sicherlich nicht etwas, was ich würde beschreiben Sie, zumindest in der Form versuchen. Es kann erfolgreich sein, aber es ist viel, viel härter und es braucht viel mehr Disziplin als der Punkt-zu-Punkt-Integration-Ansatz. Es ist komisch zu hören, es im gleichen Atemzug als ‚Cowboy‘ -Ansatz von nur schiebend Daten direkt in andere Systeme vorgeschlagen.

Insgesamt Ihre Instinkte scheinen ziemlich gut. Es gibt ein paar Ansätze. Sie erwähnen ein: Implementierungsdienstleistungen. Das ist kein schlechter Weg zu gehen, vor allem, wenn Sie Updates in Echtzeit benötigen. Die andere ist eine separate Integration Anwendung, die für das Mischen der Daten um verantwortlich ist. Das ist der Ansatz, den ich in der Regel nehmen, aber in der Regel, weil ich nicht die Systeme ändern kann ich für die Daten zu fragen, bin zu integrieren es braucht; Ich habe die Daten eindrücken. In Ihrem Fall des Service-Ansatz ist nicht schlecht.

Eine Sache, Ich mag würde sagen, dass nicht offensichtlich sein könnte jemand zum ersten Mal über die Systemintegration kommt, ist, dass jedes Stück von Daten in Ihrem System einen einzigen, maßgeblichen Punkt der Wahrheit haben sollte. Wenn die Daten dupliziert wird (und es dupliziert wird), und die Kopien nicht miteinander übereinstimmen, die Kopie in dem Punkt der Wahrheit für diese Daten müssen korrekt sein getroffen werden. Es gibt einfach keine andere Möglichkeit, Systeme zu integrieren, ohne die Komplexität mit einer exponentiellen Rate gen Himmel mit schreien. Spaghetti-Integration ist wie Spaghetti-Code, und es sollte auf jeden Fall vermieden werden.

Viel Glück.

EDIT:

Middleware behandelt das Problem des Verkehrs, aber das ist nicht das zentrale Problem bei der Integration. Wenn die Systeme nahe genug beieinander, dass eine App-Daten direkt in ein anderes schieben kann, sind sie wahrscheinlich nahe genug, dass eine von einer angebotenen Dienstleistung direkt von einer anderen aufgerufen werden kann. Ich würde nicht Middleware in Ihrem Fall empfehlen. Sie könnten einen Nutzen daraus ziehen, aber das würde durch die erhöhte Komplexität aufgewogen werden. Sie benötigen ein Problem auf einmal zu lösen.

Answer 2

Klingt wie Sie Message Queuing und Message Oriented Middleware .

MSMQ und Java Message Service Beispiele hierfür werden.

Answer 3

Es scheint, dass Sie für Meinungen suchen, also werde ich mein liefern.

ich mit den anderen Entwickler zustimmen, die für die verschiedenen Systeme eine API schreiben zu hoch ist. Sie würden es wahrscheinlich schneller zu erledigen und haben viel mehr Kontrolle über sie, wenn Sie nur den anderen Vorschlag nehmen eine einzige Datenbank zu schaffen.

Answer 4

Eine der Herausforderungen, die Sie haben, ist es, die Daten in jedem der verschiedenen Systeme auszurichten, so dass es in erster Linie integriert werden kann. Es kann sein, dass jedes der Systeme, die Sie hält ganz andere Sätze von Daten integrieren wollen, aber desto wahrscheinlicher ist es, die Daten überlappend ist. Vor dem Tauchen in dem Schreiben von API: s (das ist die Strecke, die ich auch angesichts Ihre Beschreibung nehmen würde) Ich würde empfehlen, dass Sie versuchen, und kommen mit einem logischen Datenmodell für die Daten, die integriert werden muss. Dieses Datenmodell wird dann helfen Sie die Daten nutzen, die Sie in den verschiedenen Systemen haben und machen es sinnvoller zu den anderen Datenbanken.

Ich würde auch sehr einen iterativen Ansatz zur Integration empfehlen. Mit Legacy-Systemen gibt es so viel Unsicherheit, dass es alles in einem Rutsch zu entwerfen versuchen und implementieren zu riskant ist. Fangen Sie klein an und arbeiten Sie sich zu einem einigermaßen integrierten System. „Voll integriert“ ist kaum erstrebenswert.

Answer 5

Direkt über Schiebe- / Stossen Datenbanken Schnittstelle macht eine Menge interner Detail einem System zum anderen. Es gibt offensichtliche Nachteile: ein System aktualisieren können die anderen brechen. Darüber hinaus kann es in technischen Einschränkungen sein, wie ein System die Datenbank des anderen zugreifen kann (man denke an, wie eine Anwendung in C unter Unix geschrieben mit einer SQL Server 2005-Datenbank auf Windows 2003 Server interagieren).

Das erste, was Sie entscheiden müssen, ist die Plattform, wo die „Master-Datenbank“ befinden wird, und das gleiche gilt für die Middleware des dringend benötigten Klebstoff bereitstellt. Statt auf Middleware-Integration API-Ebene (zB CORBA) zu gehen, würde ich vorschlagen, dass Sie Message Oriented Middleware zu betrachten. MS Biztalk, Suns eGate und Oracle Fusion können einige der Optionen sein.

Ihre Idee einer neuen Datenbank ist ein Schritt in der richtigen Richtung. Vielleicht möchten Sie ein wenig auf Unternehmen Entity Aggregation Muster lesen.

Eine Kombination aus „Datenintegration“ mit einer Middleware ist der Weg zu gehen.

Answer 6

Wenn Sie sich für die Strategie „Middleware + Single Central Database“ entscheiden, sollten Sie darüber nachdenken, dies in mehreren Phasen zu erreichen.Hier ist ein logischer schrittweiser Prozess, der in Betracht gezogen werden kann:

1. Implementierung von Diensten/APIs für verschiedene Systeme, die die Funktionalität für jedes System bereitstellen
2. Implementierung von Middleware, die auf diese APIs zugreift und eine Schnittstelle zu allen Systemen bereitstellt, um auf die Daten/Dienste anderer Systeme zuzugreifen (greift auf Daten von einer zentralen Quelle zu, sofern verfügbar, andernfalls bezieht sie sie von einem anderen System)
3. Implementierung nur der zentralen Datenbank, ohne Daten
4. Implementierung von Caching-/Datenspeicherdiensten auf Middleware-Ebene, die Daten in der zentralen Datenbank speichern/zwischenspeichern können, wann immer auf diese Daten von einem der Systeme zugegriffen wird, z. B.Wenn die Datensätze 1–5 von System A von System B über Middleware abgerufen werden, können die Middleware-Daten-Caching-Dienste diese Datensätze in der zentralen Datenbank speichern und beim nächsten Mal werden diese Datensätze aus der zentralen Datenbank abgerufen
5. Die Datenbereinigung kann parallel erfolgen
6. Sie können auch einen Importmechanismus erstellen, um täglich Daten aus mehreren Systemen in die zentrale Datenbank zu übertragen (automatisiert oder manuell).

Auf diese Weise wird der Aufwand auf mehrere Meilensteine ​​verteilt und die Daten werden nach und nach in der zentralen Datenbank nach dem Prinzip „Wer zuerst aufgerufen wird, mahlt zuerst“ gespeichert.