200701r Information Builders Integration SOA

»manage it« als

E-Paper 5-6 2011
E-Paper 3-4 2011
E-Paper 1-2 2011
E-Paper 11-12 2010
E-Paper 9-10 2010
E-Paper 7-8 2010
E-Paper 5-6 2010

Serviceorientierte Architektur (SOA) und die Anwendungsintegration

Fünf goldene Integrationsregeln

Flexible Geschäftsprozesse setzen voraus, dass sämtliche Anwendungen, die zu ihrer Unterstützung implementiert wurden, ebenso flexibel gestaltet sind. Eine anpassungsfähige IT-Umgebung sorgt für ein optimales Zusammenspiel von Businessprozessen und prozessrelevanten Applikationen.

ergers & Acquisitions, Outsourcing, zunehmende gesetzliche Regelungen, wachsender Wettbewerb und steigende Anforderungen an die Profitabilität – die Bedingungen für Unternehmen werden zunehmend komplexer. Ohne flexible Geschäftsprozesse ist es für die meisten Organisationen nahezu unmöglich, zeitnah und vor allem erfolgreich auf diese Herausforderungen zu reagieren. Um derartige Prozesse jedoch nicht nur auf dem Papier, sondern auch in der Praxis effizient umsetzen zu können, müssen IT und Business optimal aufeinander abgestimmt sein.

Dabei stellt sich die Frage, wie flexible und effiziente IT-Strukturen in die Praxis umgesetzt werden können. Sinnvoll sind vor allem Methoden, auf deren Basis Unternehmen in einzelnen, aufeinander aufbauenden Schritten eine Brücke zwischen Geschäftsprozessen und IT schlagen können.

Um unternehmerische IT-Strukturen schrittweise flexibler zu gestalten, empfehlen sich die fünf goldenen Integrationsregeln. Mit ihnen können Unternehmen eine serviceorientierte Architektur (SOA) realisieren, die den Anforderungen flexibler IT- und Geschäftsprozesse gerecht wird. Folgender Leitfaden geht zunächst auf die Grundlagen der Integrationsarchitektur ein und schließt mit einem umfassenden Empfehlungskatalog für Integrationsprojekte.

Integrationsarchitektur

Der ideale Zustand einer IT-Landschaft ist dann erreicht, wenn eine kleine Änderung im betrieblichen Ablauf lediglich kleine Anpassungen der IT-Systeme nach sich zieht. Die Integration muss dem Kunden die Möglichkeit eröffnen, jeden Service über jeden Kanal bereitzustellen. Je mehr Schnittstellen zu einzelnen Diensten aufgebaut werden, desto wichtiger ist es jedoch auch, Kanäle und Services effizient miteinander zu verbinden. Dieses Prinzip bezeichnet man als lose Kopplung. Es ist ausschlaggebend für die Skalierbarkeit der Integration.

Die grundlegende Herausforderung an die Integration besteht darin, Nachrichten von einem System in ein anderes zu übertragen. Denn ein reibungsloser Message-Flow ist eine wichtige Voraussetzung für die optimale Zusammenarbeit aller Anwendungen und Services. Dabei müssen einzelne Messages sowohl syntaktisch – also strukturell – als auch semantische – also inhaltlich und damit aufgabenbezogen – an die Ausgangs- und Zielanwendungen angepasst werden. Die Verwendung von Messaging-Typen wie beispielsweise des Transaktionsstandards ACORD (Association for Cooperative Operations Research and Development) oder des FpML-Formats (Financial products Markup Language) sorgt dafür, dass Nachrichten in eine allgemeingültige, auch als kanonisch bezeichnete Form umgewandelt werden. Eine derartige Message-Modifizierung legt den Grundstein für flexible Flow-Prozesse, die auch dann wiederverwendbar bleiben, wenn für einen bestimmten Nachrichtentyp neue Quell- und Zielsysteme hinzukommen. Die Übersetzung und das Routing von Nachrichten an den Ausgangs- oder Zielanwendungen folgt festgelegten Regeln, die von entsprechenden Adaptern verwaltet und umgesetzt werden.

Ein weiterer wichtiger Aspekt ist die Serviceorientierung von Architekturen. Sie ist unumstritten notwendig, aber nicht – wie fälschlicherweise oft angenommen –hinreichend. Soll die Integration dazu dienen, Dienste über bestimmte Kommunikationskanäle bereitzustellen, müssen sowohl die Dienste als auch die Kanäle eingerichtet werden. In vielen Abhandlungen über Integration wird dieser Gesichtspunkt jedoch völlig außer Acht gelassen.

Fünf goldene Regeln der Anwendungsintegration

Regel 1. Neue Integrationsanforderungen dürfen nicht mit neuen Anwendungen gleichgesetzt werden

