SOA im Winter – Teil 2 von 2

Dies ist die Fortsetzung von SOA im Winter – Teil 1 von 2. Die SOIA-Schicht ist diejenige welche uns die Kopfzerbrechen bereitet. Denn bislang existieren noch keine ausreichenden Antworten auf alle Fragen, die uns bei ihrer Umsetzung das Leben schwer machen. Aber gleichzeitig ist die SOIA eben auch das Thema mit den großen Potentialen: Wer die Herausforderungen bewältigt, gewinnt eine Agilität, die seine Wettbewerber nicht besitzen. Es lohnt sich also trotz aller Unkenrufe, das SOA-Thema nüchtern und vorurteilsfrei zu betrachten!

3.3.2.3    SOIA in der Praxis
Die Integrations- oder Agilitätsebene umreißt das Themengebiet, das in der öffentlichen Diskussion auch gern als Zusammenspiel von BPM und SOA bezeichnet wird. Es geht um die an der Unternehmensorganisation ausgerichtete Definition und Wartung von Services, sowie um ihre prozessorientierte Nutzung. Leider befinden sich die Kenntnisse und Erfahrungen im SOIA-Bereich heute noch weit unter dem Niveau der SOSA-Ebene. Das bedeutet, es existieren noch viele offene Fragen, wie eine SOIA richtig umgesetzt werden kann – und teilweise sind noch nicht einmal die richtigen Fragen gestellt worden.

Als relativ sicher gilt die grundsätzliche Feststellung, dass sich die Prozessagilität aus der Fähigkeit ableitet, definierte Services relativ einfach neu kombinieren zu können, und dass es deshalb eine Möglichkeit geben muss, die Reihenfolge der Nutzung vieler Services direkt an der Prozesslogik auszurichten, und diese Reihenfolge über einen Mechanismus verändern zu können, der keine direkte Programmierung erfordert. Diese Überlegung führt zunächst zum Ansatz der Service Orchestrierung, bei dem eine Orchestration Engine die Rolle eines Dirigenten übernimmt, und wie bei einem Orchester ausgehend vom Prozessmodell mal den einem, mal den anderen Service zur Ausführung einer Aufgabe anweist. Solche Aufgaben können sich auf einfache Datenoperationen beziehen, wie das Auslesen von Kundenstammdaten aus einem CRM-System, oder auf komplexe Geschäftslogik, wie die Berechnung eines Beleihungswertes im Rahmen einer Baufinanzierung.

Sofort drängt sich der Vergleich zum Human Workflow Management  auf: Dort übernimmt die Workflow Engine diese Rolle, und die am Prozess beteiligten Mitarbeiter und Partner stellen mit ihrer Arbeitskraft und Kompetenz die „Services“ bereit, die mittels Aufgabenzuweisung aufgerufen werden.
Somit wird auch ersichtlich, warum ein ganzheitliches Business Process Management die Methoden „Human Workflow Management“  und „Service Orchestration“ gleichermaßen abdecken muss.

Eine für die praktische Serviceorchestrierung sehr wichtige Differenzierung ist die Unterscheidung von synchronen und asynchronen Service Aufrufen („Service Calls“; Bild 3.18): Bei einem synchronen Service Call geht der Consumer davon aus, dass der Provider kurzfristig die Aufgabe abarbeiten und das Ergebnis zurückgeben wird. Dementsprechend wartet der Consumer auf diese Antwort und führt keine weiteren Prozess-Schritte aus. Dieses Szenario macht Sinn, wenn der Provider nicht überlastet ist oder die auszuführende Aufgabe nicht zu viel Zeit in Anspruch nimmt, wie zum Beispiel die Ausführung einer überschaubaren Berechnung. Mitunter kann der Consumer aber nicht wissen, wie lange die Antwort des Providers auf sich warten lassen wird. Möglicherweise dauert es Stunden, Tage oder gar Monate, weil die Realisierung des Services selbst ein komplexer Prozess ist. In solchen Fällen wird der Service asynchron aufgerufen, d.h. der Provider schickt nach erfolgtem Service Call lediglich eine Empfangsbestätigung und beendet dann vorerst die Kommunikation. Der Consumer führt seinen Prozess weiterhin aus, sofern er hierzu nicht auf die Antwort des Providers angewiesen ist, und irgendwann, zu einem späteren Zeitpunkt, meldet sich der Provider mit dem Ergebnis der erledigten Aufgabe. Diese Meldung findet dann als Aufruf des Consumer durch den Provider statt, weshalb dieser Vorgang auch „Callback“ genannt wird.

Um diese abstrakte Darstellung besser greifbar zu machen, kann man sich Beispiele aus der physischen Welt vor Augen führen: Im Rahmen des jährliches Prozesses der Einkommenssteuererklärung überkommt den Bürger, während er das Formular ausfüllt, eine Idee zur Steueroptimierung. Weil er nicht weiß, ob diese auch legal ist, nimmt er die Beratungsleistung seines Steuerberaters in Anspruch, und ruft diesen kurzerhand an. Technisch gesehen führt er via Telefon einen Service Call durch, wobei er in diesem Call seine Frage als Parameter übergibt, und nun darauf wartet, dass der Steuerberater die Aufgabe des darüber Nachdenkens ausführt, und ihm in seiner Antwort seine Einschätzung der rechtlichen Lage mitteilt. Solange der Bürger am Telefon sitzt und auf die Antwort wartet, unterbricht er das Ausfüllen des Formulars, und sein Prozess ist in einen Wartezustand eingetreten. Es handelt sich also um einen synchronen Service Call.

Hätte der Bürger hingegen damit gerechnet, dass der Steuerberater gerade nicht verfügbar ist oder seine Fragestellung so komplex ist, dass diese eine ausführliche Prüfung erfordert, hätte er seinen Service Call möglicherweise via Email durchgeführt. Dann hätte er, ohne auf die Antwort zu warten, das Ausfüllen seines Formulars fortgesetzt. Irgendwann wäre er an einem Punkt angelangt, wo er die Antwort des Steuerberaters gebraucht hätte, um das Formular zu finalisieren, und wäre in einen Wartezustand eingetreten (zumindest, was diesen Prozess angeht). Technisch gesehen hätte er auf den Callback des Services gewartet, den er zuvor via Email asynchron aufgerufen hätte (Bild 3.19).

Die Nutzung asynchroner Service Calls ist mit einer besonderen Herausforderung verbunden, die sich ebenfalls mit dem skizzierten Beispiel erklären lässt: Die Antwort des Steuerberaters erreicht den Bürger vermutlich ebenfalls per Email. Dieser registriert zunächst den Erhalt und erkennt anhand des Absenders, dass es sich um eine Email seines Steuerberaters handelt, und (für gewöhnlich) anhand des Betreffs, dass sich diese nicht auf die noch offene letzte Honorarabrechnung bezieht, sondern eine Antwort auf die zuvor gestellte Frage ist. Er hat also eine gedankliche Zuordnung der Nachricht zu seinem Prozess vorgenommen. Dieser schlüsselbasierte Zuordnungsvorgang wird Corellation Handling genannt und ist eine unabdingbare, aber auch schwierige Anforderung im Rahmen der Service Orchestrierung.
Einige Service Orchestration Prozesse funktionieren aus der Business-Perspektive nur nach dem Alles-oder-nichts-Prinzip: Es müssen alle Service-Aufrufe erfolgreich durchgeführt werden. Sollte auch nur ein Service-Aufruf fehlschlagen, müssen alle bereits erfolgten Aufrufe rückgängig gemacht werden. Dieses Prinzip der Atomarität dient der Transaktionssicherheit und gilt beispielsweise im Rahmen von Überweisungen:  Wenn im ersten Service Call der Betrag vom Konto A abgebucht wurde, jedoch der zweite Service Call zur Buchung auf Konto B fehlschlägt (zum Beispiel, weil es einen technischen Defekt im Netzwerk gibt), muss der Betrag auf das Konto A zurückgebucht werden, damit das Geld nicht „verloren“ geht. In derart kritischen Szenarien muss für jeden Service, der eine Aktion ausführt, vom Service Provider ein zweiter Service bereitgestellt werden, der genau diese Aktion wieder rückgängig machen kann und durch die Orchestration Engine im Fehlerfall aufgerufen werden kann. Der Umgang mit solchen Szenarien wird für gewöhnlich Compensation Handling genannt.

