© Ekaphon maneechot/Shutterstock.com
Probleme und Lösungen bei einer SOA

Technik ist einfach, Strukturen schwierig


Eine SOA einzuführen, ist nicht nur eine technische Herausforderung. Auch auf der Ebene der Zusammenarbeit von Mitarbeitern und Prozessen muss sich einiges ändern. Denn wie Conway’s Law schon sagt: Kommunikationsbeziehungen bestimmen Strukturen. Das reale Beispiel einer SOAfizierung einer Versicherung zeigt Herausforderungen und Lösungsansätze auf.

Die SV Informatik ist ein Systemhaus für öffentliche Versicherungen. Sie stellt die Weiterentwicklung sowie den sicheren und performanten Betrieb für die IT-Landschaften ihrer Kunden sicher – der SV Sparkassenversicherung, der Hamburger Feuerkasse und der Sparkassen-Versicherung Sachsen. Die heutige SV Informatik ist aus einer Fusion von öffentlichen Versicherern entstanden. Die einzelnen Ursprungshäuser brachten alle ihre eigene Anwendungslandschaft in die neue Gesellschaft ein.

Anfang des Jahrtausends wurde in einem mehrjährigen Migrationsprojekt diese mit redundanten Komponenten besetzte Anwendungslandschaft hochgradig konsolidiert. Mit dieser Konsolidierung wurde eine eindeutige Verortung fachlicher Fähigkeiten auf jeweils ein System bzw. eine Systemkomponente erreicht, sodass die Anwendungslandschaft heute aus einer Reihe von Client-Server-Systemen besteht, denen jeweils eindeutige Fachverantwortungen zuzuordnen sind.

Die einhergehende Reduktion der Systeme verringerte auch die Systemabhängigkeiten. Nichtsdestotrotz führt eine solche verteilte Anwendungslandschaft zu einem höheren Schnittstellenbedarf zwischen den Systemen als in einer vergleichsweise monolithischeren Anwendungslandschaft. Naheliegend in einer solchen Konstellation ist die SOAfizierung der Anwendungslandschaft, d. h. das Standardisieren der Kommunikationsbeziehungen über Services und das Abbilden fachlicher Prozesse durch die Orchestrierung der in der verteilten Anwendungslandschaft gehosteten Services in einer Business Process Engine (BPE).

Die SV Informatik skizzierte daher 2009 eine Plattformstrategie, die eben dieses anstrebte: Das Bereitstellen fachlicher Services aus den jeweils für die Domäne zuständigen Systemen, das Entkoppeln der Systeme über das Routen der Kommunikation durch einen zentralen Enterprise Service Bus (ESB) und die Flexibilisierung eben jener Geschäftsprozesse durch die Orchestrierung mithilfe einer BPE. Zeitgleich wurde – quasi als Untermauerung – eine Servicerichtlinie verabschiedet, die eine standardisierte und zielgerichtete Umsetzung der Strategie gewährleisten sollte. Im weiteren Verlauf entstanden peu à peu die ersten Services und Prozesse. Eine SOA-Keimzelle, die das operative Umsetzen der Strategie durch einen Projektpfad unterstützen sollte, wurde initiiert. Es wurden technologische Grundlagen geschaffen, organisatorische Prozesse aufgesetzt und Schulungsmaßnahmen durchgeführt.

Conway hat (noch immer) recht

Von einem Aufbruch des Unternehmens in Richtung einer SOA unter aktiver Einbringung der Mitarbeiter war allerdings nichts zu spüren. Warum dem so war, war zunächst unklar, denn handwerklich war das Vorgehen in Ordnung. Ursachenforschung wurde betrieben. Es stellte sich heraus, dass die Organisationsform der SV Informatik im damaligen Status quo das Umsetzen einer SOA behinderte. Die Linienorganisation war systembezogen aufgestellt, d. h. jede Entwicklungseinheit war für ein oder mehrere Systeme zuständig und trug für diese die volle Verantwortung für Stabilität, Fehleraufkommen und Entwicklungsgeschwindigkeit. Diese Verortung führte zu einer starken Einkapselung der Abteilungen, nach dem Motto „Störe meine Kreise nicht“.

Melvin E. Conway stellte in seinem Essay „How Do Commitees Invent?“ (1968) die These auf, dass Organisationen zwangsläufig Systeme (im allgemeinen Sinne) bauen, die den Kommunikationsbeziehungen der Organisation entsprechen. Die Forschung zu dieser These ist nicht eindeutig, hier allerdings traf es eindeutig zu: Kommunikation zwischen den Abteilungen fand nur in eingeschränktem Maße statt. Lösungen, die innerhalb einer Abteilung erstellt werden konnten, wurden Lösungen vorgezogen, die eine abteilungsübergreifende Zusammenarbeit erforderten. Abbildung 1 verdeutlicht diesen Sachverhalt.

sensler_soa_1.tif_fmt1.jpgAbb. 1: Schematische Darstellung von Conway‘s Law in der SV Informatik

Es wurde klar, dass ohne einen Change, der die Interaktion und Kommunikation zwischen den Abteilungen nicht veränderte, eine SOA nicht erstellt werden könnte. In diesem Kontext sind es insbesondere vier verschiedene Bereiche, in denen sich die Veränderung durch eine SOA zeigt: Menschen (People), Prozes...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang