In modernen Geschäftsumgebungen gibt es eine ganze Reihe von Standardanwendungen und selbst entwickelten Lösungen. Gerade letztere haben sich in der Vergangenheit entwickelt, da Standardkomponenten nicht immer den Erfordernissen eines modernen Geschäftsbetriebs gerecht wurden. Die Standardanwendungen hingegen haben oftmals durch komplizierte und/oder unbrauchbare Schnittstellen ausgezeichnet, die in vielen Fällen den Wünschen der Anwender zuwiderliefen, anstatt diese zu unterstützen.
In diesem Umfeld hat sich EAI entwickelt - als Möglichkeit, beliebige Anwendungen in einem heterogenen Umfeld miteinander zu verknüpfen. Dies erfolgt auch Ebene der Daten und erfolgt über orchestrierten und geordneten Austausch der Daten über Anwendungsebenen hinweg.
Die Notwendigkeit ist dabei relativ klar, wenn man überlegt, das ein Unternehmen Daten zwischen Anwendungen austauschen können muss. Sofern die bestehenden Anwendungen hinreichend “gute” Export-/Importmöglichkeiten bietet, gibt es erstmal keine Notwendigkeit, eine EAI Infrastruktur zu realisieren. Steigt aber die Anzahl der Schnittstellen an, bzw. sollen viele Datenstrecken realisiert werden, führt dies zu Point-to-Point Verbindungen, die nicht gewünscht sind, da der Verwaltungsaufwand und die Administration extrem steigt. Zudem wird das ganze Gebildet recht schnell unübersichtlich.
In diesem Umfeld bietet sich ein zentraler Hub an, der für den Datenaustausch zuständig ist - die EAI Plattform.
Die Frage, die technisch interessant ist, ist die nach der Motivation. Reichen die Argumente, die eine EAI Plattform bieten kann:
- Auflösen der Point-to-Point Verbindungen
- Entflechtung und Harmonisierung der unterschiedlichen Datenströme
- schnelle und zentrale Anpassung bzw. Änderbarkeit von Datenflüssen
aus, um sich für eine Einführung zu entscheiden?
Diese Frage hat sich sicherlich vor einiger Zeit noch gestellt, als es wenige Alternativen gibt - diese waren vor allem auch noch zumeist proprietär. Das immer gleiche Problem, dass es zu lösen gab und gibt ist, dieses:
Auf welche Art und Weise kann die IT auf die sich immer schneller ändernden Anforderungen der Geschäftswelt reagieren? Ergänzt wird dies in letzter Zeit noch mit dem Zusatz: Welchen Beitrag zum Gesamtergebnis eines Unternehmens kann die IT leisten?
Um die Gunst der IT-Entscheider ranken sich mittlerweile die Konzepte EAI, SOA, EDA und ESB.
Dabei verspricht EAI, das Business zu beschleunigen, indem die Datenströme in einem Unternehmen beschleunigt und “gestreamlined” werden. In einem Umfeld, in dem vor allem der Datenaustausch als zentrales Problem gesehen wird, die Anwendungen für sich genommen aber funktional ausreichend sind, ist dies die richtige Entscheidung. Hierbei handelt es sich also um eine Infrastruktur-Disziplin.
Dem gegenüber verspricht SOA die Geschäftsprozesse zu beschleunigen, in dem die Geschäftsprozesse analysiert werden, aufgespaltet werden in Komponenten (sogenannte Services) und anschließend über eine dynamische Orchestrierung wieder zusammengefügt werden. Hier wird ein Schritt weiter gegangen, als bei der EAI Architektur. Anstelle die Datenströme zu optimieren (und damit implizit auch einen Beitrag zur Geschäftsprozessoptimierung in zeitlicher Hinsicht) wird bei SOA der Geschäftsprozess insofern in den Mittelpunkt gestellt, als die Abbildung des gesamten Prozesses in technischer Form zu einer ganzheitlichen Orchestrierbarkeit führt. Hierbei gehört der zugehörige Datenaustausch natürlich mit ins Konzept, wird aber eher zweitrangig “mitbehandelt”. Der EAI Gedanke wird mit einbezogen und ggf. ein Teilen umgesetzt, der Fokus liegt aber klar auf dem Prozess.
Betrachtet man EDA, so handelt es sich nicht um eine technische Lösung, sondern vielmehr um ein Architekturpattern, die Event-Driven-Architecture. Diese zielt darauf ab, gerade in gewachsenen Strukturen dazu zu kommen, sich von festen Zeitpunkten zu lösen und die Plattform und die darauf laufenden Applikationen eng aneinander zu koppeln. Dabei wird jeder Prozessschritt an den nächsten angekoppelt (unter Verwendung von Triggern oder ähnlichen Ereignissteuerungen), um damit eine möglichst enge Verzahnung zu erreichen. Durch eine solche Kopplung soll erreicht werden, dass auf unnötige Wartezeiten verzichtet wird. Hierbei handelt es sich ganz klar um eine techologisch losgelöste Vorgehensweise, die sowohl mit EAI Plattformen als auch mit SOA Architekturen umgesetzt werden kann.
Als letztes tritt ESB an, die Gunst der IT’ler zu erwerben. Dabei handelt es sich um eine Architektur und Plattform, um Komponenten mit bestimmten Schnittstellen in ein Ganzes zu führen. Das bedeutet, man installiert eine Plattform und installiert auf dieser Plattform einzelne Komponenten. Jede dieser Komponenten hält sich an eine vorgegebene Schnittstelle und die Plattform kümmert sich um die Ansteuerung der einzelnen Module. Welche davon in welcher Reihenfolge angesprochen werden, ist der jeweiligen Konfiguration zu entnehmen, die mit ausgeliefert wird. Dadurch können Änderungen sehr schnell umgesetzt werden, da lediglich die Konfiguration angepasst wird. Im Falle von Änderungen an den Komponenten, müssen nur die jeweiligen Komponenten angepasst werden, die Konfigurationen nehmen die Änderungen beim Deployment automatisch auf.
Hierbei handelt es sich sowohl um ein Architekturpattern, dass nicht zwangsläufig an eine konkrete Plattform gebunden ist. Andererseits bieten diverse Hersteller Produkte dieser Kategorie an, die allesamt die notwendigen Voraussetzungen mitbringen.
Die Frage nach dem Gesamtsieger ist relativ einfach zu erklären, da es keinen tatsächlichen Sieger gibt. Stattdessen bearbeiten alle Anwärter Teilgebiete des Ganzen, das sinnvolll zusammengefügt werden will.
Folgender Ansatz kann gewählt werden, um zu einer Lösung zu gelangen:
- Implementierung der Middleware auf Basis eines ESB. Hierbei wird einfache Erweiterbarkeit und schnelle Umkonfiguration von statischen Datenstrecken sichergestellt.
- Implementierung von Datenstrecken auf Basis von etablierten EAI Patterns. Hiermit wird erreicht, dass synchronisierte Datenströme, die evtl. unter Performanceaspekten zu realisieren sind, in einer einheitlichen und zentral administrierten Plattform aufgebaut werden. Es wird ein ESB verwendet, ohne auf irgendwelche Aspekte der EAI zu verzichten
- Unterstützung der Geschäftsprozesse durch eine SOA Architektur. Auf Basis eines ESB ist sichergestellt, die Vorteile der zentralen Komponenteregistrierung zu nutzen, die Flexibilität einer SOA aber weiterhin zur Verfügung zu haben. Durch die Registrierung weiterer Komponenten zur Laufzeit können dabei Funktionalitäten wie Geschäftsregeln (Business Rules), Orchestrierungen (BPEl, BPM, etc.) oder Aktivitätsüberwachung (BAM) unkompliziert nachgerüstet werden.
- Als generelles Schema für die Implementierung sollte dabei der EDA Gedanke aufgegriffen werden. Durch eine ereignisgesteuerte Abarbeitung werden Leerlaufzeiten vermieden und damit maximale Agilität sichergestellt. Optimierungen einer Stelle des Prozesses wirken sich damit unmittelbar auf die nachgelagerten Stellen aus.
Um alles nochmal kurz zusammen zu fassen: Es wurden die Probanden EAI, SOA, EDA, ESB betrachtet. Dabei haben sich alle als tauglich erwiesen, bieten aber nur in sich verzahnt maximale Flexibilität. Diese wird dann erreicht, wenn auf Basis eines ESB die statischen Datenstrecken über EAI Architekturen abgebildet werden. Die flexiblen Bestandteile werden nach SOA Patterns abgebildet. Die grundsätzliche Vorgehensweise richtet sich dabei nach EDA Prinzipien (also mit maximaler Flexibilität).
Über ein solches Vorgehensmodell können sowohl die Anforderungen von statischen, hochperformanten Datenströmen, als auch von flexiblen Prozessen, die an die Geschäftswelt angelehnt sind, realisiert werden. Durch die Verwendung eines ESB wird die zukünftige Erweiterbarkeit sichergestellt, ohne eine spätere Gefährdung der Stabilität in Kauf zu nehmen (da nur isolierte Komponenten betrachtet werden).
