Probleme und Lösungen bei einer SOA

Technik anpassen ist einfach, Strukturen ändern schwierig

Carsten Sensler, Michael Heinke

©Shutterstock/alice-photo

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.

Abb. 1: Schematische Darstellung von Conway‘s Law in der SV Informatik

Abb. 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), Prozesse (Process), Technologie (Technology) und Information (Information) – die PPTI.

People: Menschen überzeugen

Wir haben ein SOA-Team als virtuelles Team im Querschnitt zur Linienorganisation etabliert. Das heißt, wir haben aus jeder Entwicklungsabteilung zwei Entwickler rekrutiert, die nach entsprechender Schulung Speerspitzen für SOA in den einzelnen Abteilungen sein sollten. Wir wollten keine neue reale Linieneinheit, da wir damit ja auch wieder Grenzen zu den anderen Abteilungen gezogen hätten. Wir glauben auch, dass ein SOA-Team ein Mindestmaß an Fachwissen der jeweiligen Domänen mitbringen muss, um in der Service- und Prozessentwicklung optimal mitzuwirken. Eine separate Einheit hätte das Domänenwissen im Laufe der Zeit verloren. Dieses SOA-Team eröffnete uns Kommunikationskanäle zwischen den Abteilungen. Außerdem war es uns über das SOA-Team möglich, die Abteilungsgrenzen durchlässig zu machen: Die Diskussionen innerhalb des SOA-Teams zu Serviceschnitten und Prozessgestaltung führten zu einer Teambildung, die in die Abteilungen hineinwirkte.

Um erfolgreich eine Transformation – und die Einführung einer SOA ist eine große Transformation – zu gestalten, hat es sich bewährt, Unterstützer zu finden. Unterstützer zum einen in dem Sinn, dass aus dem Management dem Transformationsteam der Rücken gestärkt wird, wenn es einmal zu Eskalationen kommt. Und zum anderen in dem Sinn, dass auch genügend Atem in Form von Geduld und auch Budget zur Verfügung steht. Eine SOAfizierung eines Unternehmens ist keine Angelegenheit von ein paar Wochen. Wir reden hier eher von Monaten und Jahren. Außerdem ist es wichtig, Unterstützer in den Anwendungsentwicklungsabteilungen (AE) zu finden. Aus Erfahrung lässt sich sagen, dass es sehr hilfreich ist, wenn andere Gutes über das Transformationsteam verbreiten und somit für die Sache an sich Werbung gemacht wird. Erreichen kann man dies, indem sich das Transformationsteam insbesondere zu Beginn der Transformation sehr stark in der Beratung und Hilfe für die AE engagiert. Das ging sogar soweit, dass das Transformationsteam Aktivitäten übernommen hat, die später im Regelbetrieb die Aufgabe der Entwicklungseinheiten sein wird.

Information: eine Sprache sprechen

Wir leben konsequent einen „Contract First“-Ansatz, d. h. vor jeglicher Entwicklung von Services müssen die Serviceentwickler des Consumers und des Providers einen formalen Vertrag schließen, der die Fachlichkeit des Service, dessen beabsichtigte Nutzung oder SLAs festlegt. Vertrag verstehen wir hier wörtlich: Es muss eine von beiden Seiten tragbare Vereinbarung getroffen werden. Nichtsdestotrotz ist der Provider eines Service offensichtlich in einer stärkeren Verhandlungsposition. Dies ist einer der Gründe, warum wir ein Common Data Model (CDM) einsetzen. Da sich beide Parteien auf Strukturen in einer ihnen nicht nativen Sprache einigen müssen, müssen sie in einen intensiven Dialog gehen, der keiner Partei einen unfairen Vorteil gibt. Darüber hinaus entkoppeln wir mit dem CDM die Schnittstellen von den Systemspezifika und fördern die Konzentration auf die Fachlichkeit eines Service (Abb. 2).

Abb. 2: Schematische Darstellung des Common Data Models

Abb. 2: Schematische Darstellung des Common Data Models

In der Literatur finden sich oftmals skeptische Einschätzungen gegenüber einem CDM. Eine Problematik, die häufig angesprochen wird, ist die der Änderungsabhängigkeit von Services in Bezug auf die Strukturen eines CDM. Diese Problematik haben wir auch gesehen und uns daher darauf zurückbesonnen, dass es bei einem CDM im Kontext einer SOA nicht um ein Modell für beispielsweise eine Persistenz geht, sondern um eine Sprache, die das Definieren von Nachrichten unterstützt.

Für uns ist daher ein CDM nicht ein Modell im klassischen Sinne, sondern eher ein Wörterbuch, das die fachliche Attributierungen enthält, die in der Formulierung von „Nachrichtensätzen“ erforderlich sind. Strukturen und Beziehungen, wie man sie in einem Modell erwartet, finden sich in diesem Wörterbuch kaum wieder. Außerdem ist dieses Wörterbuch gegenüber Änderungen unempfindlich: Erweiterungen des Wortschatzes führen zu neuen Ausdrucksmöglichkeiten, ändern aber keine bestehenden Sätze und sind daher im SOA-Sinne kompatible Änderungen und bedingen keine Versionierung bestehender Services.

Technology: eine Basis schaffen

Der Punkt „Technologie“ ist nur vermeintlich der schwierigste. Es hat sich gezeigt, dass man die technologischen Herausforderungen und Probleme im Allgemeinen leichter lösen kann als viele andere Herausforderungen der SOAfizierung.

Die Entscheidung der SOA-Laufzeitumgebung wurde gefällt. Sie fiel auf den Oracle Service Bus (OSB). Es gab ein Team, das manuell die notwendigen Proxy-Flows in der OEP (OSB-Entwicklungsumgebung) modelliert und in die Laufzeitumgebung eingespielt hat. Die manuelle Tätigkeit und auch das Lernen über die Zeit haben allerdings zu vielen unterschiedlichen Ausprägungen der Proxy-Flows geführt. Es gab auch kein zentrales Logging- und Service-Monitoring-Konzept. Außerdem fehlte es an einem Standardvorgehen zur Anbindung von Web Services auf dem OSB. Hinzu kam, dass es bereits generative Ansätze innerhalb mancher AE gab, die aus PL-/SQL-Businesslogik Web-Services-Schnittstellen erzeugten. Leider folgte man hier dem Code-First-Ansatz. Mit steigender Anzahl von servicebasierter Kommunikation wurden der Wunsch und auch die Notwendigkeit eines Service-Repository-Werkzeugs stärker.

Nach einer Evaluierung hat sich die SV Informatik für das Service Repository CEISeR (Common Enterprise Integration Service Repository) von der Deutschen Telekom entschieden. CEISeR ist prinzipiell ein Modell-Repository zur Verwaltung beliebiger Metadaten. Im Kontext von SOA gab es ein entsprechendes Metamodell, das die notwendigen Entitäten und deren Beziehung untereinander beschreibt und in CEISeR genutzt wird. Beispiel: Ein Service ist ein WSDLPortType und hat eine Beziehung zu Komponenten einer Anwendung. Eine Anwendung wird durch ein Binding an einen Zugangspunkt einer Umgebung gebunden. CEISeR bietet nicht nur die Möglichkeiten zur Persistierung der Informationen, sondern auch ein Generatoren-API basierend auf openArchitectureWare (oAW). Mit dieser kann auf das Objektgeflecht zugegriffen und darüber navigiert werden, um die Daten in einer Transformation in einer anderen Repräsentation wieder zu nutzen (Model-2-Text-Transformation).

Durch die Modellierung einer Servicearchitektur in CEISeR ist es aufgrund des MDSD-Ansatzes und dem oAW-Generator-Frameworks möglich, Templates in Xpand zu entwickeln, um z. B. den Proxy-Flow für den OSB generativ zu erstellen. Durch die Möglichkeit, die generierten OSB-Artefakte automatisch einzuspielen, wurde die Bereitstellung der Laufzeitumgebung voll automatisiert. In Abbildung 3 ist die Verzahnung von Service-Repository und SOA-Laufzeitumgebung grafisch dargestellt.

Abb. 3: Schematische Darstellung des Service-Repository und Verzahnung mit der SOA-Laufzeitumgebung

Abb. 3: Schematische Darstellung des Service-Repository und Verzahnung mit der SOA-Laufzeitumgebung

Wir sind sogar einen Schritt weitergegangen und haben nicht nur die SOA-Laufzeitumgebung automatisiert mit der Servicearchitektur bestückt. Auch der Metadatenspeicher (MDS – Meta Data Services) für die Oracle BPEL Suite wurde aus dem zentralen Repository automatisch und generativ bereitgestellt. Ein weiterer Anwendungsfall in diesem Kontext war die komplette Generierung einer PL-/SQL-Service-Fassade basierend auf der modellierten Servicearchitektur in CEISeR. Dieser Ansatz eignet sich für Reports unterschiedlicher Art ebenso wie für alle textbasierten Artefakte, die in einem Zusammenhang zur Servicearchitektur mit den entsprechenden Interfaces oder Laufzeitumgebungen stehen. Durch diesen flexiblen und äußerst agilen Ansatz war es uns möglich, nahezu auf Zuruf neue Reports oder Ähnliches zu erstellen und die unterschiedlichen Stakeholder inhaltlich zu überzeugen.

Ein weiterer großer Vorteil eines zentralen Service-Repositories ist die Governance. Dadurch, dass automatisch ein Regelwerk auf die in CEISeR eingespielten Artefakte angewandt werden kann (so genannte Constraints), ist es möglich, eine strikte SOA Governance zu etablieren. Die toolgestützte SOA Governance erstreckt sich in diesem Fall über folgende Aspekte:

  • Zu einer modellierten Servicekommunikation muss ein Service-Contract für Service-Provider und Service-Consumer in CEISeR hinterlegt sein.
  • WSDL-Richtlinienkonformität wird automatisch überprüft.
  • Namenskonventionen werden automatisch überprüft.
  • Bereits produktiv genutzte Datendefinitionen (XSDs) können nicht mehr verändert werden.
  • Service-Provider und Service-Consumer verweisen auf die gleiche Schnittstellendefinition.
  • Ein Service ohne Endpunkt (physischer IP-Port und IP-Adresse sowie optional Kontext-Root) kann nicht in eine Laufzeitumgebung provisioniert werden.

Process: kurze, gut geplante Iterationen

Wir leben ein zyklisches Releaseverfahren mit drei Releases im Jahr. Um in diesem Zyklus möglichst frühzeitig Klarheit über die anstehenden SOA-Themen zu bekommen, findet zu Beginn der Entwicklungsphase ein SOA-Day statt. Dort werden im Plenum und kleinen Gruppen innerhalb des SOA-Teams übergreifende Abstimmungen und zumindest Entwürfe der Contracts erstellt. Im Vorfeld des SOA-Days führen die SOA-Entwickler eine Sichtung der SOA-relevanten Anforderungen des Releases durch, um neue bzw. zu ändernde Services und Prozesse zu identifizieren. In diesem Kontext werden auch evtl. notwendige Erweiterungen des CDM identifiziert und zur Abstimmung an die Produktmanager gegeben. Denn diese haben dazu inhaltlich die Führung.

Der SOA-Day ist somit quasi Kick-off für die Umsetzungen des SOA-Teams im Entwicklungszyklus. Darüber hinaus war es eminent wichtig, die im Kontext von SOA anfallenden Tätigkeiten in den normalen Entwicklungsprozess einzubinden und anzukoppeln. Nur dadurch ist es möglich, die virtuellen SOA-Teams in die realen Linienprozesse nachhaltig einzubinden.

Abb. 4: Schematische Darstellung des Prozesses von der Anforderung bis zum Betrieb eines SOA-Services

Abb. 4: Schematische Darstellung des Prozesses von der Anforderung bis zum Betrieb eines SOA-Services

Abbildung 4 zeigt schematisch den Prozess, wie er in der SV-Informatik umgesetzt wurde – von der Anforderungsanalyse eines SOA-Services bis hin zum Betrieb. Es ist leicht zu erkennen, dass nahezu in jedem Schritt Vertreter eines zentralen SOA-Teams involviert sind. Der Schritt 2 (CDM) wird ohne SOA-Team bewerkstelligt, weil dort sehr fachlich über allen Anwendungen hinweg Fragmente für das gemeinsame Datenmodell definiert werden. Diese Aufgaben werden in dem Unternehmen durch die Enterprise-Architektur sowie die jeweiligen Produktmanager der Anwendungssysteme erledigt.

Ausblick: kompletter Übergang ins Regelgeschäft

Die vier von der Veränderung im Wesentlichen betroffenen Dimensionen haben wir dargestellt und zu jeder Herausforderung die passende Antwort finden können. Aktuell besteht die letzte konkrete Herausforderung noch in dem Punkt, dass die beschriebenen Aufgaben und Tätigkeiten in das Tagesgeschäft der Linie in den Entwicklungsabteilungen übergehen. Aktuell wird die SOAfizierung durch ein dediziertes Team von internen und externen Experten geführt. Dieses Team soll bis Ende 2016 durch die Verschiebung der Tätigkeiten ins Regelgeschäft aufgelöst werden. Es bleibt spannend, und sicherlich können wir Ihnen von dieser Herausforderung der Transition in einem weiteren Artikel im kommenden Jahr berichten.

Aufmacherbild: Science Molecule, Molecular DNA Model Structure, business teamwork concept von Shutterstock / Urheberrecht: alice-photo

Verwandte Themen:

Geschrieben von
Carsten Sensler
Carsten Sensler
Carsten Sensler berät Kunden im Kontext ihrer Transformation. Bis Ende 2013 war er bei einem DAX-30-Konzern VP „Technology, Architecture and Operation“ für ein strategisches Geschäftsfeld. Vorher arbeitete er als Group-Enterprise-Architekt und war verantwortlich für die Ausgestaltung der Konzernzielarchitektur. Zuvor war er in einer verantwortlichen und treibenden Rolle für die internationale Standardisierung einer SOA (Laufzeitumgebung, Monitoringwerkzeuge, Service-Repository und der entsprechenden SOA Governance) in einem DAX-30-Konzern.
Michael Heinke
Michael Heinke
Michael Heinke ist Enterprise-Architekt im Stab der Geschäftsführung der SV Informatik GmbH. Er hat dort maßgeblich das Architekturgefüge mitgestaltet und leitet u. a. derzeit die SOA-Initiative. Zuvor war er in verschiedenen Rollen im Konzern der SparkassenVersicherung unterwegs und hat dabei die Versicherungsbranche in all ihren Facetten von der Produktentwicklung als Aktuar bis zur IT-Entwicklungsleitung business- und IT-seitig aktiv kennengelernt.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: