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 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.
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.
|