SOA integriert Standard- und Individualsoftware

23.03.2011
Die Arbeitsgruppe SOA und Standardsoftware in der Anwendervereinigung SOA Innovation Lab arbeitet an Lösungen, wie sich in Großunternehmen IT-Silos aufbrechen und End-to-End-Prozesse unterstützen lassen.

Die Koexistenz von Standardsoftware und individuell entwickelten Anwendungen ist in den meisten Unternehmen an der Tagesordnung. Beide Welten sind auf vielfältige Weise miteinander verzahnt. Doch die Programme folgen unterschiedlichen Treibern, weshalb oft ein Spannungsfeld entsteht: Individualsoftware wird in der Regel über Modularisierung und Service-Orientierung hinsichtlich Agilität, Erweiterbarkeit und Integrierbarkeit optimiert. Standardsoftware im Enterprise-Umfeld ist dagegen meist auf niedrige Total Cost of Ownership, hohen Durchsatz und eine integrierte Prozessabdeckung ausgerichtet - Modularisierung und Service-Orientierung waren dabei in der Vergangenheit nicht die entscheidenden Erfolgsfaktoren. Das Verhältnis von Standard- zu Individualsoftware ist von Unternehmen zu Unternehmen unterschiedlich. In den marktdifferenzierenden Bereichen eines Unternehmens wird in der Regel Individualsoftware häufiger eingesetzt, weil dort mehr Wert auf Flexibilität und Agilität gelegt wird.

Produktneutrale Verzahnung

Weil Anwender in den letzten Jahren immer häufiger End-to-End-Prozesse wie die Auftragsabwicklung von der Bestellung des Kunden bis zur Verbuchung der bezahlten Rechnung ganzheitlich unterstützen wollen, reicht allerdings die bloße Koexistenz von Standard- und Individualsoftware nicht mehr aus. End-to-End-Prozesse erstrecken sich über verschiedene IT-Anwendungen hinweg, was ihre Verknüpfung erfordert, soll eine übergreifende IT-Unterstützung stattfinden. Eine "feste Verdrahtung" stellt angesichts der sich häufig ändernden Teilprozesse keine Option mehr dar. Wenn Anwendungen flexibel verzahnt werden sollen, sind Unternehmen gut beraten, sie im Rahmen einer Service-orientierten Architektur (SOA) zu integrieren.

Da die Anbieter von Standardsoftware für diese Art der Verzahnung keine produktneutralen Lösungen anbieten, entwickelt die Arbeitsgruppe "SOA und Standardsoftware" des SOA Innovation Lab einen Werkzeugkasten, der helfen soll, maßgeschneiderte Lösungen für dieses Problem zu finden. Dazu gehören eine Liste von bewährten Integrationsmustern und eine Landkarte der Integrationskomponenten. Nicht im Fokus der Arbeitsgruppe steht das Finden neuer Enterprise Patterns. Vielmehr geht es um das Identifizieren von Mustern oder Verfahrensweisen, die insbesondere für die Service-orientierte Integration von Standard- und Individualsoftware relevant sind und sich bereits bewährt haben.

Drei Arten von Integrationsmustern wurden dabei erkannt:

- Etablierte Integrationsmuster wie die Service-Fassade, die eingesetzt werden, um die Anwendungslandschaft servicefähig zu machen.

- Als Zweites benötigt man Lösungsmuster für den Einsatz von typischen Integrationskomponenten wie ein Service-Repository.

- Schließlich resultierte aus der Analyse von typischen Anwendungsfällen die Erkenntnis, dass man bei der Service-orientierten Integration von Standardprodukten auf Probleme stößt, zu deren Lösung komplexe Integrationsmuster notwendig sind, die gegebenenfalls den kombinierten Einsatz mehrerer einfacher Muster erfordern.

Unternehmen nutzen verschiedene Patterns, um die Anwendungslandschaft servicefähig zu machen. Ein geeignetes Pattern ist die Servicefassade zur Kapselung von heterogenen Anwendungen. Die Service-Fassade bietet eine einheitliche Schnittstelle zu einer Vielzahl von Schnittstellen zu Subsystemen und verringert dadurch nicht zuletzt die Komplexität der Systemlandschaft. Sie stellt innerhalb eines Prozesses den zentralen Einstiegspunkt dar, um etwa Kundeninformationen aus verschiedenen Subsystemen abzufragen oder auch zu verändern.

Prozesse voller Medienbrüche

Beispielsweise müssen bei einem von verschiedenen, nicht integrierten Anwendungen unterstützten Order-to-Cash-Prozess mehrere Beteiligte in unterschiedlichen Rollen bei jedem Prozessschritt verschiedene Anwendungen mit sehr unterschiedlichem Look and Feel bedienen. Doppeleingaben sind notwendig. Fehler und Terminüberschreitungen lassen sich nur durch eine aufwendige Koordination aller Prozessbeteiligten vermeiden.

Die Service-orientierte Integration mittels einer Service-Fassade führt demgegenüber zu deutlichen Verbesserungen - es entstehen wiederverwendbare, konfigurierbare und orchestrierbare Service-Operationen mit einem einheitlichen Look and Feel über alle Prozessschritte. Die Service-Fassade kapselt dafür technisch und fachlich sehr unterschiedliche Individual- und Standard-software-Komponenten. In Kombination mit einer Aufgabenliste und einer Prozesssteue-rung wird der Endnutzer von automatisierbaren Teilschritten, etwa der Benachrichtigung der im Ablauf folgenden Personen, entbunden. Insgesamt erhöht sich die Prozessqualität spürbar, Doppeleingaben entfallen, die Prozessüberwachung erfolgt automatisch. Nicht zuletzt lassen sich Mitarbeiter durch die Prozessharmonisierung flexibler einsetzen als zuvor.

Empfehlungen zur Service-Fassade

Die Service-Fassade ist kein neues Muster. Sie ist ein bewährtes Mittel, um Standard- und Individualsoftware Service-orientiert zu integrieren. Allerdings empfiehlt die Arbeitsgruppe, bei ihrem Einsatz vor allem auf folgende Dinge zu achten:

- Granularität: Anwender sollten sich sehr genau überlegen, wie die einzelnen Services geschnitten werden. Einerseits sollte der Funktionsumfang einer Service-Operation nicht zu klein sein, um eine bestimmte Funktionalität mit wenigen Operationen umsetzen zu können. Ist der Funktionsumfang andererseits zu groß, wird die Komplexität einer einzelnen Operation oft nicht mehr durchschaubar und benötigt zu viele Rechnerressourcen.

- Wiederverwendbarkeit: Anwender müssen darauf achten, dass die Services wiederverwendet und bei der Gestaltung von Prozessen flexibel eingesetzt werden können. Es lohnt sich, wenn erfahrene Mitarbeiter aus Fachbereich und IT zusammenarbeiten, um einen Service-Baukasten für das Unternehmen zu gestalten.

- Projektübergreifender Blick: Oft rechnet sich die Implementierung von wiederverwendbaren Services für ein einzelnes Projekt nicht. Hier ist der Blick aufs Ganze die Voraussetzung dafür, um die ersten beiden Anforderungen so erfüllen zu können, dass sich der Mehraufwand über verschiedene Projekte hinweg lohnt.

Reicht ein Service-Repository aus?

Eine sinnvolle Komponente für den Serviceorientierten Aufbau der Anwendungslandschaft ist ein Service-Repository. Dabei unterscheidet man gerne zwischen einem Repository für die Projektphasen bis hin zum Abschluss der Entwicklung und einem für die Laufzeit (inklusive Tests). Bei Letzterem handelt es sich dann häufig um eine Registry wie UDDI. Da viele Standard-Softwareprodukte ihre eigenen Service-Repositories mitbringen, haben Unternehmen oft verschiedene Repositories gleichzeitig im Einsatz. Meist sind diese jedoch nicht kompatibel. Im Grunde stellt jedes für sich genommen einen Alleinvertretungsanspruch, so dass es bislang keine Möglichkeit gibt, sie zumindest logisch zu integrieren.

Für Unternehmen stellen sich damit in der Regel folgende entscheidende Fragen:

- Was ist der beste Weg, alle Service-Repositories in einer logischen Sicht zu integrieren? Rechnet sich der Aufwand überhaupt?

- Lassen sich die unterschiedlichen Bedürfnisse zum Beispiel in puncto Entwicklungs- und Laufzeit mit einem Repository erfüllen? Falls ja, ist das sinnvoll?

In vielen Unternehmen sind diese Fragen noch ungeklärt, eine zentrale Sicht auf alle verfügbaren Services fehlt. Aufbauend auf den Erfahrungen der Mitgliedsunternehmen möchte die Arbeitsgruppe des SOA Innovation Lab ein Integrationsmuster entwickeln, mit dem sich diese Fragen beantworten lassen.

Komplexe Integrationsmuster

Wie eingangs erwähnt, ergeben sich bei der Service-orientierten Integration von Standardprodukten oft Probleme, die sich nur mit komplexeren Integrationsmustern lösen lassen. Dies erfordert gegebenenfalls den kombinierten Einsatz mehrerer einfacher Muster wie Service-Fassaden, Portale, UI-Integration oder Enterprise-Service-Bus. So stellte zum Beispiel ein Unternehmen, als es seinen Auftragsabwicklungsprozess analysierte, fest, dass es für diese Abläufe Kundeninformationen in vielen Prozessschritten und damit in unterschiedlichsten Anwendungen benötigt.

Die einzelnen Anwendungen bieten dabei eine unterschiedliche Sicht auf den Kunden, was eine Synchronisation der Daten erschwert. Ferner müssen die Kundendaten in unterschiedlichen Systemen gepflegt werden.

Erschwerend beanspruchen manche Produkte wie SAP GP/CRM, Leitanwendungen zu sein, obwohl das Unternehmen die Stammdaten in einer anderen Anwendung pflegen möchte. Eine Synchronisation der Daten, bei verschiedenen Produkten eines Herstellers oft noch möglich, ist unter diesen Umständen extrem aufwendig oder kann sogar scheitern, wenn die beteiligten Anwendungen zu heterogen sind. Die Folge: Eine zentrale Stammdatensicht ist nicht verfügbar. Auch der Einsatz eines zentralen technischen Stammdatenprodukts, wie es viele Hersteller von MDM-Produkten (Master-Data-Management) anpreisen, bietet hier keine einfache Lösung.

Erste Diskussionen der Arbeitsgruppe laufen darauf hinaus, verschiedene einfache Integrationsmuster zu empfehlen. Allerdings arbeitet die Gruppe - genauso wie bei der Frage nach einem zentralen Respository - noch an klaren Empfehlungen. In diesem Jahr wird man deshalb gemeinsam mit der Hochschule Reutlingen ein Testlabor einrichten und prototypisch einen Order-to-Cash-Prozess erstellen, an dem komplexe Integrationsmuster evaluiert werden können.

Fragenkatalog für die Hersteller

Derzeit wendet die Arbeitsgruppe die beschriebenen Integrationsmuster und die Landkarte der Integrationskomponenten auf konkrete Probleme rund um die Einbindung von Standardsoftware in End-to-End-Prozesse an. Master-Data-Management und Business Activity Monitoring gelten dabei als vorrangig zu behandelnde Probleme. Aufbauend auf diesen Anwendungsfällen sollen konkrete Fragen und Anforderungen an die Hersteller von Standardsoftware und Integrationslösungen abgeleitet und Lösungsempfehlungen in einer Testumgebung erprobt werden. (ue)

Das SOA Innovation Lab

Das SOA Innovation Lab e. V. bietet Unternehmen ein Praxisforum, in dem anwendungsbezogenes Wissen zu SOA und Enterprise-Architecture-Management ausgetauscht werden kann. Im Sinne einer "Knowledge Community" stehen dabei die Interessen und Fragen der Unternehmen im Vordergrund. Unabhängiges Wissen, Erfahrungen aus konkreten Projekten und erprobte Vorgehensweisen werden aus ers-ter Hand zugänglich gemacht.

Heute zählt das SOA Innovation Lab folgende Unternehmen zu seinen Mitgliedern: BSH Bosch und Siemens Hausgeräte, Bundesministerium des Inneren, Commerzbank, Daimler, Deutsche Bahn, Deutsche Lufthansa, Deutsche Post, Deutsche Telekom, Fiducia, Itergo, Volkswagen, Wacker Chemie, ZF Friedrichshafen, Zürich Versicherungs-Gesellschaft.

Das SOA Innovation Lab ist offen für die Beteiligung weiterer Anwenderunternehmen. Informationen gibt es unter www.soa-lab.de.

Landkarte der Integrationskomponenten

Die Landkarte der Integrationskomponenten wurde von den Mitgliedern der Arbeitsgruppe als Referenzarchitektur für die Integration von Geschäftsanwendungen entwickelt. Sie enthält und gruppiert alle technischen Integrationsfunktionen, die man unter anderem zur Umsetzung einer SOA benötigt.

Ganzheitliche Betrachtung

Integrationskomponenten werden als etablierte Bausteine einer Integrationslandschaft verstanden. Integrationsmuster für Geschäftsanwendungen werden mit diesen Komponenten zu einer Gesamtintegrationslösung kombiniert. Zur Strukturierung dieser Bausteine haben sich die Integrationsebenen Präsentation (Frontend), Prozess, Logik und Daten herauskristallisiert. Neben Komponenten, die über Integrationsebenen hinweg relevant sind, wurden Komponenten für Entwicklung und Laufzeit identifiziert.

Die Anwendung der Landkarte unterstützt eine ganzheitliche Betrachtung der Integrationsproblematik. Neben der Logikintegration, die meist im Vordergrund einer SOA steht, ist die Datenintegration (Master-Data- Management) eine weitere Voraussetzung für jegliche Logik- und Prozessintegration. Prozess- und Präsentationsintegration liefern höherwertige Integrationslösungen. Ferner lassen sich mit der Landkarte Herstellerlösungen im Bereich Integration und Middleware sehr gut analysieren. Sie hilft zu erkennen, welche Produkte welche Integrationskomponenten beinhalten und welche Integrationsebenen sie mit welchen Mitteln bedienen. Ein willkommener Nebeneffekt ist die Möglichkeit, mit der Landkarte Überlappungen im Lösungsportfolio des Herstellers zu identifizieren.