Home 
ORDIX News 4/2008 IT-Strategie
ORDIX News 4/2008 IT-Strategie
ORDIX News 4/2008 IT-Strategie
und Entwickler, die sich mit SOA vertraut machen wollen.
| SOA-Governance Als SOA-Governance (auch Service Governance genannt) werden die Aktivitäten, Entscheidungen, Rollen und Verantwortlichkeiten zur Regulierung und Kontrolle einer serviceorientierten Architektur (SOA) bezeichnet. Konflikte sollen dabei nicht vermieden werden, sondern durch standardisierte und akzeptierte Prozesse ausgetragen werden. |
| Toolchain Toolchain bezeichnet eine Kette von Software-Werkzeugen, bei denen das Ergebnis (Output) von einem Werkzeug als Quelle (Input) für ein weiteres Werkzeug verwendet wird. Somit kann eine lückenlose Entwicklung von Software von der Design- bis zur Implementierungsphase ermöglicht werden. |
| Domain Mit einer Domain (Domäne) ist die Kapselung von logisch zusammengehörenden Services in einer diskreten Einheit gemeint, die eine Schnittstelle zum Zugriff von Außen anbietet. |
| Corporate Governance Mit diesem Begriff sind Methoden, Strukturen und Instrumente zur Leitung und Überwachung von Organisationen gemeint. |
| IT-Governance IT-Governance liegt in der Verantwortung des Managements und ist ein wesentlicher Bestandteil der Unternehmensführung. IT-Governance stellt Methoden, Strukturen und Instrumente bereit, mit denen gewährleistet wird, dass die IT die Unternehmensstrategie und -ziele unterstützt. |
Weiterführende Links
| ||
| ||
| ||
| ||
|
Wird eine SOA in einem Unternehmen ohne eine zentrale Steuerungseinheit eingeführt, so können sehr schnell redundante Implementierungen von Services mit geringer Wiederverwendung entstehen.
Damit SOA in der Praxis nicht im Chaos endet, sollten schon am Anfang eines SOA-Vorhabens unter anderem folgende Fragen beantwortet und entsprechende Maßnahmen ergriffen werden:
Werden diese Fragen vernachlässigt, so ist das SOA-Projekt von vornherein zum Scheitern verurteilt.
Da in heutigen Unternehmen die IT meist vertikal, entsprechend der Geschäftsbereiche, organisiert ist, wird die Verantwortung der Unternehmensanwendungen ebenfalls vertikal an den Geschäftsbereichen ausgerichtet (siehe Abbildung 1).
Die Grundidee der SOA, die am Geschäftsprozess ausgerichteten Services über verschiedene Bereiche hinweg mehrfach zu verwenden, steht somit konträr zur klassischen Verantwortung von IT-Anwendungen (siehe Abbildung 2).An dieser Stelle stellt sich die Frage, welche Interessen ein Geschäftsbereich an der Bereitstellung von Services hat, die durch andere Bereiche genutzt werden können? Diese Frage lässt sich mit ausschließlichem Fokus auf einen Geschäftsbereich nicht beantworten.
Da SOA insbesondere dann Mehrwert schafft, wenn bereichsübergreifende Unternehmens-interessen verfolgt werden, ist ein zentrales Management der Services im Unternehmen unabdingbar.
Mit dem Begriff SOA-Governance ist, vereinfacht gesagt, ein Steuerungsmechanismus gemeint, mit dem Rollen und Zuständigkeiten zur Regulierung und Kontrolle einer SOA festgelegt werden. Demzufolge kann SOA auch als ein Managementkonzept bezeichnet werden.
Vergleicht man SOA-Governance mit der klassischen IT-Governance, so kann man sagen, dass SOA-Governance eine Spezialform bzw. eine Weiterentwicklung der IT-Governance darstellt.
Deshalb verfolgt SOA-Governance dieselben Ziele wie eine IT-Governance mit der Erweiterung um serviceorientierte Aspekte. Abbildung 3 zeigt die Einordnung von SOA-Governance in eine unternehmensweite Governance-Hierarchie.
Die wesentlichen Aufgaben einer SOA-Governance sind:
Vergleicht man den Lebenszyklus einer herkömmlichen Anwendung mit einem Service-Lifecycle, so stellt man einen wesentlichen Unterschied fest: Im klassischen Fall handelt es sich in der Regel um eine Anwendung mit nur einem so genannten Software Lebenszyklus.
Bei einer SOA werden Services mit einer geringen Größe und Granularität zu einer Anwendung zusammengeschlossen. Dabei verfügen Services dann auch jeweils über einen eigenen Software-Lebenszyklus (siehe Abbildungen 4 und 5).
Da die einzelnen Services in der Regel von mehreren Servicekonsumenten aufgerufen werden, wird oft die Anforderung nach einer Versionierung und dem parallelen Betrieb von mehreren Serviceversionen gestellt. Auch diese Anforderung stellt einen Unterschied zum Lebenszyklus klassischer Anwendungen dar, wo in der Regel immer nur eine Version der Anwendung im Betrieb ist.
Mit Service-Portfoliomanagement ist eine strukturierte Verwaltung der Meta-Informationen (Servicebeschreibung) der einzelnen Services in einer so genannten Service-Registry/Repository gemeint. Dabei werden auch die Abhängigkeiten der Services untereinander gepflegt.
Das Ziel ist hierbei eine zentrale Erfassung und Veröffentlichung von Services, damit diese anschließend von Service-Konsumenten gefunden und genutzt werden können.
Eine weitere, wesentliche Aufgabe von SOA-Governance ist das Festlegen von Designprozessen und -standards für Services. Nur mit einem eindeutig definierten Designprozess für Services kann ein reibungsloser Verlauf bei der Entwicklung ermöglicht werden.
Zusätzlich müssen bereits in den ersten Phasen bei der Einführung von SOA so genannte Service-Designstandards und Technologiestandards eingeführt werden.
Da SOA in einem Unternehmen nicht nur definiert sondern auch aktiv gelebt werden muss, müssen zwingend einige neue Rollen definiert werden. Eine Rolle ist dabei nicht mit einer Stelle gleichzusetzen.
Die Ausgestaltung eines Rollenmodells ist in der Regel sehr unternehmensspezifisch. Die in einem Unternehmen bereits vorhandenen Rollen sollten dabei unbedingt berücksichtigt werden.
Zu einem SOA-Rollenmodell gehören unter anderen folgende Rollen:
Der Domänenverantworliche (Domain Owner) ist verantwortlich für eine oder mehrere Geschäftsdomänen. Unter einer Geschäftsdomäne ist hierbei eine logische Zusammenfassung fachlicher Services und Daten zu verstehen, die in einer engen Beziehung zueinander stehen. Das Besondere an dieser Rolle ist, dass diese einen großen Einfluss auf die strategische Weiterentwicklung der Domänen und eine enge Verbindung zu den Geschäftsebenen hat.
Die Rolle eines SOA-Architekten wird in der Regel in technische und fachliche Aspekte aufgeteilt. Der so genannte fachliche SOA-Architekt führt in der Regel die Anforderungsanalyse durch und hat eher einen fachlichen Fokus.
Der technische SOA-Architekt dagegen hat primär einen technologischen Schwerpunkt. Zusätzlich modelliert der technische Architekt zusammen mit dem Geschäftsprozessdesigner die Geschäftsprozesse auf der technischen Ebene unter Berücksichtigung der Vorgaben des fachlichen SOA-Architekten.
Grundsätzlich kann gesagt werden, dass die Rolle des SOA-Architekten eine Schlüsselposition bei der Entwicklung neuer Services für eine SOA darstellt.
Die Aufgabe eines Geschäftsprozess-Designers besteht hauptsächlich in der konkreten modelltechnischen Umsetzung der von den SOA-Architekten vorgegebenen Geschäftsprozesse. Dabei werden die Prozesse durch eine geeignete Komposition atomarer Services realisiert.
Schließlich ist der Service-Modellierer für die ausführliche Dokumentation der Dienstschnittstelle verantwortlich. Werden die Services z. B. mit Web-Services realisiert, so erstellt der Service-Modellierer die WSDL-Beschreibung (Web Services Description Languages). Anschließend wird der so modellierte Service durch den Service-Entwickler implementiert.
Zusammenfassend kann gesagt werden, dass SOA-Governance eine grundlegende Voraussetzung zu einer langfristig erfolgreichen SOA darstellt. Dabei dürfen Herausforderungen auf der organisatorischen Ebene nicht unterschätzt werden. Durch die Verlagerung und Änderung von Verantwortlichkeiten in einem Unternehmen kann sehr schnell Konfliktpotenzial entstehen.
Eine erfolgreiche SOA-Governance muss alle Artefakte des SOA-Lebenszyklus nicht nur umfassen, sondern diese im wahrsten Sinne des Wortes regieren.
Markus Fiegler (info@ordix.de).
