SOA-Governance

1  Einleitung  4

2  SOA-Governance  5

2.1  SOA-Ansatz  5

2.1.1  SOA - Verknüpfung von IT und Business  6

2.1.2  SOA - Ansätze beim Aufbau  7

2.1.3  SOA - Ausgangslage  7

2.1.4  SOA - Realisierung  8

2.1.5  SOA - Technische Sicht  8

2.2  SOA-Governance - Regelwerk für SOA  8

3  Service-Lifecycle  9

3.1  Abläufe Service Lifecycle  9

3.1.1  Identify Business Processes  10

3.1.2  Service Modeling  11

3.1.3  Build and Compose  11

3.1.4  Publish and Provision  11

3.1.5  Integrate and Deploy  12

3.1.6  Secure and Manage  12

3.1.7  Evaluate  13

3.2  SOA Service-Lifecycle im Unternehmen  13

4  Maturity Models  14

4.1  Phasen  14

4.2  Reifegrade  15

4.2.1  Initial Services  15

4.2.2  Architectured Services  16

4.2.3  Business Collaborative Services  16

4.2.4  Measured Business Services  17

4.2.5  Optimized Business Services  17

4.3  Umsetzungsstand  18

4.4  Unterschiede Anbieter von SOA  18

4.4.1  Software AG webmethods  18

4.4.2  Oracle Bea Systems  19

4.4.3  IBM  20

  Seite  2

4.4.4  HP  20

4.4.5  Literatur  20

4.5  Zusammenhang Maturity Model - Service Lifecycle  20

5  SOA-Governance heute und morgen  21

5.1  Anwendung  21

5.2  Statistiken  22

5.3  Bewertung der Anbieter  22

6  Fazit  23

7  Anhang  24

7.1  Literatur Quellenverzeichnis  24

7.2  Abbildungsverzeichnis  29

  Seite  3

1 Einleitung

Der Alltag nahezu jedes Unternehmens ist heutzutage von Computern geprägt. Für viele Arbeiten, die in Unternehmen anfallen werden PCs verwendet. Durch die ausgeprägtere Vernetzung von Computern in den vergangenen Jahren bzw. Jahrzehnten resultierten für Unternehmen neue Möglichkeiten, Betriebsabläufe effizienter zu gestalten. Interne Postsysteme und manuelle unternehmensinterne Kommunikation sollten - so die Vorstellungen der SOA-Protektionisten - bald der Vergangenheit angehören[1]. Es kam anfangs zur Entwicklung von Softwaresystemen, welche die innerbetriebliche Kommunikation erleichtern sollten. Dies geschah in großen Unternehmen häufig abteilungsspezifisch bzw. es wurde Software erstellt, welche die Prozesse von Abteilungen erfasste, die häufig miteinander kommunizierten. Durch diese vereinfachten innerbetrieblichen Prozessabläufe eröffneten sich wiederum neue Optionen, die Betriebsprozesse an sich ebenfalls in ihrer Gesamtheit zu vereinfachen. Vielfach schlug dies allerdings aufgrund der Inkompatibilität der einzelnen Softwarekomponenten in den betreffenden Abteilungen fehl. Auch wirtschaftliche Interessen vieler Unternehmen, einzelne Datenverarbeitungsschritte bzw. -dienste extern ausführen zu lassen bedingten schließlich die Entwicklung serviceorientierter Architekturen (SOA). SOA ist eines der am häufigsten genannten Worte der letzten Jahre im Bereich der Softwareentwicklung. Das SOA-Konzept bzw. -Paradigma setzt an dieser Stelle an und vermag die zwischen den einzelnen Systemen klaffende(n) Lücke(n) zu schließen. Speziell durch die neuartige Konzeption wurden jedoch weitere Regelungsmechanismen erforderlich, welche dazu beitragen sollen, SOA konsistent zu steuern und zu organisieren. Mit SOA-Governance existiert seit einigen Jahren eine solche Regelbeschreibung, die den direkten Bezug zu SOA herstellt. Zum Gesamtkontext der SOA-Governance werden einige Merkmale zugeordnet, von denen in dieser Seminararbeit in besonderer Weise die Maturity Models sowie der Service-Lifecycle Betrachtung finden.

Seite 4

2 SOA-Governance

Zum Verständnis des Themenkomplexes sowie der Einordnung von "Service- Lifecycle" und "Maturity Model" in den Gesamtkontext SOA werden im Folgenden die grundlegenden Fakten und Merkmale von SOA sowie SOA-Governance betrachtet. Thema sind ebenso die historische Entwicklung und die Motivation, die zu SOA geführt haben.

2.1 SOA-Ansatz

Der Begriff "SOA" wurde 1996 vom Marktforschungs-unternehmen Gartner geprägt[2]. Eine allgemein akzeptierte Definition[3] dafür gibt es derzeit nicht. Die zentralen Aspekte der Definitionen sind, die Geschäftsprozesse besser durch die IT zu unterstützen bzw. die Geschäftsprozesse in der Softwarearchitektur abzubilden[4]. Das übergeordnete Ziel von SOA ist es also die IT mit den Geschäftsprozessen des Unternehmens zu verzahnen. Hauptbausteine von SOA sind einzelne "Services"[5]. Oracle definiert[6] den Begriff Service als "die kleinstmöglichen Bausteine, aus denen sich geschäftliche Abläufe ausgeklügelt zusammensetzen lassen". Über ein Netzwerk, beispielsweise das Internet ist es Services, welche unter SOA- Gesichtspunkten entwickelt wurden, möglich untereinander zu kommunizieren und zu interagieren[7]. Werden mehrere Services zusammengestellt[8] so entstehen Anwendungen (Applikationen). Einzelne Services werden im SOA-Modell meist von mehreren Anwendungen verwendet. Diese Wiederverwendbarkeit von Services ist ebenso eines der zentralen Merkmale von SOA. Es geht bei SOA also sowohl um die Integration unternehmensinterner Services wie auch um die Integration unternehmensexterner Services. Die Funktionalität der einzelnen Services richtet sich dabei an den Betriebs- und Geschäftsprozessen der einzelnen Unternehmen aus. Neue Services können im laufenden Betrieb hinzugefügt werden, ohne dass schon vorhandene Implementierungen anderer Services beeinträchtigt werden. Dies ermöglicht eine schrittweise Erweiterung der SOA-Landschaft. Zusätzlich können die einzelnen Services den (externen) Partnern der Unternehmen zugänglich gemacht werden. Für eine Argumentation innerhalb eines Unternehmens ist dies einer der wichtigsten Vorteile, auf den die Befürworter von SOA bei einer Diskussion hinweisen können.

Seite 5

2.1.1 SOA - Verknüpfung von IT und Business

SOA hilft Unternehmen, die Betriebs- und Geschäftsprozesse auf die IT umzusetzen.

Einzelne Teilanwendungen können flexibel neu gestaltet[9] werden und zu neuen Anwendungen kombiniert werden[10]. Dabei wird auf die eingangs erwähnten Services zurückgegriffen. Durch die Rekombination können diese Services schnell und flexibel den Marktverhältnissen angepasst werden.

Abbildung 1: Flexibilität im Geschäftsprozess

Unternehmen welche ihre Dienstleistungen mittels SOA anbieten, beispielsweise als kostenpflichtige Webservices, können somit schneller neue bzw. von den Nutzern nachgefragte Dienstleistungen anbieten. Diese Aspekte werden in der Literatur auch als "time to market" zusammengefasst[11]. Als Beispiel wird im Folgenden ein Unternehmen betrachtet, welches - wie in Abbildung 1: Flexibilität im Geschäftsprozess - für den Verkauf seiner Produkte nach außen drei Vertriebskanäle unterhält, welche nach dem SOA-Paradigma gestaltet sind. Treten nun gesetzliche Änderungen in Kraft, wird ein neuer Service entworfen, der diese Neuerungen umsetzt. Anschließend wird dieser mit dem Customer Relationship Management (CRM) verknüpft. Die aufgetretenen Gesetzesänderungen werden so für alle drei Vertriebswege zusammen mit lediglich einer Änderung in der Software des Unternehmens verwirklicht.

Seite 6

2.1.2 SOA - Ansätze beim Aufbau

Grundsätzlich werden zwei verschiedene Arten der Einsetzung von SOA unterschieden. Zum einen ist dies der Top-down-Ansatz, zum anderen der „Bottom up“-Ansatz. Diese Begriffe sind bereits in der Informatik bekannt und werden hier ebenso wie dort verwendet.

Beim Top-down-Ansatz[12] wird von „oben“ die Einführung von SOA beschlossen und für alle Abteilungen des Unternehmens verbindlich verfügt. Hierbei wird der gesamte Betriebsprozess erfasst und anschließend für Teilbereiche immer weiter verfeinert, bis die niedrigste Stufe erreicht ist und die Anwendungen verknüpft werden können. SOA Governance kann nur bei diesem Modell zur Anwendung kommen, da hierfür eine allumfassende Sichtweise notwendig ist.

