SOA-Governance

Inhaltsverzeichnis

1 Einleitung

2 SOA-Governance
2.1 SOA-Ansatz
2.1.1 SOA - Verknüpfung von IT und Business
2.1.2 SOA - Ansätze beim Aufbau
2.1.3 SOA - Ausgangslage
2.1.4 SOA - Realisierung
2.1.5 SOA - Technische Sicht
2.2 SOA-Governance - Regelwerk für SOA

3 Service-Lifecycle
3.1 Abläufe Service Lifecycle
3.1.1 Identify Business Processes
3.1.2 Service Modeling
3.1.3 Build and Compose
3.1.4 Publish and Provision
3.1.5 Integrate and Deploy
3.1.6 Secure and Manage
3.1.7 Evaluate
3.2 SOA Service-Lifecycle im Unternehmen

4 Maturity Models
4.1 Phasen
4.2 Reifegrade
4.2.1 Initial Services
4.2.2 Architectured Services
4.2.3 Business/Collaborative Services
4.2.4 Measured Business Services
4.2.5 Optimized Business Services
4.3 Umsetzungsstand
4.4 Unterschiede - Anbieter von SOA
4.4.1 Software AG / webmethods
4.4.2 Oracle / Bea Systems
4.4.3 IBM
4.4.4 HP
4.4.5 Literatur
4.5 Zusammenhang Maturity Model - Service Lifecycle

5 SOA-Governance heute und morgen
5.1 Anwendung
5.2 Statistiken
5.3 Bewertung der Anbieter

6 Fazit

7 Anhang
7.1 Literatur / Quellenverzeichnis
7.2 Abbildungsverzeichnis

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¹. 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.

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². Eine allgemein akzeptierte Definition³ 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⁴. Das übergeordnete Ziel von SOA ist es also die IT mit den Geschäftsprozessen des Unternehmens zu verzahnen. Hauptbausteine von SOA sind einzelne "Services"⁵. Oracle definiert⁶ 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⁷. Werden mehrere Services zusammengestellt⁸ 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.

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⁹ werden und zu neuen Anwendungen kombiniert werden¹⁰. 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 in dieser Leseprobe nicht enthalten

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¹¹. 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.

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¹² 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¹³ 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¹⁴. 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¹⁵. Durch die fehlende Kompatibilität sowie fehlende Schnittstellen kam es in der Vergangenheit in vielen Unternehmen immer mehr zu redundanten Arbeitsschritten¹⁶. 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¹⁷.

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¹⁸ 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¹⁹. Nur mit SOA- Governance könne das gesamte SOA-Potential ausgeschöpft werden, beschreiben Software-Unternehmen die Notwendigkeit eines Regelwerks²⁰ 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²¹. 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 Verwaltungsinstanz dient, die sämtliche Metainformationen und Artefakte für den Aufbau und die Steuerung der Architektur vorhält. In der Praxis unterliegen die Repository-Systeme wie CentraSite (Software AG)[22] selbst ständigen Veränderungen, haben demnach selbst noch Verbesserungsbedarf. Um die SOA auch während des Betriebs erfassen, warten und überprüfen zu können, sind weitere Regeln essentiell. Den Verantwortlichen des IT-Bereichs eröffnen diese Regeln die Möglichkeit, den gesamten Lebenszyklus der Elemente der SOA einzusehen und zu kontrollieren²². Diese werden von den einzelnen SOA- Anbietern teils unterschiedlich aufgestellt. Vielfach ist es üblich eine zentrale SOA- Management-Stelle²³ einzurichten, in welcher sämtliche Änderungen und Verantwortlichkeiten erfasst werden. In dieser werden ebenso die zuvor angeschnittenen Repositories verwaltet. Der Begriff SOA-Governance fasst folglich Regeln und Regelungsmechanismen verschiedener Art in sich zusammen. Einzelne Aspekte hiervon sind Service-Lifecycles sowie Maturity Models. Ebendiese sind Thema der folgenden beiden Abschnitte.

3 Service-Lifecycle

Beim Aufbau sowie während des Betriebs kommt es oftmals zu neuen Anforderungen an die Softwarelandschaft, so dass schrittweise neue Services in die SOA integriert werden. Die Erfassung dieser neuen Services ist ebenso Aufgabe der SOA-Governance, im speziellen die des Repositories, wie die Registrierung der möglicherweise neuen Funktionalität von veränderten Services.

3.1 Abläufe Service Lifecycle

Unter den SOA-Anbietern ist ein Service-Lifecyclemodell weit verbreitet, welches mehr oder weniger verändert angewendet wird. Aus diesem Grund wird an dieser Stelle das Modell von Bea Systems (Abbildung 2) betrachtet. Der Service Lifecycle gliedert sich zunächst in die Abschnitte "Design time"²⁴ und "Runtime"²⁵. Betrachtet man das Modell nur nach diesen beiden Abschnitten, so wird der Service während der Design Time entwickelt und in der Runtime publiziert und evaluiert. Generell ist zum Modell zu sagen, dass man beim Aufbau einer SOA den Zyklus eröffnet - dies geschieht an der Stelle "Identify Business Process" - und im weiteren Verlauf immer in diesem Zyklus verbleibt. Die Dauer eines Zyklusumlaufs richtet sich

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Service-Lifecycle (©Bea Systems)[24]

an der Notwendigkeit zu Änderungen am betreffenden Service aus. Das bedeutet, dass die Zeitdauer zwischen den einzelnen Stationen im Lifecycle unterschiedlich lang sein kann. Solange ein Service zufrieden stellend arbeitet und die an ihn gestellten Anforderungen erfüllt, so sind keine Änderungen notwendig und der Service verbleibt im Lifecycle an einer Station. Im Folgenden wird eine ausführliche Betrachtung der einzelnen Punkte in den beiden Abschnitten vorgenommen.

3.1.1 Identify Business Processes

Am Anfang des Service Lifecycles ist ein zentrales Merkmal von SOA angesiedelt, die Angleichung von Geschäftsprozess und IT. Als Vorgehensweise wird vorgeschlagen, die Ziele in drei zeitliche Kategorien einzuteilen (kurz-, mittel- und langfristige Ziele), um eine Gewichtung vorzunehmen. Diese Ziele sind anschließend nacheinander zu verfolgen. Dazu werden für jeden einzelnen Geschäftsprozess die notwendigen Voraussetzungen in einer Liste zusammengestellt. Nachdem dies abgeschlossen ist, werden Abhängigkeiten zu anderen Services geklärt.

[...]

¹ Thomas Bilz, "Sepa öffnet die Tür für SOA-Projekte" http://www.computerwoche.de/soa-trends/1853231/index.html (Abruf 05.01.2008)

² Yefin V. Natis, "Service Oriented Architecture Szenario", http://www.gartner.com/DisplayDocument?doc_cd=114358 (Abruf 15.11.2007)

³ Richard Hubert, "Software ist ein Service", http://www.mid.de/fileadmin/documents/pdf/sonstige /Computerwoche_SOA_2005_01_28.pdf (Abruf 20.11.2007)

⁴ IBM, "SOA: Audi führt Geschäftsprozesse und IT auf Basis von IBM WebSphere zusammen", www.ibm.com/news/de/de/2007/03/151.html (Abruf 15.01.2008)

⁵ Peter Eichhorst, "Softwarebausteine für die Prozesse", http://www.informationweek.de/showArticle. jhtml?articleID=197002224&cid=SOA (Abruf 10.01.2008)

⁶ Peter Riedberger, "Business Bausteine arbeiten effektiver", http://www.mittelstandswiki.de/Service-Oriented_Architecture,_Teil_1 (Abruf 20.01.2008)

⁷ visual rules "Whitepaper - Business Rules und SOA: Parallelen und Synergien", http://www.visual-rules.de/pdf/Business-Rules-SOA.pdf (Abruf 29.12.2007)

⁸ Daniel Liebhard, "Service Systems", http://www.computerwoche.de/soa-expertenrat/?p=198 (Abruf 13.12.2007)

⁹ Till Rausch, "Service orientierte Architektur Übersicht und Einordnung", http://www.till-rausch.de/assets/baxml/soa_akt.pdf (Abruf 17.12.2007)

¹⁰ valtech, "SOA-Konzepte als Basis für flexible Lösungen", http://www.valtech.de/de/index/management_consulting/consulting_DE/ soa_konzepte.html (Abruf 4.11.2007)

¹¹ Progress Actional, "SOA Development speeding time to market", http://www.actional.com/resources/white-papers/SOA-Infrastructure/SOADevelopment.html (Abruf 08.01.2008) Seite 25

¹² Nitin Bharti, " Voices from the Web: SOA - Top down or bottom up approach?", http://searchsoa.techtarget.com/news/article /0,289142,sid26_gci1070656,00.html (Abruf 21.11.2007)

¹³ CIO, "SOA-Projekte richtig angehen", http://www.cio.de/technik/820135/ (Abruf 7.12.2007)

¹⁴ ECIN, "Bitte keine Technologie Inseln" http://www.ecin.de/news/2006/03/13/09278/ (Abruf 2.12.2007)

¹⁵ Karin Sondermann, "SOA - sein oder nicht sein?", http://www.computerwoche.de/soa-expertenrat/?p=195 (Abruf 14.12.2007)

¹⁶ Bearing Point, "Shared Services", http://marktstudien. nzzcampus.ch/files/WhitePaper-SharedServices.pdf (Abruf 3.1.2008)

¹⁷ Progress Actional, "The Case for coordinating SOA Design" http://www.actional.com/resources/whitepapers/SOA-Worst-Practices-VolII/SOA-Design.html (Abruf 2.12.2007)

¹⁸ Andreas Zimmer, "Im Herz der SOA - Teil 3", http://www.resoommagazine.de/news-special-display-pages/detailed-article/article/serie-im-herzder-soa-teil-3-strukturierung-des-soa-anwendungsportfolios/ (Abruf 8.11.2007)

¹⁹ Wikipedia - die freie Enzyklopädie, Autoren siehe Versionshistorie, "SOAGovernance", http://de.wikipedia.org/wiki/SOA-Governance (Abruf 9.11.2007)

²⁰ IBM, "SOA-Governance", https://www- 306.ibm.com/software/at/solutions/soa/gov/ (Abruf 13.11.2007)

²¹ Novell, "SOA Governance und Identitätsmanagement" http://www.compliancemagazin.de/plaintext/markt/kommentare /soanovell141107.html (Abruf 20.11.2007)

²² Software AG, "SOA Governance und Lifecycle Management", http://www1.softwareag.com/de/products/soa/default.asp (Abruf 10.11.2007)

²³ Software AG, "SOA Governance - beherrschen Sie Ihre SOA", http://www.softwareag.com/de/Images /WP_SOA_Governance_D_tcm17-22130.pdf (Abruf 2.11.2007)

²⁴ Quinton Wall, "Understanding the Service Lifecycle within a SOA - Design Time", http://dev2dev.bea.com/lpt/a/521 (Abruf 17.11.2007) Seite 26

²⁵ Quinton Wall, "Understanding the Service Lifecycle within a SOA - Run Time", http://dev2dev.bea.com/lpt/a/539 (Abruf 17.11.2007)