Die bis hierher vorgestellten Konzepte der

• Prozessorientierte Servicenutzung über Service Orchestration
• Synchrone versus asynchrone Service Calls
• Correlation Handling zur Zuordnung von Callbacks
• Compensation Handling zur Realisierung atomarer Service Orchestrations

sind bei weitem nicht alle, aber die in der Praxis besonders häufigen Aspekte, die es bei der technischen Umsetzung einer SOIA zu beachten gilt. Sie werden in vielen BPM-Suites entweder proprietär oder durch Implementierung von Standards wie z.B. BPMN zur optischen Gestaltung oder BPEL zur technischen Realisierung abgebildet.

Während diese Herausforderungen, wenngleich anspruchsvoll, so doch intellektuell bereits weit durchdrungen sind, existieren weitere, vergleichsweise mangelhaft geklärte Probleme auf der SOIA Ebene. Ein besonders schwieriges Problem bezieht sich auf die sinnvolle fachliche Abgrenzung von Services. Diese Abgrenzung mündet in eine Service Definition, die wiederum Grundlage der Service Implementierung ist. Dieser Prozess ist aufwendig, führt aber, sofern erfolgreich durchlaufen, erst wirklich zum gewünschten Effekt der flexiblen Nutzung von Services, um sie in verschiedenen Prozessen einsetzen zu können bzw. innerhalb eines Prozesses zu verschiedenen Zeitpunkten aufrufen zu können, und somit Prozessänderungen rasch umzusetzen – also genau der Zielsetzung der Integrationsebene, die dynamische Organisationsebene mit der starren Software-Ebene flexibel zu verbinden. Wenn diese organisatorische Ausrichtung fehlschlägt, führt dies im Ergebnis zu starren Services, die nur eine ganz bestimmte fachliche Anforderung abbilden, und nur zu einem ganz bestimmten Zeitpunkt innerhalb eines Prozesses aufgerufen werden können. In der Konsequenz könnten die implementierten Services zwar dank Orchestration Engine relativ schnell neu kombiniert werden, sind aber selbst gar nicht fähig zu unterschiedlichen Kombinationen, weil der Grad der „losen Kopplung“ nicht ausreicht und logische Abhängigkeiten zwischen den Services bestehen, die eine bestimmte Reihenfolge der Ausführung erzwingen, obwohl diese Reihenfolge nicht zwangsläufig der Prozesslogik geschuldet ist.

Für den Prozess der SOIA-gerechten Abgrenzung, Definition und Implementierung von Services gibt es (noch) kein Patentrezept, sondern nur die häufig leidvollen Erfahrungen derjenigen, die ihn bereits durchlaufen haben. Nicht wenige gehen tatsächlich den Weg über die Prozesse: Sie sammeln sämtliche Abläufe, die durch die SOIA zukünftig unterstützt werden sollen, und identifizieren die Gemeinsamkeiten und Unterschiede der jeweils benötigten IT-Unterstützung einzelner Schritte und Aktivitäten. Aus dieser Sammlung entsteht ein Domänenmodell, in dem sich zunächst Gruppen von Services zusammenfassen lassen. Innerhalb der Domänen werden dann einzelne Services voneinander abgegrenzt, wobei es durchaus zu Überlappungen in der bereitgestellten Leistung kommen darf. Die Implementierung dieser sehr grobgranularen Services muss dann auch nicht direkt in Code erfolgen, sondern kann selbst wieder eine Orchestrierung eher feingranularer Services sein – wobei man sehr darauf achten muss, die unterschiedlichen Prozessebenen konsistent aufeinander abzustimmen. So kann es vorkommen, dass ein feingranularer Service in unterschiedlichen grobgranularen Services Verwendung findet.