Viele Architekturen werden im Zentrum überladen. Das Phänomen dieser zentralen Überfrachtung taucht im Zusammenhang komplexer zusammengesetzter Anwendungen immer wieder auf. Zahlreiche Unternehmen gehen davon aus, dass ihre vorhandenen Applikationen keine Geschäftsprozesse liefern können, sondern immer auf solchen aufsetzen müssen. Doch diese Überlegung kann durchaus in Zweifel gezogen werden. Bei der engen Verzahnung von Integrations- und Applikationsstrukturen gerät nämlich eine Tatsache häufig in Vergessenheit: Die Anwendungen von heute sind die Legacy-Systeme von morgen. Deshalb ist es für die Integration unbedingt erforderlich, das Zentrum der IT-Landschaft auszudünnen und die Integrationsarchitektur sowie ihre Komponenten von der Anwendungsarchitektur zu trennen. Alle Services, sowohl vorhandene als auch neue Dienste, sollten auf derselben Ebene angeordnet werden – und zwar dort, wo sich die Legacy.Services befinden. Der ideale Integrationsansatz lautet auch hier lose Kopplung.

Regel 2: Die Verantwortung für den Service liegt bei der jeweiligen Anwendung

Ebenfalls bedeutend für das reibungslose Funktionieren einer losen Kopplung ist die richtige Rollenverteilung. Die Verantwortung für Syntax-Adapter und ihr strukturelles Regelsystem liegt bei den Anwendungen, die sie anbinden. Dagegen orientieren sich die semantischen Adapter an den organisatorischen Strukturen auf einer höheren Ebene. Damit wird deutlich, dass es bei der Integration weniger um ein technisches als vielmehr um ein organisatorisches Konzept geht. Aus diesem Grund spielt die Serviceorientierung eine wichtige Rolle. Nur mit ihr ist es möglich, die Verantwortung richtig zu verteilen und mehr Flexibilität zu erreichen. Außerdem fördert dieser Ansatz ein besseres Verständnis für die geschäftlichen Anforderungen – ohne ausufernde Analysen vorauszusetzen.

Regel 3: Die Überlappungen der Datenelemente sind relevant

Wenn es um Design und Implementierung einer Architektur geht, kommt es in vielen Unternehmen zu einer Art Lähmung. Dieses Phänomen ist insbesondere bei Data-Warehouse-Architekturen zu beobachten. Es ist weder möglich noch ratsam, alle Integrationsanforderungen im Vorfeld zu kennen und zu definieren. Obwohl die allgemeingültigen kanonischen Nachrichten mit wiederverwendbaren Services gekoppelt sind, sind sie zunächst in der Architektur verborgen und können nur sukzessive identifiziert werden. Deshalb sind Bottom-up-Analysen, die die Überlappung aller relevanten Datenelemente untersuchen, deutlich effizienter als eine aufwendige Top-down-Analyse, die in der Regel hohe Kosten für die Dokumentation tausender Dokumente erzeugt. Mit dem Botton-up-Prinzip hingegen lassen sich Schnittmengen mit deutlich weniger Aufwand exakt identifizieren und steuern.

Regel 4: Steuern Sie immer mit drei Flow- und zwei Transform-Prozessen

Um grobe Granularität, lose Kopplung und die Wiederverwendbarkeit von Services und Diensten zu erreichen, empfehlen sich drei Vorgänge zur Steuerung des Datenstroms (Flow) und zwei Prozesse zur Datenumwandlung (Transform). Die Kombination der Quell- und Zieladapter mit einer Flow-Regel ergeben zusammengenommen die angemessene Granularität. In der nächsten Schicht wird nun die lose Kopplung implementiert. Diese Schicht ist erstmalig der Domain zugeordnet. Hier finden die beiden semantischen Transform-Prozesse statt – einmal in eine kanonische Form und von dort aus jeweils in das Zielsystem. Dies ist das Prinzip der losen Kopplung: Jede Anwendungsänderung wird in diesen Umwandlungsprozessen aufgefangen. Der zentrale Flow-Prozess wird im kanonischen Namensraum, dem Namespace, erstellt. Er sorgt für das richtige Routing und die Datenanreicherung, bevor die Message an den Zieladapter weitergereicht wird.

Regel 5: Bei der Übertragung immer mit drei Transaktionsstufen arbeiten

Um eine Nachricht an eine andere Anwendung zu senden und dann auf die Rückmeldung hin weitere Aktivitäten auszulösen, sind drei Transaktionen erforderlich. In der ersten Transaktionsstufe wird die Nachricht gelesen, dann aus der einen Queue gelöscht und in eine neue Warteschlange geschrieben. Die zweite Stufe findet nun in der anderen Anwendung statt, von der die übermittelte Nachricht gelesen wird. Danach wird eine neue Nachricht geschrieben, die sich von der ersten unterscheidet. Im dritten Schritt schließlich liest die erste Applikation die Nachricht aus der zweiten Anwendung und gleicht sie mit ihrer Datenbank ab. Damit ist der Übertragungsvorgang abgeschlossen.

