Richtlinie: Integration traditioneller Anwendungen in moderne Architekturen
Diese Richtlinie ist eine Übersicht über die Strategien für die Modernisierung "traditioneller Systeme" durch Integration mit neuen Anwendungen.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

Die geschäftskritischen Systeme oder "traditionellen Systeme" vieler großer Unternehmen sind häufig in großen, monolithischen Anwendungen ohne standardisierte Schnittstellen vergraben und mit älteren Programmiersprachen wie COBOL entwickelt. Viele dieser Unternehmen möchten Internet-, Intranet-, E-Commerce- und andere neue Technologien verwenden, um wettbewerbsfähig zu bleiben. Das Umschreiben dieser traditionellen Schlüsselsysteme kann unter Umständen jedoch aus finanzieller (zu teuer) oder technischer (ursprüngliche Programmierer sind nicht mehr im Unternehmen) oder zeitlicher (wir können uns Abwarten nicht leisten) Hinsicht nicht machbar sein. Deshalb entscheiden sich viele Unternehmen für die Alternative, ihre "traditionellen Systeme" durch Integration mit neuen Anwendungen zu modernisieren.

Die gängigste Methode für eine solche Integration ist die Integration von Unternehmensanwendungen (EAI, Enterprise Application Integration), bei der eine Kommunikationsinfrastruktur zwischen den verschiedenen Unternehmensanwendungen (neue und traditionelle) implementiert wird.

Integrationsstrategie für traditionelle Systeme

Die Integration traditioneller Systeme kann in zwei Hauptkategorien unterteilt werden:

Nicht invasiv

Nicht invasive Strategien sind Strategien, die die traditionelle Anwendung gar nicht ändern oder nur geringfügige Änderungen vornehmen. Diese Strategie ist kostengünstiger, aber auch weniger flexibel. Dieser Ansatz wird normalerweise verwendet, wenn die Integration von Unternehmensanwendungen auf Benutzerschnittstellenebene, auf Datenebene oder manchmal auf Anwendungsschnittstellenebene durchgeführt wird.

Wenn die Integration auf Benutzerschnittstellenebene durchgeführt wird, werden die vorhandenen textbasierten Anzeigen durch browserbasierte Anzeigen ersetzt, die in ein Unternehmensgeschäftsportal integriert werden. Auch wenn diese Art der Integration gewöhnlich als instabil und archaisch eingestuft wird, ist sie manchmal der pragmatischste Weg für die Integration traditioneller Systeme, die keine Zugriffe auf Datenbank- oder Geschäftsprozessebene unterstützen.

Die Integration auf Datenebene kann durch Wiederverwendung der vorhandenen traditionellen Datenbank oder durch Extraktion der Daten aus der vorhandenen Datenbank und anschließende Aktualisierung einer neuen Datenbank mit einer ETL-Lösung (Extract, Transform, Load) erfolgen. Auch wenn dieser Ansatz attraktiv scheint, lässt er sich manchmal schwierig implementieren, da in der Geschäftslogik der traditionellen Anwendungen häufig Datenkonvertierung, Bedingungen und Steuerelemente implementiert sind.

Die nicht invasive Integration auf Anwendungsschnittstellenebene (oder "Legacy Wrapping" ) bietet ein wenig mehr Flexibilität. Bei diesem Ansatz erstellen Sie aufrufbare Anwendungsprogrammierschnittstellen (API, Application Programming Interfaces) für traditionelle Transaktionen. Da dieser Ansatz vorhandene traditionelle Transaktionen nutzt, ist er kostengünstig und vermeidet die Schwierigkeiten, die mit der Integration auf Datenebene verbunden sind. Durch die Konvertierung der Transaktionen in APIs bietet dieser Ansatz mehr Flexibilität als die Integration auf Benutzerebene. Damit der Ansatz jedoch nicht invasiv bleibt, kann er nicht verwendet werden, um Geschäftsfunktionen zu ändern und zu erweitern. Hierfür benötigen Sie einen invasiven Ansatz.

Invasiv

Eine invasive Strategie setzt voraus, dass Sie funktionalen traditionellen Code ändern müssen. Ganz offensichtlich sind mit diesem Ansatz mehr Risiken und Kosten verbunden, da traditioneller Code gewöhnlich alt und nicht besonders gut dokumentiert ist und die Programmierer, die den Code geschrieben haben, in den seltensten Fällen noch verfügbar sind. Allerdings ist dieser Ansatz auch derjenige, der Ihnen mehr Flexibilität und die Möglichkeit gibt, vorhandene Geschäftsprozesse und -funktionen zu modifizieren und zu erweitern. Dieser Ansatz wird gewöhnlich für die Integration von Unternehmensanwendungen auf Anwendungsschnittstellenebene verwendet, wenn Sie APIs benötigen, die den vorhandenen traditionellen Transaktionen nicht entsprechen. Dieser Ansatz kann auch für die Integration von Unternehmensanwendungen auf Methodenebene verwendet werden, aber ein Refactoring des vorhandenen Codes für die Bereitstellung gemeinsam genutzter Methoden ist häufig zu kostenintensiv.

Ein Integrationsansatz auf Anwendungsschnittstellenebene ist die Verwendung von traditionellen e-Komponenten. Bei diesem Ansatz wird die traditionelle Anwendung in eine Sammlung autonomer Geschäftskomponenten partitioniert. Jede Komponente stellt eine klar definierte Gruppe von APIs bereit, die die Umstellung von einer strengen Konnektivität zwischen Programmen auf einen nachrichtenbasierten Ansatz mit flexiblen Verbindungen vereinfacht, der mit entsprechenden Komponentenmodellen auf mehreren Plattformen eingesetzt und in die Gesamtarchitektur integriert werden kann. Dieser Ansatz kann präzisiert werden, um jede "traditionelle e-Komponente" mit Hilfe von XML-Web-Services in Form eines oder mehrerer Services in einer serviceorientierten Architektur (SOA) zu definieren. Weitere Informationen finden Sie in Konzept: Einführung in die serviceorientierte Architektur.

Da invasive Ansätze gewöhnlich kostenintensiver und aus Architektursicht risikoreicher sind als nicht invasive Ansätze, sollten Sie sich für einen iterativen Ansatz entscheiden, der die Risiken mindert und die Machbarkeit der Architektur in den frühen Iterationen nachweist.