Im Bottom-up-Modell[13] werden zunächst für einzelne Abteilungen bzw. Teilbereiche des Unternehmens Services gebildet und anschließend alle diese Teilbereiche in die Gesamtarchitektur eingefügt.

2.1.3 SOA - Ausgangslage

Um die beiden Ansätze zur Einführung von SOA in einem Unternehmen besser verstehen zu können ist es wichtig, die Ausgangslage der Unternehmen zu betrachten. In fast allen Unternehmen wurden seit der Einführung der Elektronischen Datenverarbeitung Systeme erschaffen, die lediglich einen Teilbereich von Daten erfassten. Oftmals wurde dabei Software entwickelt, die nicht alle Abteilungen des Unternehmens involvierte. Bildlich kann man sich dies vorstellen wie eine Softwarelandschaft, welche aus vielen kleinen Inseln besteht[14]. In den seltensten Fällen konnten Applikationen von verschiedenen Abteilungen, die nicht schon bei der Implementierung diese Funktionalität boten im Nachhinein so verändert werden, dass eine Schnittstelle zum automatisierten Informationsaustausch existierte[15]. Durch die fehlende Kompatibilität sowie fehlende Schnittstellen kam es in der Vergangenheit in vielen Unternehmen immer mehr zu redundanten Arbeitsschritten[16]. Geht die SOA-Initiative von einer einzelnen Abteilung aus (bottom up), dann fehlt mitunter die Sicht auf andere Abteilungen, die andere Anforderungen an die SOA haben können, als die Initiativabteilung. Um eine SOA unternehmensweit einführen zu können und dabei auch sämtliche EDV des Unternehmens einzubeziehen muss diese von oben (top down) initiiert werden[17].

Seite 7

2.1.4 SOA - Realisierung

Bei der Einführung einer SOA werden die genannten Altanwendungen entweder gekapselt und dann als Service dem Rest der entstehenden SOA-Umgebung zur Verfügung gestellt. Alternativ wird die Funktionalität der Altanwendung von einem neu erstellten Service angeboten. Auch die Beibehaltung von alten Umgebungssystemen[18] ist möglich. Nötig ist lediglich die Einhaltung der Schnittstellenkonventionen. Durch die Einführung von SOA werden in manchen Fällen auch Teile von Altanwendungen selbst redundant und brauchen nicht mehr zur Verfügung stehen. Die Funktionalität der Services richtet sich in der Regel am Geschäfts- bzw. Betriebsprozess aus.

2.1.5 SOA - Technische Sicht

Eine Möglichkeit der Realisierung bietet die Erfassung der Betriebs- und Geschäftsprozesse mittels Business Process Modelling Notation (BPMN) sowie die Realisierung sämtlicher Services als Webservice. Externe Webservices können anhand der bereitstehenden Beschreibungen als Web Service Description Language (WSDL) in die SOA eingebunden werden. Altanwendungen bzw. Services können gekapselt werden und auf einem Server ebenfalls als Webservice zur Verfügung gestellt werden.

2.2 SOA-Governance - Regelwerk für SOA

SOA-Governance bezeichnet Aktivitäten, Entscheidungen, Rollen und Verantwortlichkeiten zur Regulierung und Kontrolle einer SOA[19]. Nur mit SOA- Governance könne das gesamte SOA-Potential ausgeschöpft werden, beschreiben Software-Unternehmen die Notwendigkeit eines Regelwerks[20] und assoziieren damit SOA-Governance. Eine SOA besteht aus einer Vielzahl an veränderlichen Einzelteilen. Ohne feste Regeln in den Bereichen Qualitätssicherung, Verfügbarkeit, Komponentenwechsel, Performance und Zuverlässigkeit würde im Laufe der Zeit das Chaos in der SOA drohen[21]. Damit nicht durch fehlende Regeln die SOA diejenige Leistungsfähigkeit und Effizienz einbüßt, welche sie nicht unwesentlich ausmacht, wird sie von SOA-Governance-Instrumentarien überwacht und geregelt. Dadurch wird verhindert, dass mehrmals die gleichen Anwendungen erschaffen werden bzw. um doppelte Arbeiten an den Services vorgenommen werden. Ebenso wird eine effiziente Verwaltung sichergestellt. Ein Element dieser Verwaltung ist die Schaffung und Führung eines Repositories, welches in SOA-Projekten als zentrale

Seite 8