Empfehlungen für die Integration

Aus den angeführten Regeln lassen sich folgende Empfehlungen ableiten:

• Workflows innerhalb der Geschäftsprozesse sollten wie Anwendungen behandelt werden. Sie dienen nicht als Instrument für die Integration.

Werden bereits Dienste über Kanäle und Hubs bereitgestellt, ist es sinnvoll, bei der Entwicklung neuer Anwendungen Teile dieser Dienste mitzunutzen. Für diese Anwendungen ist der Workflow-Ansatz ein geeignetes Konzept. Ebenso wie die bestehenden Anwendungen miteinander gekoppelt sind, werden auch diese neuen Anwendungen über lose Verbindungen an die bereits vorhandenen Applikationen gekoppelt.

• Die Verantwortung für die Adapter liegt bei den Anwendungen, die sie anbinden.

Auch wenn einige Adapter zunächst zentral erstellt werden, muss jedes Syntax-Element an die Anwendung, die der jeweilige Adapter anbindet, übergeben und die entsprechende Verantwortung zugewiesen werden. Damit soll sichergestellt werden, dass der Adapter alle Änderungen in der Anwendung aufgreift und umsetzt.

• Die Integration sollte immer über eine lose Kopplung realisiert werden.

Um Skalierbarkeit zu gewährleisten, sollte die Integration von Anwendungen über lose gekoppelte Verbindungen realisiert werden. Bei enger Kopplung zwischen Services und Kanälen steigen die Integrationskosten sehr schnell ins Unermessliche.

• Bei internen Nachrichten sollten SOAP Header-Standards verwendet werden.

Bis es eine endgültige Einigung auf einen Header-Standard geben wird, empfiehlt sich für den externen Nachrichtenaustausch der Einsatz von ebXML SOAP Header (electronic business XML) und für die interne Übermittlung WSRM Header (Web Services Reliable Messaging).

• Externe Standards bieten sich für eine Type-Library an, nicht aber als interner Messaging-Standard.

Diese Empfehlung entspricht unter Umständen nicht dem erklärten Ansatz vieler Unternehmen. Dies liegt darin begründet, dass ein vorgegebenes Formatpaket für den internen Nachrichtenaustausch zu starr ist. Auf der einen Seite kann es zu einem so genannten ’Overkill’ kommen, wenn der externe Standard mehr Vorgänge beschreibt, als in dem Unternehmen stattfinden. Im anderen Fall werden Vorgänge, die tatsächlich vorhanden sind, nicht abgedeckt.

• Für die externe Kommunikation empfiehlt sich der Einsatz eines Übertragungsstandards, intern sollte dieser nicht verwendet werden.

Wird die B2B-Kommunikation nicht über leistungsfähige (high-level) Hubs gesteuert, empfiehlt es sich Standards zu nutzen, wie zum Beispiel für den Nachrichtenaustausch zwischen verschiedenen Unternehmenseinheiten oder zwischen dem Unternehmen und seinen Kunden, Lieferanten und Partnern.

• In jeder Integration sollten immer drei Flow-Prozesse stattfinden: Ein Prozess für das Ausgangssystem, einer für die Zielanwendung und einer für die zwischengeschaltete Nachricht.

Erst eine solche Struktur ermöglicht die Verbindung über eine lose Kopplung der Systeme und sorgt für Skalierbarkeit. Die lose Kopplung wird dadurch erreicht, dass der anwendungsunabhängige Teil von Routing, Semantik und Regelwerk außerhalb der Anwendung gesteuert wird. Im Unterschied dazu laufen die Anreicherung von Daten und die Datentypen als anwendungsspezifische Prozesse innerhalb der Anwendung ab.

• Empfehlenswert ist der Einsatz von Integration-Flows für die Adapter ebenso wie für die Hub-Verbindung (Zwischenschaltung).

Beide Systeme sind aufeinander abgestimmt und sorgen somit für Konsistenz.

• Für das Deployment sollten multilaterale, bilaterale und monolithische Verteilungsstrukturen kombiniert werden.

So wird eine höhere Kosteneffizienz bei Integrationsprojekten erreicht.

• Dort, wo die Kanäle implementiert werden, sollte jede Domain eine einheitliche Eingangsoberfläche (Face) erhalten.

Jede Domain kann dadurch jeden Service über jeden Kanal flexibel zur Verfügung stellen.

Dieter Wolf

___________________________________________________________

Dieter Wolf ist Regional Director Central Region bei Information Builders

Folgen Sie »manage it«

auf Google+