www.bt-magazin.de 1.10

Expertenwissen für IT-Architekten, Projektleiter und Berater

Schwerpunkt:

SoftwareArchitektur

ServicesichtenDen passenden Service � nden

People Change ManagementÄnderungsprozesse erfolgreichmeistern

How does IT matter?Den Wertbeitrag der IT bestimmen

Enterprise SOA SecurityTeil 1: Die Herausforderungen

Aus alt mach neuDie 10 Regeln der Modernisierung

Businessorientierte Architekturansätze

Kanban inSoftwareprojekten

Pragmatic SOA – Beschränken auf das Wesentliche

Erl:„SOA in a Box hat die

Probleme verursacht“

Sonderdruck für

www.mid.de

www.bt-magazin.de

SOA Governance

2 bt | 1.2010

Autor: Jochen SeemAnn

Die Vision von SOA verspricht, wonach die IT schon lange strebt: Eine schnelle und flexible Unterstützung der Anwender auf der einen Seite und kostensenkende Wiederverwendung von Komponenten auf der anderen Seite. In der Realität hat sich SOA jedoch in den letzten Jahren einen schlechten Ruf erworben, da es vielen Kun-den nicht gelang, diesen Nutzen zu erzielen. Ein Grund dafür ist, dass oft lediglich bestehende Komponenten mit Service Interfaces versehen werden. Dabei fordert SOA einen viel umfassenderen Denkansatz und eine neue Kultur, die Services aus dem Bedarf der Anwender her-aus identifiziert und über Jahre hinweg in der SOA-Inf-rastruktur in so genannten SOA-Repositories verwaltet. Diese Vorgehensweise nennt man SOA Governance.

SOA und GeSchäftSprOzeSSmOdellierunGDer wichtigste Schritt in einer SOA-Kultur ist die Service identifikation aus dem Bedarf der Anwender einer Applikation heraus. Dazu ist es zunächst einmal notwendig, den Bedarf der Anwender präzise zu er-fassen. Vor SOA ging man stets von einzelnen Anwendungen aus und konzentrierte sich darauf, deren An-forderungen zu spezifizieren. Das Ergebnis davon war eine Vielfalt von einzelnen Anwendungen, die ein Fachbereichsmitarbeiter im Rahmen

eines Geschäftsprozesses benutzen musste. In einer SOA zerfallen die „alten“ Anwendungen in feingranulare Services, die für den Fachbereichsmitarbeiter möglichst den Geschäftsprozessen folgend zusammengebunden werden. Folgerichtig muss eine erfolgreiche SOA mit der Analyse der Geschäftsprozesse beginnen. Allerdings führen Geschäftsprozesse per se nicht zu der versproche-nen Wiederverwendung. Deshalb ist die Serviceidentifi-kation nach der Geschäftsprozessanalyse eigentlich der wichtigste methodische Schritt in einer SOA. Abbildung 1 zeigt einen typischen Geschäftsprozess.

Die Darstellung wählt die neue BPMN-2.0-Notation, die für SOA einen wesentlichen Vorteil bietet: Früher benutzten BPM-Spezialisten und Fachbereiche speziel-le Notationen wie EPKs, die IT verwendete Notationen wie UML, was neben Verständnisproblemen auch dazu führte, dass die Modelle der IT nicht direkt auf Model-le aus dem Fachbereich aufsetzen konnten. Jetzt erlaubt

transparente SOA Governance mit Bpm-modellen

Geschäftsprozesse und SOA GovernanceGeschäftsprozesse ändern sich – eine dafür flexible und agile It-Landschaft verspricht sich

heute jeder von serviceorientierten Architekturen. Der erfolgreiche einsatz von SoA erfordert

SoA Governance, um die unterschiedlichen Aspekte eines Serviceportfolios zu steuern. Wie

können modelle die SoA Governance vereinfachen?

Abb1: einfacher Geschäftsprozess eines Kartenverkaufs

3bt | 1.2010www.bt-magazin.de

die BPMN 2.0 sowohl die einfache verständliche Dar-stellung für den Fachbereich als auch die Anreicherung mit technischen Details für die IT in Bezug auf SOA-Implementierungen. Bei der Betrachtung von Geschäfts-prozessen für SOA beginnt man meist mit einfachen Modellen wie in Abbildung 1 und verfeinert dann die Modelle wie etwa in Abbildung 2.

Anhand dieser verfeinerten Prozesse versucht man nun, die Funktionalität wiederverwendbarer (Fach-)Services zu definieren. Im obigen Beispiel erkennt man schnell, dass ein Reservierungsservice zur Unterstützung des Geschäftsprozesses z. B. das Ermitteln der freien Plätze, das Reservieren dieser Plätze und die Freigabe dieser Plätze beinhalten sollte. Das Ermitteln der Preise hingegen scheint ein anderer fachlicher Service zu sein. Abbildung 3 zeigt nun eine angereicherte Version des Prozesses, mit dem die IT nun weiterarbeiten und zu-sätzlich technische Informationen, wie beispielsweise die genauen Daten- und Nachrichtenstrukturen, hin-terlegen kann.

WiederverWendunG und Service- identifikAtiOnSinn und Zweck von SOA ist die Wiederverwendung der fachlichen Services in möglichst vielen Geschäfts-

Abb. 2: Verfeinerung linker teilprozess „Kartenreservierung“

Abb. 3: teilprozess „Kartenreservierung“ mit identifizierten Services

prozessen. Hat man einen Service identifiziert, ist die nächste Frage, ob ein derartiger Service in der SOA schon existiert. Hier schlägt die Stunde der SOA-Re-positories, in denen die bestehenden Services und ihre Spezifikationen verwaltet werden. Gibt es den Service bereits, kann er eingesetzt werden. Gibt es ihn noch nicht, wird er für die Entwicklung vorgeschlagen und in einem Prozess, der alle potenziellen Nutzer des Ser-vice einbezieht, spezifiziert. Das führt zur Wiederver-wendung der Services in mehreren Geschäftsprozessen, wie in Abbildung 4 dargestellt. Bei Änderung der Ge-schäftsprozesse muss man nun feststellen können, wel-che Services beteiligt sind und wie sie beteiligt sind – in welchen Services also diese Änderung berücksichtigt werden muss. Um dies einfach in Erfahrung zu bringen, verknüpft man die Geschäftsprozesse mit den Services im SOA-Repository. Man nennt dies auch „Traceabi-lity“.

GeSchäftSprOzeSSe AuSführBAr mAchenIm Rahmen von SOA ist es üblich geworden, den Aufruf von Services, um einen Geschäftsprozess auszuführen, nicht mehr in Code zu programmieren. Als Alternati-ve werden Geschäftsprozesse mithilfe von deklarativen Ablaufsprachen wie BPEL umgesetzt. Üblicherweise

www.bt-magazin.de4 bt | 1.2010

werden Geschäftsprozesse über mehrere Hierarchien hinweg modelliert. Aus den Teilen dieser Modelle, die von IT-Systemen unterstützt werden, wird nun eine BPEL-Ablaufbeschreibung generiert (Abb. 5). Diese wird dann mithilfe von BPEL-Editoren mit Details ver-sehen, die die spezifische BPEL-Umgebung betreffen.

In der Praxis werden BPEL-Informationen eben-falls in der SOA-Infrastruktur gespeichert. Wie bereits erwähnt, ändern sich die Geschäftsprozesse häufig. Ähnlich wie oben beschrieben, muss man mithilfe von Verknüpfungen zwischen den Prozessen und den abge-leiteten BPEL-Ablaufbeschreibungen im Rahmen der SOA Governance bei Änderungen prüfen, welche BPEL-Beschreibungen abgeändert werden müssen.

GeSchäftSprOzeSSe und SOA GOvernAnceEs gibt eine Reihe von guten Gründen, bei der Ver-waltung einer SOA im Rahmen der SOA Governance verstärkt auf die zugrunde liegenden Geschäftsprozes-se einzugehen. Zum einen hängt über die Serviceiden-tifikation der Erfolg einer SOA überhaupt davon ab, zum anderen sind die Geschäftsprozesse unabdingbar,

um Änderungen bei den Metainformationen wie BPEL nachzuvollziehen. Dabei ist es wichtig, dass alle, die an der SOA beteiligt sind – vom Fachbereichsexperten bis zum BPEL-Designer – die Geschäftsanwendung verste-hen.

Geschäftsprozessmodelle sind ideal geeignet, um allen Beteiligten ein einheitliches Verständnis zu ver-mitteln. Neue Notationen wie die BPMN 2.0 für Ge-schäftsprozesse erlauben es endlich, dass Anwender (Fachbereich) und IT an einem Modell arbeiten und erst-mals die gleichen Werkzeuge und Diagramme in einer SOA einsetzen.

Allerdings kommen die Werkzeuge dafür gerade erst auf den Markt. Ebenfalls in den Kinderschuhen steckt die notwendige Integration der technischen SOA-Inf-rastruktur wie Service-Repositories mit der Geschäfts-prozessmodellierung. Hier sind in nächster Zeit noch wesentliche Weiterentwicklungen zu erwarten.

fAzitErst wenn Transparenz vom Geschäftsprozess zum Ser-vice durchgängig gewährleistet ist, wird SOA Gover-

nance für alle Beteiligten greifbar. Dann wird die Vision von der Wiederverwendbarkeit und einer schnellen und flexiblen Reaktion auf Veränderungen Wirklichkeit. Modellie-rung kann wichtige Voraussetzungen dafür schaffen.

Jochen Seemann ist seit 2008 Geschäftsfüh-rer bei der mID Gmbh und beschäftigt sich seit mehr als 15 Jahren mit modellierung. Zuvor war er in unterschiedlichen leitenden Positionen bei

IBm/rational in Seattle (rational rose/XDe) und mi-crosoft in redmond (Visual Studio team System, DSL tools) tätig.

Abb. 4: Services werden in mehreren Geschäftsprozessen benutzt

Abb. 5: BPeL-Ablaufbeschreibungen spiegeln das Geschäfts-prozessmodell wider

Abb. 6: Viele Beteiligte müssen bei der SoA Governance hand in hand arbeiten