Sind Services implementiert und publiziert, können sie durch die „Allgemeinheit“ innerhalb, mitunter auch außerhalb des Unternehmens genutzt werden. Aufgrund des dezentralen Charakters einer SOA muss auch nach der Implementierung der Betrieb der Services gewissenhaft betreut werden, weshalb man hier auch vom Service LifeCycle Management spricht. Schließlich darf es nicht passieren, dass ein Service zur Angebotskalkulation, der im Unternehmensbereich A entwickelt und betrieben wird, eines Tages abgeschaltet wird, ohne alle anderen Unternehmensbereiche, die den Service in ihren Prozessen nutzen, rechtzeitig darüber zu informieren. Eine weitere unerwünschte Entwicklung wäre die Einrichtung einer eigenen Angebotskalkulation durch Unternehmensbereich B, weil sie den Service von Bereich A für mangelhaft hält, sodass innerhalb des Unternehmens zwei verschiedene Services für dieselbe fachliche Anforderung existieren. Die Sicherstellung der Serviceverfügbarkeit, die Vermeidung eines Wildwuchses und weitere Aspekte des Service LifeCycle Managements werden im Rahmen einer SOA-Governance organisiert. Doch auch für den Aufbau einer solchen Governance existieren bislang keine standardisierten, wissenschaftlich fundierten und praxiserprobten Verfahren, sondern lediglich die ersten punktuellen Erfahrungen von Unternehmen, die eine SOA größeren Umfangs eingeführt haben.

Abschließend muss konstatiert werden, dass sich SOIA momentan immer noch in einem Prozess der Entdeckung befindet. Zwar haben viele, vor allem größere Unternehmen bereits umfangreiche Projekte zur Steigerung ihrer Agilität durch die Einrichtung einer solchen Ebene angestoßen, und einige haben auch schon erste Erfolge melden können. Aber in der Breite existieren noch nicht ausreichend viele analysierbaren Ergebnisse, um eindeutige Muster für alle auftretenden Herausforderungen ableiten zu können. Wer sich mit der Einrichtung einer SOIA beschäftigt, muss deshalb  Pioniergeist und einen längeren Atem mitbringen, denn es passiert noch vieles nach dem Prinzip „Versuch-und-Irrtum“. Es wird vermutlich noch einige Jahre dauern, bis sich der Erfahrungshorizont im SOIA-Bereich auf dem heutigen Niveau der SOSA-Ebene befindet – diese zunächst negative Feststellung bedeutet natürlich gleichzeitig auch eine Chance für Unternehmen, die als „First-Mover“ eine Agilitätsebene in ihrer Prozesslandschaft entwickeln und somit einen Vorsprung gegenüber ihren Wettbewerbern realisieren wollen.

Die Idee der SOIA-Ebene steht auch in einem direkten Zusammenhang mit der allgemeinen Zusammenführung der Organisations- und IT-Perspektive von Business Process Management. Weitere Herausforderungen und Lösungsansätze in diesem Themenfeld werden in Kapitel 4 beschrieben.

3.3.2.4    SOPA in der Praxis
Zum Thema Service-Orientierung auf Prozessebene gibt es über die allgemeine Zielsetzung hinaus in der Praxis momentan noch nicht viel zu sagen: Die Klärung der wesentlichen Fragen der SOIA-Ebene ist Voraussetzung, um sich überhaupt seriös mit Vorgehensweisen zur Einrichtung einer serviceorientierten Organisation befassen zu können. Deshalb ist es müßig, sich heute bereits die Frage zu stellen, wie man die eigenen Geschäftsprozesse organisatorisch „serviceorientiert“ gestalten kann. Diskussionen und Publikationen zu diesem Thema rutschen derzeit schnell in eher schwammige Diskurse über Kundenorientierung und Dienstleistungsmentalität ab, und münden gern in Forderungen wie „Prozesse müssen als Service gegenüber dem Kunden gestaltet werden, den dieser muss im Mittelpunkt der Betrachtung stehen“. Diese Ambition ist zwar löblich, aber gleichzeitig eine absolute Binsenweisheit und hat mit dem eigentlichen SOA-Paradigma nichts mehr zu tun.