SOA- Einführung

Transcrição

SOA- Einführung

Unter
Wie Sie mit SOA
www.soaadoptionfordummies.com
finden Sie viele weitere
Informationen
Ihre Geschäftsprobleme
lösen
Sie
erfahren:
Wie Sie mit SOA Geschäftsprobleme lösen
Wie Sie SOA-Baupläne
umsetzen
Mit diesem Buch
gelingt die SOA-Einführung!
Gegenstand dieses Buches ist nicht die Architektur selbst. Zu
diesem Thema gibt es mittlerweile genügend Literatur. In diesem
Buch geht es um die SOA-Einführung, um handfeste, praktische
Methoden, die Ihnen bei der Umsetzung Ihrer SOA-Pläne helfen.
Wir stellen Ihnen unser »SOA-Raumfahrtprogramm« vor.
So nennen wir unsere Methode, mit der wir Ihre SOA-Projekte
durch die Gefahrenzone steuern, eins nach dem anderen, ganz
behutsam – damit Sie Ihre Ziele sicher erreichen.
Fach-Chinesisch
Erklärungen ohne
m Ausprobieren
Tipps und Tricks zu
Symbolen
Durchblicken mit
melseite
Handliche Schum
Top-Ten-Listen
und Spaß
Eine Prise Humor
ISBN 978-0-470-48333-6
Nicht zum Verkauf
Wie Sie Richtlinien entwerfen, mit denen Sie das
Wachstum und die Nutzung
Ihrer Services steuern
SOAg
n
u
r
h
ü
Einf
ftware AG
Sonderausgabe So
Machen Sie
sich schlau!
Ihr Unternehmen
Flexibilität
www.fuer-dummies.de
Hier finden Sie alle
unsere Bücher
für Dummies
Wählen Sie aus vielen
verschiedenen
Themengebieten
Download von Probekapiteln, Inhalts- und
Stichwortverzeichnissen
Für Dummies®
Eine Marke von
So führen Sie
Kontrolle
Rendite
Organisation und Motivation
Miko Matsumura
Björn Brauel
Jignesh Shah
sicher zum Ziel!
9780470483336.indb 8
18.02.2009 11:05:43 Uhr
SOA-Einführung
FUR
DUmmiES
Â
Sonderausgabe Software AG
von Miko Matsumura, Björn Brauel
und Jignesh Shah
Übersetzung aus dem Englischen
von Ruth Simons
Wiley Publishing, Inc.
9780470483336.indb 1
18.02.2009 11:05:42 Uhr
SOA-Einführung für Dummies®, Sonderausgabe Software AG
1. Auflage 2009
© 2009 Wiley Publishing, Inc., Indianapolis, Indiana
Original English language edition Copyright © 2009 by Wiley Publishing, Inc.
All rights reserved including the right of reproduction in whole or in part in any
form. This translation is published by arrangement with John Wiley and Sons, Inc.
Copyright der englischsprachigen Originalausgabe © 2009 Wiley Publishing, Inc.
Alle Rechte vorbehalten inklusive des Rechtes auf Reproduktion im Ganzen oder in
Teilen und in jeglicher Form. Diese Übersetzung wird mit Genehmigung von John
Wiley and Sons, Inc. publiziert.
Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks
and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc.
and/or its affiliates, in the United States and other countries. Used by permission.
Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons,
Inc., USA, Deutschland und in anderen Ländern.
Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren
und Verlag für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler keine Haftung.
Printed in Germany
Gedruckt auf säurefreiem Papier
Satz Conrad und Lieselotte Neumann, München
Druck und Bindung M.P. Media-Print Informationstechnologie, Paderborn
ISBN: 978-0-470-48333-6
9780470483336.indb 2
18.02.2009 11:05:42 Uhr
Über die Autoren
Miko Matsumura ist Vice President und Deputy CTO bei Software AG. Er
war Gründungsvorstand des SOA Adoption Blueprints Technical Committee von Oasis und Organisator der SOA Link Interoperability Initiative.
Matsumura ist ein international gefragter Redner zum Thema SOA und
führt einen Blog unter www.SOAcenter.com.
Bis zur Übernahme von Infravio durch webMethods war Matsumura bei
Infravio als Vice President verantwortlich für Marketing und strategische
Planung. Matsumura trat in der Branche zum ersten Mal als Vordenker in
Erscheinung, als er bei The Middleware Company an einem Partnerprogramm für SOA Blueprints mitarbeitete und die erste herstellerneutrale
Spezifikation für SOA-Anwendungen erstellte, die von namhaften Herstellern wie BEA, Borland, HP, Microsoft, Oracle, Sun Microsystems, Veritas
und anderen unterstützt wurde. Bei Systinet arbeitete Matsumura in leitender Funktion mit an der Entwicklung von Produkten und der Erstellung
von Produkt- und Marketingstrategien. Außerdem vertrat er das Unternehmen bei Branchenveranstaltungen. Matsumura war Chief Java Evangelist bei Sun Microsystems und arbeitete eng mit Java-ISVs und Lizenznehmern zusammen, um die Java-Community weiterzuentwickeln.
Matsumura hat einen Master-of-Science-Abschluss der Yale University in
Neurowissenschaften und einen Master-of-Business-Administration-Abschluss der San Francisco State University.
Björn Brauel ist Vice President und Deputy CTO bei Software AG, dem
weltweit größten unabhängigen Anbieter von Infrastruktursoftware für
Geschäftsprozesse.
Brauel stellt die SOA-Strategie der Software AG auf Konferenzen, Messen,
Kundenveranstaltungen und Seminaren auf der ganzen Welt vor. Zu seinem Aufgabenbereich gehört es auch, gemeinsam mit Kunden, Communities und Analysten Technologietrends voranzutreiben, Strategien zur Umsetzung von Kundenwünschen zu entwickeln und zukünftige IT-Anforderungen zu analysieren. Brauel verfügt über fundierte Erfahrungen in Forschung und Entwicklung, Pre-Sales, Marketing und strategischer Produktplanung. Aufgrund dieser Erfahrungen besitzt Brauel ein ausgezeichnetes
technisches Wissen. Er genießt in der Branche eine hohe Anerkennung
als Redner, der einem Business-Publikum komplizierte technische Sachverhalte verständlich erklären kann und dem es dabei dennoch nicht an
der erforderlichen Präzision fehlt. In den letzten fünf Jahren hat sich
Brauel hauptsächlich auf die Themen serviceorientierte Architektur, Business Process Management und Integrationstechnologien mit XML und
Web Services konzentriert.
9780470483336.indb 3
18.02.2009 11:05:42 Uhr
Vor seiner Tätigkeit bei Software AG arbeitete Brauel über zehn Jahre für
die Open Source Community.
Jignesh Shah ist Vice President für SOA-Produktmanagement und -marketing bei Software AG. Er arbeitet eng mit Kunden auf der ganzen Welt zusammen und unterstützt sie bei der praktischen Umsetzung ihrer SOA-Projekte. Davor leitete Shah bei Paradigm die Einführung von OpsPlanner –
einer SaaS-Lösung (Software as a Service) für das Notfallmanagement. Er
war federführend beteiligt an Entwurf und Umsetzung diverser umfangreicher IT-Lösungen für Fortune-500-Kunden aus den unterschiedlichsten
Branchen (Hightech, Konsumgüter, Pharma, Fertigungsindustrie, öffent
liche Verwaltung).
Widmungen
Miko Matsumura: Für Lis und für Jackson, die Raketen ebenso lieben
wie ich.
Björn Brauel: Für meinen Vater, der mich gelehrt hat, unabhängig zu
denken.
Jignesh Shah: Für Aarti, die mich immer unterstützt hat. Für Maanav:
Wie du siehst, baut dein Vater auch gerne mit Klötzchen!
Danksagungen
Die Autoren danken Jim Fowler, der ihnen mit seinem Wissen über die Modernisierung von Legacy-Anwendungen mit SOA wertvolle Unterstützung
geleistet hat.
Der besondere Dank der Autoren gilt Claas Wallrodt, der ihnen dabei half,
alle Fäden in der Hand zu behalten.
Dank auch an Jim Bole und Garry Clarkson, beide sind echte »SOACracks«. Ivo Totev und Kevin Iaquinto danken die Autoren für ihr Vertrauen und ihre Unterstützung.
9780470483336.indb 4
18.02.2009 11:05:42 Uhr
Inhalt
Über die Autoren............................................................................................ 3
Widmungen..................................................................................................... 4
Danksagungen................................................................................................ 4
Einführung............................................................................................. 9
Über dieses Buch........................................................................................... 9
Symbole, die in diesem Buch verwendet werden...................................... 10
Kapitel 1: Flexibilität für das Unternehmen....................................11
SOA verstehen................................................................................................ 11
Alles über Services............................................................................ 11
Bausteine zusammenfügen.............................................................. 12
SOA dreht sich ums Geschäft....................................................................... 12
Den SOA-Bauplan lesen................................................................................. 13
Vollständige Abbildung der SOA-Implementierung...................... 14
Der Bauplan für die Organisation.................................................... 14
Den Bauplan umsetzen: Projekt für Projekt .................................. 15
Kapitel 2: Die zersiedelte IT-Landschaft . .......................................17
Ursachen der Zersiedelung........................................................................... 17
Die zersiedelte Systemlandschaft................................................................ 18
Schichten bestehender Systeme .................................................... 18
Unzugängliche Silos.......................................................................... 19
Verbindungsgestrüpp....................................................................... 20
Die zersiedelte IT-Organisation.................................................................... 20
Die Kräfte in der Organisation......................................................... 21
Gruppenkonflikte in IT-Organisationen.......................................... 23
SOA-Governance gegen die Zersiedelung................................................... 23
Integrierte Governance von Systemen und Organisation......................... 24
Kapitel 3: Den Bauplan der SOA erfüllen........................................25
Einigung über Richtlinien und Prozesse..................................................... 25
Das SOA-Kompetenzzentrum........................................................................ 26
Richtlinien und Prozesse automatisch einhalten...................................... 26
Richtlinien und Prozesse.................................................................. 27
9780470483336.indb 5
18.02.2009 11:05:42 Uhr
6 SOA-Einführung für Dummies
Richtlinien und Prozesse der Designphase.................................... 27
Richtlinien und Prozesse zur Laufzeit............................................ 28
Die Einhaltung von Richtlinien kontrollieren............................................. 30
Kapitel 4: Die Infrastruktur der Services . ......................................31
Neue Services erzeugen................................................................................ 31
Vorhandenes belassen und eine Serviceschicht einziehen ........ 32
Der Enterprise Service Bus als Bindeglied..................................... 33
Wrapper einsetzen............................................................................ 34
Service-Mediation.......................................................................................... 35
Services virtualisieren................................................................................... 36
Lose Kopplung................................................................................... 37
Service-Mediation mit dem Enterprise Service Bus..................... 39
Servicevermittlungsstellen beziehungsweise -Gateways............. 39
SOA-Appliances................................................................................. 40
Kapitel 5: Die Infrastruktur der Governance...................................41
Ein Registry/Repository nutzen................................................................... 41
Richtlinien verwalten........................................................................ 43
Das Registry/Repository als Kontrollpunkt der Designphase . .. 44
Das Prinzip des Lebenszyklus...................................................................... 45
Runtime-Management . ................................................................................. 46
On-boarding zwischen Nutzer und Service................................................ 48
Der Kreis schließt sich.................................................................................. 49
Kapitel 6: Services zusammensetzen (Composition).....................51
Voraussetzungen für Composition............................................................... 52
Business Process Management (BPM)........................................................ 52
Zusammengesetzte Anwendungen entwickeln.......................................... 53
Kapitel 7: Flexible Strukturen............................................................55
Machtkämpfe überwinden............................................................................ 56
Der SOA-Lebenszyklus................................................................................... 57
Anbieter- und Nutzer-Lebenszyklus............................................................ 58
Die Beteiligten definieren................................................................. 58
Abnahmen ......................................................................................... 59
Verträge aufsetzen............................................................................ 60
Die Entwicklung der SOA im Griff behalten................................................ 60
Ein Beispiel .................................................................................................... 61
Spannungen in der zentralen IT...................................................... 62
Spannungen zwischen Geschäftsbereich A und zentraler IT...... 63
9780470483336.indb 6
18.02.2009 11:05:42 Uhr
7
Misstrauen zwischen den Geschäftsbereichen ............................ 64
Spannungen zwischen den Beteiligten im Lebenszyklus ............ 64
Kapitel 8: Finanzierung der SOA ......................................................67
Überzeugende Argumente für SOA finden ............................................... 67
Der taktische Ansatz ........................................................................ 68
Der strategische Ansatz................................................................... 69
Der praktische Ansatz: BPM............................................................ 70
Die Organisation motivieren . ..................................................................... 70
Kapitel 9: Ihr erstes SOA-Projekt......................................................73
Ein SOA-Projekt aufsetzen............................................................................. 73
Mit den richtigen Services beginnen.............................................. 74
Neue Verbündete............................................................................... 75
Auf Kurs bleiben............................................................................................. 75
Die SOA-Tauglichkeit von IT-Projekten bewerten ........................ 75
Den ROI für die Abteilungen messen.............................................. 76
Richtlinien und Prozesse automatisieren................................................... 77
Langsam vorgehen ........................................................................... 77
Frühzeitige Einführung der Governance-Infrastruktur . ............. 77
Kapitel 10: Das SOA-Raumfahrtprogramm......................................79
Die Gesetze der Schwerkraft ....................................................................... 79
Vom SOA-Projekt zum SOA-Programm........................................... 79
In der Gefahrenzone . ....................................................................... 81
Auf Kurs bleiben............................................................................................. 81
Kennzahlen für den IT-Nutzen......................................................... 81
Kennzahlen für den geschäftlichen Nutzen .................................. 82
Leitlinien für den Organisationsbauplan........................................ 83
Leitlinien für den Architekturbauplan............................................ 83
Richtig motivieren . ......................................................................... 84
Die schwerelose SOA erreichen .................................................................. 86
Die Reichweite Ihrer SOA................................................................. 87
Austausch rund um SOA ................................................................. 87
Kapitel 11: Die SOA-Sterne erreichen.............................................89
Die Gefahrenzone überwinden..................................................................... 89
SOA-Fallstricke................................................................................... 89
Die lange Reise zu den SOA-Sternen............................................... 90
Schwerelosigkeit erleben ............................................................................. 91
Vorstoß in neue Galaxien.............................................................................. 91
9780470483336.indb 7
18.02.2009 11:05:43 Uhr
9780470483336.indb 8
18.02.2009 11:05:43 Uhr
Einführung
S
OA steht für serviceorientierte Architektur. Mithilfe einer SOA entwerfen Enterprise-Architekten sogenannte SOA-Baupläne (SOA Blueprints)
zur Umgestaltung von IT-Systemen und Organisationen. Die Umsetzung
dieser SOA-Baupläne heißt SOA-Einführung.
In diesem Buch beschreiben wir unseren Ansatz für die Einführung einer
SOA, den wir zur Veranschaulichung mit einem Raumfahrtprogramm vergleichen. Wie bei einem Raketenflug gibt es bei einer SOA-Einführung eine
Gefahrenzone, eine kritische Phase, bevor die SOA-Rakete die endgültige
Umlaufbahn in der Schwerelosigkeit des Weltraums erreicht hat. Wenn sie
das geschafft hat, kann eine SOA Ihr Unternehmen in eine neue Dimension
befördern. Bis es aber so weit ist, besteht immer die Gefahr, dass Ihre
SOA-Träume abstürzen und auf der Erde zerschellen.
Diese kritische Phase überwinden Sie, wenn Sie folgende Grundsätze beachten:
55 Halten Sie Ihre SOA-Rakete auf Kurs: Überprüfen und messen Sie
ständig Ihren Fortschritt; nehmen Sie gegebenenfalls Kurskorrekturen vor.
55 Motivieren Sie die Teams und Einzelspieler Ihrer SOA-Einführung.
55 Lassen Sie in Ihren Bemühungen nicht nach, bis Sie die Umlaufbahn
erreicht haben. Automatisieren Sie Ihre Prozesse so lange, bis die
SOA-Einführung zum Selbstläufer wird.
Über dieses Buch
Gegenstand dieses Buches ist nicht die Architektur selbst. Zu diesem Themenbereich gibt es mittlerweile genügend Literatur. In diesem Buch geht
es um die SOA-Einführung, um handfeste, praktische Methoden, die Ihnen
bei der Umsetzung Ihrer SOA-Pläne helfen.
SOA-Einführung für Dummies erklärt, worauf Sie bei Ihrem SOA-Programm
achten müssen und wie es Ihnen gelingt, Ihr Ziel nicht aus den Augen zu
verlieren. Alle Informationen zu einem Thema haben wir jeweils in einem
9780470483336.indb 9
18.02.2009 11:05:43 Uhr
Kapitel zusammengefasst. Wenn Sie sich zum ersten Mal mit SOA beschäftigen, sollten Sie das Buch Kapitel für Kapitel durcharbeiten. Wenn Sie bereits mit SOA vertraut sind, lesen Sie einfach die Informationen, die Sie suchen, im entsprechenden Kapitel nach. Wenn Sie also wissen wollen, wie
Sie ein SOA-Projekt finanzieren könnten, müssen Sie nicht das ganze Buch
lesen. Das Kapitel über die Finanzierung (Kapitel 8) ist auch für sich allein
verständlich und enthält alle relevanten Informationen zu dieser Frage.
Symbole, die in diesem Buch
verwendet werden
In diesem Buch finden Sie neben manchen Textpassagen Symbole, die Sie
auf bestimmte Informationen aufmerksam machen:
Wichtige Tipps, damit Ihre SOA-Einführung gelingt und die zeigen, wie
Ihre Anstrengungen die größte Wirkung erzielen.
Achtung, hier müssen Sie aufpassen, dass Ihnen kein Fehler unterläuft!
Hier wird es technisch; wenn Sie wenig Zeit haben, können Sie diese Hinweise später lesen.
Das sollten Sie sich auf alle Fälle merken.
9780470483336.indb 10
18.02.2009 11:05:45 Uhr
Kapitel 1
Flexibilität für das Unternehmen
In diesem Kapitel
00
Worum es bei SOA geht
00
SOA löst Geschäftsprobleme
00
Der SOA-Bauplan
S
OA (serviceorientierte Architektur) steht für eine bestimmte Sicht
auf die IT-Systeme, und SOA ist eine Methode, um einen SOA-Bauplan (SOA Blueprint) umzusetzen.
In diesem Kapitel wenden wir SOA-Prinzipien auf Geschäftsprobleme an
und erklären, wie man einen SOA-Bauplan pragmatisch umsetzt.
SOA verstehen
Aus der SOA-Perspektive betrachtet ist alles ein Service. Der Service ist
der kleinste Baustein einer SOA. Er ermöglicht es, auf immer wiederkehrende Geschäftsfunktionen zuzugreifen.
Alles über Services
Ganz grundsätzlich lässt sich ein SOA-Service dadurch definieren,
55 was er für Sie tut: Ein Service bietet einem Servicenutzer eine Funktion, zum Beispiel die Verarbeitung einer Adressenänderung für
einen Bankkunden.
55 wie Sie ihn einsetzen: Ein Service wird mit einer bestimmten Methode aufgerufen. Dieser Aufruf erfolgt über eine korrekt definierte
Schnittstelle, über die man auf die Servicefunktion zugreifen kann.
9780470483336.indb 11
18.02.2009 11:05:45 Uhr
Bei einem SOA-Service ist ausdrücklich nicht festgelegt,
55 wo sich der Service befindet: Services sind nicht räumlich gebunden, können also innerhalb eines Netzwerks von jedem Standort aus
aufgerufen werden.
55 wie er funktioniert: In einen Service kann man nicht hineinsehen.
Von außen ist nicht erkennbar, wie er funktioniert, und dieses Wissen ist für das Funktionieren auch nicht notwendig.
SOA-Services lassen sich zu anderen Services zusammensetzen. Reiht
man sie zu Sequenzen aneinander, entsteht ein Prozess.
Bausteine zusammenfügen
Eine SOA besteht aus Services, und zwar aus ganz vielen. Stellen Sie sich
eine riesige Star-Wars-Packung von Lego vor, mit 5000 Einzelteilen und
sämtlichen Figürchen. So ähnlich sieht eine SOA aus.
Die SOA definiert,
55 wie man einen Service findet,
55 wie verschiedene Services zusammenarbeiten,
55 wie jeder einzelne Service in das Gesamtsystem hineinpasst.
Durch das Lego-Prinzip braucht man nur die richtigen Bausteine aus
zusuchen und nach Anleitung zusammenzustecken.
Bei einer SOA findet man die Services in einem Verzeichnis, dem Registry.
Was Sie daraus zusammenbauen, nennt man eine zusammengesetzte Anwendung (Composite Application), und die Anleitung, nach der dies alles
geschieht, ist der SOA-Bauplan (SOA Blueprint).
SOA dreht sich ums Geschäft
Wenn SOA nur ein Thema für Computerfreaks wäre, wäre es nicht weiter
spannend für uns. SOA ist aber deshalb spannend, weil es technische
Funktionen in der Sprache der Business-Experten erklärt. Dadurch können Unternehmen diese technischen Funktionen schnell zu neuen Lösungen kombinieren.
Wenn sich IT-Architekten unterhalten, verwenden sie manchmal Fachbegriffe wie lose Kopplung oder grobe Granularität. Was bedeuten diese Fachbegriffe und warum sind sie für das Unternehmen relevant?
9780470483336.indb 12
18.02.2009 11:05:45 Uhr
Kapitel 1: Flexibilität für das Unternehmen 13
55 Granularität heißt so viel wie »Korngröße« und gibt an, wie groß die
Komponenten eines Systems sind. Eine SOA bevorzugt größere Komponenten, die man Business Services nennt. Diese bestehen meist
aus kleineren technischen Services, die bereits vorhanden waren.
Grobe Granularität ist wichtig, denn bei größeren Elementen fällt es
den Benutzern in den Fachabteilungen leichter, SOA-Services zu
verstehen, wiederzuverwenden und zu verwalten.
55 Schnittstelle versus Implementierung: Hier geht es um die Trennung zwischen dem, was ein Service tut, und dem, wie er es tut.
Diese Unterscheidung ist wichtig, weil SOA für den Benutzer in der
Fachabteilung dadurch einfacher wird. Er kann sich ganz darauf
konzentrieren, was der Service für ihn tut. Welche komplizierten
technischen Details dahinterstecken, braucht er gar nicht zu wissen.
55 Verträge (Contracts) halten fest, was der Servicenutzer vom Serviceanbieter erwarten darf. Hierzu gehören Aspekte wie Verfügbarkeit,
Zuverlässigkeit, Leistungskennzahlen, Kosten und Support.
Diese Verträge helfen den Benutzern in den Fachabteilungen zu entscheiden, auf welche Services sie sich verlassen wollen.
55 Lose Kopplung heißt, dass Services flexibel entworfen werden und
nicht starr voneinander abhängen. Dadurch lassen sie sich leichter
zusammensetzen (koppeln) und neu kombinieren.
Neue Geschäftslösungen entstehen viel schneller, wenn man sie aus
vorgefertigten Bauteilen zusammensetzt und nicht jede neue Geschäftsfunktion von Grund auf neu schreibt.
Den SOA-Bauplan lesen
Dieses Buch erklärt, wie man eine SOA einführt. Es ist keine Anleitung in
SOA-Design für SOA-Architekten. Aber auch SOA-Bauherren ohne spezielle Architekturkenntnisse müssen wissen, was zu einem SOA-Bauplan gehört und wie man ihn liest.
Das sollten Sie über einen SOA-Bauplan wissen:
55 Er zeigt das vollständig umgesetzte Endergebnis.
55 Er wird laufend angepasst.
Im Laufe Ihrer SOA-Einführung müssen Sie Ihre Rakete immer wieder neu
ausrichten, sonst kommen Sie vom Kurs ab. Wenn sich der Bauplan ändert, müssen Sie sich auf ein neues Ziel einstellen. An diesen Kurskorrekturen kommen Sie nicht vorbei, denn bei jedem Schritt in Richtung SOA
9780470483336.indb 13
18.02.2009 11:05:46 Uhr
wird klarer, was funktioniert und was nicht. Und diese Erkenntnisse können Sie nur dann nutzen, wenn sie in den SOA-Bauplan einfließen.
Vollständige Abbildung der
SOA-Implementierung
Der SOA-Bauplan sollte das angestrebte Endergebnis abbilden, also zeigen,
wie die gesamte SOA-Implementierung nach Fertigstellung aussieht. Der
Bauplan sollte die folgenden Dinge vollständig aufführen:
55 Business Services
55 Anforderungen an die Servicebeschreibung
55 Leistungskennzahlen der Services
55 Interoperabilitätsstandards
55 Datenschemata
55 Richtlinien
55 Anforderungen für das Auffinden und die Klassifizierung von
Services
Im Verlauf der weiteren Kapitel werden Sie noch besser verstehen, was
sich hinter diesen Elementen verbirgt.
Weitere Bestandteile des Bauplans sind
55 das Design der SOA-Infrastruktur: Auf diesem Plan sehen Sie alle
für die SOA erforderlichen Software- und Hardwarekomponenten.
Diese Komponenten werden in den Kapiteln 4 bis 6 ausführlicher
beschrieben.
55 der Entwicklungsfahrplan: Dieser Plan beschreibt Schritt für
Schritt, wie der gesamte Bauplan umgesetzt wird. Meistens entsteht
dieser Fahrplan im Laufe des Projekts.
55 der Bauplan für die Organisation: Er zeigt, wie die SOA-Organi
sation am Ende aussieht. Auf diesen organisatorischen Aspekt
wollen wir im nächsten Abschnitt etwas genauer eingehen.
Der Bauplan für die Organisation
Ein Architekturbauplan hilft bei der Umgestaltung von IT-Systemen, der
Bauplan für die Organisation unterstützt Sie bei der Umgestaltung Ihrer
IT-Organisation. Bei unserem SOA-Raumfahrtprogramm wird auf die organisatorischen Aspekte genauso viel Wert gelegt wie auf die technischen.
9780470483336.indb 14
18.02.2009 11:05:46 Uhr
Kapitel 1: Flexibilität für das Unternehmen 15
Ein Bauplan für die Organisation sollte die folgenden Fragen klären:
55 Know-how: Ist das nötige SOA-Know-how vorhanden?
55 Organisationsstruktur: Wie lassen sich die Beziehungen zwischen
Serviceanbietern und Servicenutzern transparent und verbindlich
gestalten?
55 Leitungsgremium: Wer definiert die Richtlinien und Prozesse der
SOA-Einführung? Welche Gruppen sollen in einem solchen Gremium
vertreten sein?
55 Anreize: Wie können Leistungsbeurteilungen, Prämien oder Beförderungen eingesetzt werden, um die SOA-Ziele zu erreichen?
55 Rollen und Zuständigkeiten: Wie müssen Stellenbezeichnungen,
-beschreibungen und Zuständigkeiten angepasst werden, damit sie
mit den Anforderungen der SOA in Einklang stehen?
55 Einheitliches Finanzierungsmodell für die Infrastruktur (Ausgleichszahlungen, Nutzungsgebühren): Wer bezahlt für Services
und Serviceänderungen?
55 Einheitliche Kennzahlen: Wie soll der Zustand der SOA gemessen
werden und an welchen Messwerten soll sich die IT-Organisation
orientieren?
55 Lebenszyklus: In welchen Schritten sollen das Design, der Ablauf,
die Wartung und die Außerbetriebsetzung der Services erfolgen?
55 Entwicklungsplan: Wie soll die schrittweise Umsetzung des Bauplans der Organisation ablaufen?
Ihren SOA-Bauplan sollte jeder kennen, werben Sie für ihn. Den Bauplan
der Organisation dagegen sollten Sie vertraulich behandeln, denn er kann
funktions- oder rollenspezifische Informationen über Kollegen und Mit
arbeiter enthalten.
Den Bauplan umsetzen:
Projekt für Projekt
Bei der Umsetzung der Baupläne für Architektur und Organisation gilt:
immer nur ein Projekt auf einmal. In Kapitel 10 gehen wir noch ausführ
licher auf diese Vorgehensweise ein.
Versuchen Sie nicht, den ganzen SOA-Bauplan in einem einzigen großen,
teuren und langwierigen Projekt umzusetzen. Teilen Sie das Ganze besser
in kleinere SOA-Projekte auf, die jedes für sich dem Unternehmen einen
eigenen Nutzen bieten.
9780470483336.indb 15
18.02.2009 11:05:47 Uhr
Jedes Projekt sollte einen Return on Investment (ROI) aufweisen, aber
auch als Anreiz für weitere Projekte dienen, die Sie auf Ihrem SOA-Weg
voranbringen. Je weiter Ihre SOA-Projekte umgesetzt werden, desto feiner
und automatisierter werden Ihre Implementierungsprozesse – so lange,
bis Ihre SOA den Zustand der »Schwerelosigkeit« erreicht hat.
9780470483336.indb 16
18.02.2009 11:05:47 Uhr
Kapitel 2
Die zersiedelte IT-Landschaft
In diesem Kapitel
00
Ursachen der Zersiedelung
00
Die zersiedelte Systemlandschaft
00
Die zersiedelte IT-Organisation
00
Die Zersiedelung Ihrer SOA verhindern
W
enn man das Wort Bauplan hört, könnte man meinen, eine SOA
ließe sich von Grund auf neu errichten. Dem ist leider nicht so,
denn wo Sie bauen wollen, haben sich schon Systeme und Organisationen
breitgemacht. Wenn eine Landschaft unkontrolliert mit Häusern und Straßen zugebaut wird, nennen die Stadtplaner das Zersiedelung. In der ITLandschaft gibt es dieses Phänomen auch. Wenn man etwas Neues aufbauen will, würde man die alten Gebäude natürlich am liebsten abreißen.
Wenn die Häuser aber noch bewohnt sind, ist das keine gute Idee.
Bei Ihren IT-Systemen ist es nicht anders: Wenn sie noch genutzt werden,
kann man sie nicht einfach abschaffen. Dieses Kapitel erklärt, wie es zur
allmählichen Zersiedelung der IT-Landschaft gekommen ist und wie SOAGovernance diesem Trend entgegenwirken kann.
Ursachen der Zersiedelung
Eine Systemlandschaft bietet heute oft das folgende Bild: Über die Jahre
hat sich System auf System gestapelt, hermetisch abgeschlossene Silos
quetschen sich nebeneinander, und obendrauf türmt sich ein Wust weiterer Systeme.
Auch die Organisationen haben einiges mitgemacht: Sie haben sich über
Landesgrenzen hinweg ausgebreitet, haben sich in Fusionen und Übernahmen ausgedehnt, wurden wieder zentralisiert und dann wieder aus
gelagert.
9780470483336.indb 17
18.02.2009 11:05:47 Uhr
Hinzu kommen politische Machtkämpfe, Verschleierungsmanöver, Feindseligkeiten und die Frustration über die IT, die das Unternehmen wiederholt enttäuscht hat – mit immer wieder verschobenen und letztlich gescheiterten Projekten, mit überzogenen Compliance-Anforderungen oder
mit Einschränkungen bei der Infrastruktur.
Viel Fantasie braucht man für diese Szenarien nicht. In den meisten Unternehmen sieht es so ähnlich aus.
Wir behandeln diese IT-Probleme deshalb, weil SOA sie lösen will. Aber
auch deshalb, weil diese Probleme eine SOA-Einführung ernsthaft gefährden können. Solange die bestehenden IT-Systeme und Organisationsstrukturen nicht wirklich verstanden werden, hat kein Reformversuch eine
Chance.
Die zersiedelte Systemlandschaft
Das Wuchern der IT-Systeme zeigt sich in dreierlei Form:
55 Undurchdringliche Schichten: bestehende Systeme, die historisch
gewachsen sind
55 Silos: redundante Systeme, die nicht aufeinander zugreifen können
55 Gestrüpp undurchsichtiger Verbindungen: schwer nachvollziehbare, punktuelle Integration
Im Folgenden wollen wir uns diese Phänomene genauer anschauen.
Schichten bestehender Systeme
Die Informationstechnologie besteht aus sich überlagernden Systemschichten. Darin befinden sich zum Beispiel selbst entwickelte Anwendungen, Mainframe-Systeme, Client-Server-Anwendungen oder ERP-Systeme, aber auch modernere Systeme wie Java Application Server.
Diese Überlagerung hat folgende Nachteile:
55 Änderungen dauern lange und sind riskant.
55 Eine Einzelperson ist nicht in der Lage, alle Systeme zu verstehen.
55 Die Logik teilt sich nicht auf sauber abgegrenzte Schichten auf.
55 Die Wartung der Systeme ist kostspielig.
55 Die verschiedenen Systeme können teilweise nicht miteinander kommunizieren.
9780470483336.indb 18
18.02.2009 11:05:47 Uhr
Kapitel 2: Die zersiedelte IT-Landschaft 19
All diese Systeme haben unterschiedliche Programmiersprachen, Leistungsmerkmale und Architekturen. Mainframe, Client-Server, Drei-Schichten-Modell und Internet – alles zusammen bildet ein großes, unübersichtliches Patchwork.
Beim Umgang mit den Schichten aus bestehenden Systemen hilft SOA, indem sie die vorhandenen Funktionen als Business Services bereitstellt.
Damit neue Services perfekt mit bereits bestehenden Services zusammenpassen, organisiert SOA den IT-Lebenszyklus von Projekten anders.
Manche stören sich daran, dass SOA auf alle bereits bestehenden Schichten noch eine Schicht legt. Wer will schon eine weitere Schicht? Der Einwand ist berechtigt, aber trotzdem werden Sie Ihre zugrunde liegenden
Systeme damit wesentlich leichter konsolidieren und rationalisieren.
Unzugängliche Silos
Das zweite Phänomen bestehender IT-Landschaften sind Silos (der englische Fachjargon sagt dazu auch stovepipes, also »Ofenrohre«). Silos sind
vertikal integrierte Datensysteme, die nicht auf Zusammenarbeit untereinander ausgelegt wurden. Wenn Unternehmen fusionieren, werden Funktionen häufig redundant und stellen dann Silos dar. Silos gibt es aber auch
dort, wo Geschäftsbereiche eigene IT-Budgets haben und niemand verhindert, dass in den einzelnen Geschäftsbereichen redundante Systeme entstehen.
Silos entstehen also in der Regel durch das Verhalten der Organisation.
Das ist zum Beispiel der Fall, wenn die Geschäftsbereiche getrennte Kundendatenbanken unterhalten. Bei einer solchen Konstellation muss für
eine Änderung von Kundendaten erst herausgefunden werden, wo sich
die Daten und die Logik befinden und wer die Hoheit darüber hat.
Beim Umgang mit Silos hilft SOA, indem sie die Zusammenarbeit (die Interoperabilität) zwischen den Systemen über Vereinbarungen regelt. Diese
Vereinbarungen legen fest, wie Systeme kommunizieren, welche Datenformate sie verwenden und wie organisatorische Hürden zu überwinden
sind. Die Interoperabilität zwischen Systemen und Daten ist technisch
zwar anspruchsvoll. Die größte Herausforderung einer SOA-Einführung ist
allerdings, überhaupt zu solchen Vereinbarungen zwischen Abteilungen
und Bereichen zu kommen und sie zur Zusammenarbeit zu bewegen. Dieses Thema wird in Kapitel 3 noch ausführlicher behandelt.
9780470483336.indb 19
18.02.2009 11:05:48 Uhr
Verbindungsgestrüpp
Punktuell erzeugte Integrationen, Anwendungen und Prozesse haben im
Laufe der Jahre ein undurchdringliches Gestrüpp gebildet. Nicht nachvollziehbare Abhängigkeiten können die IT vor erhebliche Probleme stellen,
denn wenn aufeinander bezogene Systeme abstürzen, kann es zu einem
regelrechten Dominoeffekt kommen.
Stellen Sie sich vor, bei Ihnen daheim stünden aus Rissen in Wänden und
Decken nackte Elektroleitungen hervor. Jedes Mal wenn Sie Licht oder das
Radio anmachen wollten, müssten Sie die passende Leitung suchen und
so lange auf gut Glück herumprobieren, bis Sie die richtige gefunden haben. Wie gefährlich das wäre, liegt auf der Hand.
Bei einem solchen Durcheinander gäbe es auch keine Möglichkeit, den
Stromverbrauch vernünftig zu messen und abzurechnen – ganz abgesehen davon, dass Sie und Ihre Familie einen Schlag bekommen könnten.
Eine falscher Griff, und im Zimmer, im Haus, in der Straße oder im ganzen
Stadtviertel würde der Strom ausfallen. Und Sie wüssten noch nicht einmal, welche der rätselhaften Verbindungen für den Stromausfall verantwortlich ist.
Dieser Vergleich klingt furchterregend, aber er passt durchaus auf die
aktuelle Situation der IT in Unternehmen. Grund für diese Entwicklung ist,
dass sich in der Unternehmens-IT immer ein isoliertes Projekt an das
andere reiht. Jedes Projekt will immer nur schnell und kostengünstig an
Daten herankommen, die Architektur ist dagegen zweitrangig. Die Folge
sind schlampige Architekturen.
Im Umgang mit diesem Gestrüpp hilft SOA, indem sie ein einheitliches
und geordnetes System schafft, in dem IT-Services gefunden, verknüpft
und genutzt werden können. Durch dieses Ordnungsprinzip bekommen
die Projekte die benötigten Funktionen, ohne dass Entwickler unkoordiniert herumbasteln und damit nur neues Gestrüpp produzieren.
Die zersiedelte IT-Organisation
IT-Organisationen sind ein bisschen wie Amöben, sie wachsen und verändern ihre Struktur unter unterschiedlichen Bedingungen. Sie ziehen sich
zusammen, dehnen sich aus und teilen sich, bilden Taschen in andere
Länder oder Spezialbereiche und schrumpfen dann wieder unter zentraler
Führung zusammen.
9780470483336.indb 20
18.02.2009 11:05:48 Uhr
Die Kräfte in der Organisation
Wie die Hardware- und Softwaresysteme gewachsen sind – nämlich organisch, sind es auch die IT-Organisationen. Dieses Stadium des natürlichen, chaotischen Wachstums zu überwinden ist ebenso Bestandteil der
SOA-Einführung wie die Arbeit mit Technologie. Die folgenden Organisa
tionsstrukturen sind dabei eine besondere Herausforderung:
55 Aufspaltung nach Funktion: Je reifer eine IT-Organisation wird,
desto mehr Spezialbereiche bekommt der Lebenszyklus der Sys
tementwicklung. Dieser Lebenszyklus ist sozusagen die Fertigungslinie für neue Software oder Services. An ihr sind unterschiedliche
Gruppen mit verschiedenen Aufgabenbereichen – Design, Programmierung, Einführung, Support, Wartung und Änderungen – beteiligt.
55 Aufspaltung nach Plattform: In IT-Organisationen gibt es häufig
Gruppenbildung durch die Spezialisierung auf Softwarepakete oder
Plattformen verschiedener Anbieter. Hier entstehen schnell feindliche Lager.
Die Java-Entwickler können nicht mit den Microsoft-.NET-Entwicklern, und die SAP-Leute mögen die Oracle-Leute nicht. Klar wäre das
Leben einfacher, wenn das Unternehmen einen einzigen Anbieter
zum Standard erklärte (und die Fans der anderen Anbieter einfach
entließe). So etwas ginge aber auch nur so lange gut, bis mit einer
Fusion oder Übernahme wieder Fans anderer Anbieter ins Haus kämen.
Hier besteht die Herausforderung für die SOA-Einführung darin, die
verschiedenen Lager über Interoperabilitätsvereinbarungen an einen Tisch zu bringen.
55 Aufspaltung nach bestehenden Systemen: Die Legacy-Systeme,
zum Beispiel Mainframes, kann man einfach als eine weitere Anbieterplattform betrachten. Wir erwähnen sie deshalb gesondert, weil
die Mitarbeiter, die diese Legacy-Systeme warten, zu einer anderen
Generation von IT-Fachleuten gehören.
Hier besteht die Herausforderung für die SOA-Einführung darin, den
Wert der Legacy-Systeme optimal auszuschöpfen und das Know-how
im Unternehmen zu halten, wenn die Fachkräfte in den Ruhestand
gehen.
55 Aufspaltung nach Ländern: Wenn eine Organisation in ein neues
Land geht, entstehen dort neue Rechenzentren. IT-Organisationen
senken ihre Kosten gern durch Offshoring, die Verlagerung von
Tätigkeiten in Niedriglohnländer oder in Regionen, wo Spezialwissen
vorhanden ist.
9780470483336.indb 21
18.02.2009 11:05:48 Uhr
Hier besteht die Herausforderung für die SOA-Einführung darin, geografisch verteilte Teams zu koordinieren und dafür zu sorgen, dass
sie zwar gemeinsam, aber an verschiedenen Teilen desselben SOABauplans arbeiten.
55 Die Situation nach Fusionen und Übernahmen: Wenn ein Unternehmen ein anderes übernimmt, übernimmt es auch eine komplette ITOrganisation, die mit bestimmten Standardpaketen und Plattformen
arbeitet (für die sich das Unternehmen unter anderen Umständen
vielleicht nicht entschieden hätte).
Fachanwender der bestehenden Systeme weiter zu unterstützen,
Feindseligkeiten zwischen den Gruppen zu verhindern und gleichzeitig auf eine SOA-Welt hinzuarbeiten, in der gemeinsame Services
Redundanzen beseitigen und die Flexibilität erhöhen.
55 Die Invasion der Systemintegratoren: Je größer eine IT-Organisation wird, desto mehr Aufgaben werden von externen Dienstleistern
übernommen.
Fäden in der Hand zu behalten. Die Dienstleister leben davon, Ihre
Abhängigkeit von den Beratern zu vergrößern.
55 Die Aufspaltung nach Geschäftsbereichen: Große Organisationen
gliedern sich in Geschäftsbereiche, Ämter, Ministerien (in der öffentlichen Verwaltung), Abteilungen oder Niederlassungen mit jeweils
verschiedener Funktion. Die meisten Geschäftsbereiche haben ihre
eigene IT-Abteilung.
Hier besteht die Herausforderung für die SOA-Einführung darin, dass
die IT-Abteilungen um Budgets konkurrieren und eine gemeinsame
Nutzung von Ressourcen rundweg ablehnen. Genauso wenig können
sie es leiden, wenn ihnen von oben herab Standardrichtlinien und
-services verordnet werden. Sie spielen politische Spielchen, in denen ein anderer die Infrastruktur bezahlt, von der sie profitieren.
55 Zentralisierung: Wachstum bedeutet für IT-Organisationen oft die
Vergrößerung der zentralen IT-Abteilung. Die Motive dafür sind Kosteneffizienz und der Wunsch nach Einheitlichkeit. So braucht zum
Beispiel nicht jeder Bereich Vollzeitarchitekten für Sicherheitsfragen
oder Enterprise-Architekten – und kann sie sich auch gar nicht leisten.
Hier besteht die Herausforderung für die SOA-Einführung darin, einen ausgewogenen Mix aus den Kosten- und Verwaltungsvorteilen
der zentralen IT und der Flexibilität der Bereichs-IT zu finden. Um
das zu erreichen, wendet SOA einen integrierten Governance-Ansatz
an.
9780470483336.indb 22
18.02.2009 11:05:48 Uhr
Gruppenkonflikte in
IT-Organisationen
Die Zersplitterung der IT-Fachkräfte in die oben genannten Kategorien
führt dazu, dass sich Gruppen bilden. Jede Gruppe repräsentiert sozusagen einen Anbieter, ein Land, einen Geschäftsbereich, ein Beratungsunternehmen und so weiter und tritt in Konkurrenz zu den anderen Gruppen.
Der natürliche Wunsch jeder Gruppe, sich gegen die anderen durchzusetzen, macht der IT großer Unternehmen zu schaffen. Wenn die unternehmensinternen Kräfte, die kontraproduktive IT-Strukturen wie Silos oder
Verbindungsgestrüpp erzeugen und aufrechterhalten, nicht identifiziert
und überwunden werden, hat kein technologischer Ansatz je eine Chance
auf Erfolg. Auf das Phänomen der Gruppenbildung gehen wir in Kapitel 7
noch ausführlicher ein.
SOA-Governance gegen
die Zersiedelung
Beim Wort Governance, das zu Deutsch »Führung« oder »Steuerung« bedeutet, denken viele an lästige Bürokratie und Beschlüsse am grünen
Tisch, die jede Kreativität und Flexibilität im Keim ersticken. Natürlich
können Sie Ihre SOA-Governance diktatorisch und kreativitätsfeindlich
ausüben, aber das dürfte zu großem Widerstand gegen die SOA führen
und jeden Fortschritt verhindern.
Wir propagieren einen Governance-Ansatz, der auf Vereinbarungen zwischen den verschiedenen IT-Interessengruppen setzt, alle Fortschritte genau dokumentiert und wenn notwendig Kursanpassungen vornimmt.
Wir halten nichts davon, wie Moses mit den zehn Geboten vom Berg zu
kommen. Wir bevorzugen eine Governance, die Schritt für Schritt neue
Richtlinien einführt, dann die Auswirkungen beobachtet und entsprechend korrigiert, damit die SOA-Einführung auf Kurs bleibt.
Governance ist kein Feind der Flexibilität. Im Gegenteil: Das Fehlen von
Governance, die Zersplitterung, ist der größte Feind der Flexibilität. SOAGovernance heißt im Grunde nichts anderes als Best Practices anzuwenden und damit die Zersplitterung (oder Zersiedelung, wie wir oben gesagt
haben) zu verhindern. Ein bisschen kluge Stadtplanung kann Sie auf dem
Weg zu Ihrer reibungslos funktionierenden »SOA-City« ein gutes Stück voranbringen.
9780470483336.indb 23
18.02.2009 11:05:49 Uhr
Integrierte Governance von Systemen
und Organisation
Die Zersiedelung der Systemlandschaft wird durch den Bauplan der SOA
behoben, die Zersiedelung der IT-Organisation durch den Bauplan für die
Organisation. Das klingt so, als seien das zwei völlig verschiedene Paar
Stiefel, stimmt’s?
Dem ist nicht so. Die Zersiedelung der Systeme und der Organisation bedingen sich gegenseitig. Chaotisch organisierte IT-Gruppen erzeugen und
pflegen chaotische IT-Systeme. Die Fans bestimmter Anbieter erzeugen
und verteidigen proprietäre Anbietersysteme und werden den Herstellern
gegenüber völlig unkritisch. Die IT-Fachleute der Geschäftsbereiche erstellen und verteidigen ihre Siloanwendungen. Die Entwickler der LegacyAnwendungen verteidigen schwer durchschaubare Systeme, um ihren Job
nicht zu verlieren. Die externen Dienstleister schaffen gegenseitige Abhängigkeiten, um Scharen von Beratern bei Ihnen unterzubringen.
IT-Mitarbeiter sind aber nicht auf den Kopf gefallen. Wenn sie scheinbar
unsinnige IT-Systeme erzeugen, schauen Sie noch mal hin. Jedes unsinnige System hat jemandem einen Nutzen gebracht – und höchstwahrscheinlich dem Rest des Unternehmens geschadet. Wenn man gegen die
Zersiedelung der IT-Systemlandschaft vorgehen will, muss man an den dafür verantwortlichen Strukturen ansetzen.
Das nächste Kapitel befasst sich zwar vor allem damit, wie der SOA-Bauplan Ihre Systemlandschaft in Ordnung bringt. Aber wir wissen natürlich,
dass IT-Systeme und IT-Organisation gleichzeitig in Ordnung gebracht
werden müssen. Dies ist ein wesentliches Prinzip unseres SOA-Raumfahrtprogramms, auf das wir in Kapitel 10 noch ausführlich eingehen.
9780470483336.indb 24
18.02.2009 11:05:49 Uhr
Kapitel 3
Den Bauplan der SOA erfüllen
In diesem Kapitel
00
Einigung über Richtlinien und Prozesse
00
Ein Kompetenzzentrum einrichten
00
Richtlinien und Prozessen automatisch anwenden
00
Die Einhaltung von Richtlinien kontrollieren
I
n diesem Kapitel wollen wir uns genauer anschauen, wie automatisch
eingehaltene IT-Richtlinien und -Prozesse verhindern können, dass
sich IT-Systeme unkontrolliert ausbreiten.
Kontrollpunkte, an denen die Einhaltung der Richtlinien geprüft wird, halten Sie auf Kurs und helfen Ihnen bei der Umsetzung des SOA-Bauplans.
Einigung über Richtlinien
und Prozesse
Unter Richtlinie (Policy) verstehen wir eine förmliche Erklärung, an der
sich künftige Entscheidungen und Handlungen orientieren sollen. Richtlinien und Prozesse helfen die SOA so zu implementieren, dass der SOABauplan am Ende auch erfüllt wird.
Jede Richtlinie schränkt den Freiraum einer bestimmten Gruppe ein und
nutzt einer anderen Gruppe (oder der Allgemeinheit). Niemand mag Vorschriften (vor allem Entwickler nicht), aber ein Mindestmaß an Disziplin
hilft Chaos zu vermeiden und bringt allen Beteiligten Vorteile.
Wenn eine Richtlinie den Handlungsspielraum einer Gruppe zugunsten
einer anderen beschränkt, müssen beide Gruppen den Sinn der Richtlinie
einsehen und ihr zustimmen. Sonst ist mit passivem Widerstand oder gar
offener Auflehnung gegen die Richtlinie zu rechnen.
9780470483336.indb 25
18.02.2009 11:05:49 Uhr
Das SOA-Kompetenzzentrum
Das Führungsgremium, das die SOA-Richtlinien erarbeitet und durchsetzt,
ist in der Regel das SOA-Kompetenzzentrum. Das SOA-Kompetenzzentrum
bringt die Vertreter aller Gruppen, die von den SOA-Plänen betroffen sind,
an einen Tisch.
Praktisch jeder Teil des SOA-Bauplans – zum Beispiel die Auswahl der
Services, ihre Definition und die Art ihrer Zusammenarbeit – gibt Ihrer Organisation unweigerlich Richtlinien vor. Deshalb muss das SOA-Kompetenzzentrum als erste Amtshandlung den Bauplan als gemeinsames Ziel
verabschieden.
Jede beteiligte Gruppe muss die Auswirkungen des SOA-Bauplans auf ihr
Tagesgeschäft begreifen und mit ihnen einverstanden sein. Deshalb sollte
die Verabschiedung des SOA-Bauplans ernst genommen und nicht einfach
durchgewinkt werden. Helfen Sie den einzelnen Gruppen, die Konsequenzen der SOA-Vision wirklich zu verstehen.
Richtlinien und Prozesse automatisch
einhalten
Manche Beteiligte fühlen sich in ihrer Freiheit und Kreativität vielleicht
beschnitten, wenn die Einhaltung der Richtlinien automatisiert wird. Nun,
in einer zivilisierten Gesellschaft können die Menschen tun und lassen,
was sie wollen, müssen sich aber an Regeln halten, damit sie anderen
nicht absichtlich oder unabsichtlich schaden. Stellen Sie sich Governance
deshalb am besten als eine Art Straßenverkehrsordnung vor.
55 Ein Mindestmaß an Verkehrsregeln macht die Straßen für alle sicherer. Mit ein paar Mautstationen verdient man Geld für den Erhalt der
Straßen, und mit Verkehrsmeldungen beugt man Staus vor.
55 Eine automatisierte Einhaltung der Regeln ist besser als eine manuelle: Hat das Auto einen Sender an Bord, braucht man nicht an der
Mautstation anzuhalten und nach Kleingeld zu kramen, sondern
kann einfach durchfahren.
Allerdings lassen sich nicht alle Richtlinien automatisieren. Manche
Schritte erfordern menschliches Abwägen und manuelle Eingriffe.
9780470483336.indb 26
18.02.2009 11:05:50 Uhr
Kapitel 3: Den Bauplan der SOA erfüllen 27
Richtlinien und Prozesse
Eine durchdachte SOA-Governance baut an verschiedenen Stellen des
Servicelebenszyklus Stationen ein und kontrolliert dort die Einhaltung der
Richtlinien. Um dieses Kontrollprinzip besser verständlich zu machen,
wollen wir die SOA-Richtlinien und -Prozesse etwas vereinfachend in zwei
Kategorien gliedern:
55 Governance-Richtlinien für die Designphase: Sorgen dafür, dass
SOA-Artefakte die Designanforderungen des SOA-Bauplans einhalten.
55 Governance-Richtlinien zur Laufzeit: Sorgen dafür, dass SOA-Services die Laufzeitanforderungen erfüllen, die zwischen Serviceanbieter
und Servicenutzer vereinbart wurden.
Mit diesen zwei Kategorien wollen wir uns im Folgenden etwas näher befassen.
Richtlinien und Prozesse der Designphase
Richtlinien für diese Phase gewährleisten, dass Services dem SOA-Bauplan entsprechend erstellt werden. Damit das Gesamtwerk SOA gelingt,
bekommen Servicedesigner und -entwickler Vorgaben zu folgenden Aspekten:
55 Interoperabilität: Der SOA-Bauplan legt ein einheitliches Verfahren
fest, das die Interoperabilität zwischen Services gewährleisten soll.
Hierfür werden meist mehrere Standards ausgewählt.
55 Auffindbarkeit: Damit man Services leichter findet, sind manchmal
Zusatzinformationen erforderlich, zum Beispiel eine anwenderfreundliche Beschreibung des Service und ein Hinweis, wo sich der
Service im Registry befindet (das heißt eine Klassifizierung). Diese
Informationen kann man per Richtlinie definieren.
55 Sicherheit: Der SOA-Bauplan sollte einheitlich festlegen, mit welchem Verfahren eine serviceübergreifende Sicherheit gewährleistet
wird. Art und Parameter dieser Sicherheitsmaßnahmen lassen sich
per Richtlinie festlegen.
55 Eindeutigkeit: Neue Services sollten nicht so heißen wie bereits
vorhandene Services. Dies wird meist durch den Namensraum geregelt. Problematische Mehrdeutigkeiten lassen sich durch Richtlinien
vermeiden.
9780470483336.indb 27
18.02.2009 11:05:50 Uhr
55 Kompatible Schnittstellen: Damit Services genutzt werden können,
brauchen sie einen einheitlichen Aufrufmechanismus. Eine solche
standardisierte Schnittstelle lässt sich per Richtlinie definieren.
55 Kompatible Datenformate: Eine Möglichkeit, Wiederverwendung zu
gewährleisten, sind gemeinsame Datenformate (sogenannte Schemata). Damit wird sichergestellt, dass ein Service das Adressfeld
eines anderen Service korrekt verwenden kann, selbst wenn die Services ihre Daten unterschiedlich speichern. Gemeinsame Schemata
lassen sich mit Richtlinien festlegen.
55 Kennzahlen: Statistische Auswertungen und Berichte zu designrelevanten Aspekten kann man ebenfalls per Richtlinie definieren.
Die Prozesse der Designphase hängen meist eng mit dem Lebenszyklus
der Systementwicklung zusammen, der allmählich zum Lebenszyklus der
Serviceentwicklung wird. Auf dieses Thema gehen wir in Kapitel 7 noch
näher ein.
Wenn die Verständigung nicht klappt
Welche katastrophalen Folgen fehlende Interoperabilität haben kann, zeigt das Schicksal
der Marssonde Climate Orbiter. Sie stürzte ab, weil der Hersteller Lockheed Martin Daten
in der amerikanischen Maßeinheit Pounds of Force statt in der metrischen Maßeinheit
Newton übermittelte. Daraufhin verglühten 125 Millionen US-Dollar in der Marsatmosphäre.
Richtlinien und Prozesse zur Laufzeit
Laufzeitrichtlinien stoßen auf geringeren Widerstand als Designrichtlinien, denn sie schränken vor allem IT-Systeme ein, damit die Servicenutzer profitieren.
Die meisten Laufzeitrichtlinien sollen sicherstellen, dass sich Services
planmäßig verhalten (nämlich so, wie es der Servicenutzer erwartet).
Dies betrifft:
55 Service-Level-Agreements: Darin vereinbaren Serviceanbieter und -nutzer Leistungsmerkmale für den Service sowie
Kriterien zur Messung dieser Leistung.
55 Authentifizierung: Hier sollten sich Serviceanbieter und
-nutzer über folgende Fragen einigen: Wie weisen sich Servicenutzer aus? Welche Identitätsprüfungssysteme kommen
zum Einsatz? Werden Sicherheitstokens verwendet und
wenn ja, welche? All diese Fragen werden durch LaufzeitGovernance abgedeckt.
9780470483336.indb 28
18.02.2009 11:05:50 Uhr
Kapitel 3: Den Bauplan der SOA erfüllen 29
55 Autorisierung: Wie wird geprüft, ob ein Nutzer einen Service aufrufen darf?
55 Verschlüsselung: Wie schützen wir Nachrichten vor dem
Einblick Dritter?
55 Signaturen: Wie erkennen wir, dass Nachrichten von zugelassenen Serviceanbietern und -nutzern stammen und bei
der Übermittlung nicht manipuliert wurden?
55 Warnmeldungen und Benachrichtigung: An wen und nach
welchen Kriterien sollen Warnmeldungen herausgehen?
Warnmeldungen können sich auf fachliche oder technische
Dinge beziehen.
55 Kennzahlen: Laufzeit-KPIs und Messungen für die Entscheidungsfindung werden in Richtlinien festgehalten. Auf die
wichtige Frage, was gemessen werden soll, gehen wir in Kapitel 9 noch ausführlich ein.
Warum XML so nützlich ist
XML ist die Abkürzung für eXtensible Markup Language. XML-Dokumente und -Nachrichten enthalten in spitze Klammern gesetzte Kennungen (Tags) und ähneln darin der Internetsprache HTML.
XML muss in einer SOA nicht zwingend verwendet werden, eignet sich aufgrund folgender Eigenschaften aber hervorragend für SOA:
55 Interoperabilität: Mit XML können verschiedene Systeme leichter kommunizieren.
Dies liegt freilich auch daran, dass so viele Software- und Hardwarehersteller sich
für XML als Kommunikationsstandard entschieden haben.
55 Maschinenlesbarkeit: XML lässt sich so formulieren, dass es sowohl von Menschen
als auch von Computern gelesen werden kann. Dadurch können Serviceanbieter,
Servicenutzer und Kontrollinstanzen (Policy Enforcement Points, PEPs) miteinander
kommunizieren und die Einhaltung der Richtlinien gewährleisten.
Ein bestimmter XML-Dialekt wird bei der SOA-Implementierung besonders gern verwendet: Web Services. Web Services bieten für die Übermittlung von Nachrichten eine Standardstruktur namens SOAP und für die Beschreibung von Serviceschnittstellen einen
Standardmechanismus namens WSDL (Web Services Description Language). Dank WSDL
können Services in einem UDDI-Registry (Universal Description, Discovery and Integration) gefunden werden.
Web Services haben einen Mechanismus, mit dem man dem Empfänger eines Dokuments
oder einer Nachricht, aber auch einer zwischengeschalteten Kontrollinstanz, Anweisungen geben kann. Mit diesem Mechanismus lassen sich die Richtlinien und Prozesse
einer SOA einheitlich strukturieren.
9780470483336.indb 29
18.02.2009 11:05:51 Uhr
Laufzeitrichtlinien sind Vorschriften für IT-Operator und IT-Systeme, die
zugunsten der Servicenutzer getroffen werden. Laufzeitprozesse können
zum Beispiel Support-Anfragen oder Antworten auf Echtzeit-Warnmeldungen oder -Benachrichtigungen sein. Die Möglichkeit, flexibel auf neue
Laufzeiterfordernisse einzugehen, ist ein großer Vorteil von SOA.
Die Einhaltung von Richtlinien
kontrollieren
So wie der Zoll Pässe und Gepäck überprüft, benötigt auch SOA-Governance Kontrollinstanzen, um die Einhaltung der Vereinbarungen zwischen
Parteien zu überwachen.
Solche Kontrollinstanzen sind
55 das SOA-Registry/Repository: Es fungiert als Kontrollorgan für die
SOA-Richtlinien und -Prozesse der Designphase.
55 das SOA-Runtime-Management-System: Es kontrolliert die Einhaltung der SOA-Richtlinien und -Prozesse zur Laufzeit.
In Kapitel 5 werden wir genauer darauf eingehen, wie diese beiden Governance-Komponenten die Automatisierung von Richtlinien und Prozessen
unterstützen.
9780470483336.indb 30
18.02.2009 11:05:51 Uhr
Kapitel 4
Die Infrastruktur der Services
In diesem Kapitel
00
Neue Services erzeugen durch die Anbindung bestehender Funktionen (Service
Enablement)
00
Lose Kopplung von Services durch Service-Mediation
00
Flexibilität durch virtuelle Services
S
ervices sind das Lebenselixier der SOA. Der Geschäftsnutzen, der
aus den Services abgeleitet werden kann, liefert in unserem SOARaumfahrtprogramm den Treibstoff für den Flug ins All. Je mehr wiederverwendbare Services Ihre SOA bietet, desto mehr Treibstoff beziehungsweise Energie steht Ihnen zur Verfügung. Wenn Sie diese Energie dann
noch den richtigen Stellen zuführen, entsteht im Unternehmen eine Eigendynamik, die Sie immer weiter vorantreiben wird.
Wie bereits erwähnt, hat die Servicemedaille zwei Seiten: die Serviceschnittstelle und die Serviceimplementierung. Mit der Schnittstelle wird
festgelegt, welche Funktionalität der Service bietet. Mit der Implementierung wird bestimmt, auf welche Weise der Service diese Funktionalität erbringt. Es ist genau diese Trennung zwischen Schnittstelle und Implementierung, die SOA so leistungsfähig und flexibel macht. Wenn Sie diese
Trennung in Ihrer Infrastruktur bewerkstelligen, bekommt Ihre SOA richtig Schub.
Neue Services erzeugen
Ein Teil Ihrer Infrastruktur wird die Aufgabe haben, Services für die SOA
bereitzustellen beziehungsweise zu implementieren. Dafür gibt es Techniken und Werkzeuge. Aber aus welchem Grundmaterial sollen die Services
entstehen? Soll man jedes Mal wenn ein neuer Service gebraucht wird,
schnell etwas programmieren? Leidenschaftliche Entwickler fänden das
vielleicht reizvoll, aber es wäre extrem zeitaufwendig und teuer.
9780470483336.indb 31
18.02.2009 11:05:51 Uhr
Vorhandenes belassen und
eine Serviceschicht einziehen
Ihr Unternehmen besitzt und betreibt bereits Dutzende, wenn nicht gar
Hunderte von Anwendungen und Systemen. Dies ist ein reicher Fundus,
aus dem Sie schöpfen können:
55 Die Funktionen, die Ihre Services brauchen, sind bestimmt schon in
einem dieser Systeme vorhanden.
55 Bestehende Anwendungen sind bereits durchgetestet und haben
sich im Geschäftsalltag bewährt. Und wenn Services auf einem
bewährten System basieren, werden die Nutzer den Services eher
vertrauen.
55 Aus bestehenden Anwendungen Services zu erstellen ist erheblich
billiger und zeitsparender, als ganz neue serviceorientierte Anwendungen zu schreiben.
Sie brauchen Ihren Systembestand nicht komplett auszumustern und
durch serviceorientierte Anwendungen zu ersetzen. Sie können ihn einfach belassen und über eine Serviceschicht an die SOA anbinden. Mit den
richtigen Werkzeugen und dem richtigen Know-how lassen sich ihre bestehenden Anwendungen in kürzester Zeit als Services bereitstellen, und
Ihre SOA bekommt die nötige Dynamik. Damit schützen Sie auch die enormen Summen, die Ihr Unternehmen bereits in bestehende Anwendungen
investiert hat. Mit solchen praktischen Argumenten dürfte es ein Leichtes
sein, Ihre Vorgesetzten zu überzeugen.
In Ihren bestehenden Systemen befindet sich schon eine Menge brauchbarer IT-Funktionen. Konzentrieren Sie Ihre Kräfte darauf, eine Serviceschicht auf diese bestehenden Anwendungen zu legen.
Doch wie stellen Sie nun bestehende Funktionalität als Service bereit? Es
gibt zwei Kategorien von bestehenden Anwendungen:
55 Selbst entwickelte Anwendungen: Wer in den frühen Jahren der Informationstechnologie (von etwa 1950 bis 1970) neue IT-Funktionen
haben wollte, musste die Ärmel hochkrempeln und eigene Software
schreiben. Das Anwendungsportfolio Ihres Unternehmens dürfte
zum großen Teil aus selbst entwickelten Anwendungen bestehen,
die auf die speziellen Anforderungen Ihres Geschäfts zugeschnitten
sind und zentrale Abläufe unterstützen, zum Beispiel die Abwicklung
und Auslieferung von Bestellungen.
55 Anwendungspakete: IT-Abteilungen entwickeln zwar immer noch
individuelle Anwendungen, aber seit zwei Jahrzehnten kaufen Unternehmen auch Anwendungspakete dazu und passen sie an ihre
9780470483336.indb 32
18.02.2009 11:05:51 Uhr
Kapitel 4: Die Infrastruktur der Services 33
Bedürfnisse an. Der Kauf von Anwendungspaketen wurde so beliebt,
dass die meisten Großunternehmen inzwischen astronomische Summen für die Einrichtung und den Betrieb von ERP-, CRM- und anderen Standardsystemen ausgegeben haben.
Bei der Serviceanbindung solcher Anwendungen besteht das Problem darin, dass sie nicht auf Interoperabilität beziehungsweise die Einbindung in
eine SOA ausgelegt wurden, weil es so etwas damals noch nicht gab. Anwendungen, die vor Ende des letzten Jahrtausends entwickelt wurden, haben in der Regel noch keine XML-Schnittstelle, sondern Anwendungsprogrammierschnittstellen (APIs) für Standards und Protokolle wie RMI,
CORBA, COM, DCOM oder RPC, die man vor der Erfindung von XML verwendete. Das macht die Anbindung kompliziert. Und wenn die Anwendung noch nicht einmal eine geeignete API hat, muss man womöglich direkt in den zugrunde liegenden Datenspeicher hineingehen. Das macht
die Anbindung noch komplizierter. Aber zum Glück gibt es intelligente
Werkzeuge, mit denen Sie diese Systeme knacken und als Services bereitstellen können.
Der Enterprise Service Bus
als Bindeglied
Wenn die Anwendung, die Sie servicefähig machen wollen, eine Schnittstelle für die Kommunikation mit anderen Systemen besitzt, ist der Enterprise Service Bus (ESB) eine feine Sache. Mit einem guten ESB können Sie
XML-Services erzeugen, die mit diesen Schnittstellen kommunizieren:
55 Er unterstützt unterschiedliche Protokolle, vor allem so altmodische wie RPC. Ein guter ESB schirmt Sie nahezu völlig von den technischen Details der Protokollnutzung ab.
55 Er unterstützt verschiedene Kommunikationsmodi: Üblicherweise
kommuniziert ein ESB im Request-Reply-Modus mit einer Anwendung. Dabei schickt der ESB mithilfe eines Protokolls eine Anfrage
(Request) an die Anwendung, und die Anwendung antwortet (Reply)
sofort. Viele geschäftskritische Systeme arbeiten jedoch mit ausgeklügelten, nachrichtenorientierten Kommunikationsmodellen wie
Publish-and-Subscribe oder Fire-and-Forget. Ein guter ESB vereinfacht die Anbindung an Systeme mit ausgereiften Kommunikationsmodellen und kann bei Bedarf auch Modelle kombinieren.
55 Er unterstützt unterschiedliche Nachrichtenformate: Eine weitere
Stärke von ESBs ist die Fähigkeit, Nachrichten zwischen XML und
Anwendungssprachen hin und her zu übersetzen. Egal ob es sich dabei um MIME, reinen Text, Flat Files oder Klingon handelt – der ESB
9780470483336.indb 33
18.02.2009 11:05:52 Uhr
übernimmt sämtliche Übersetzungs- und Umwandlungsschritte von
und nach XML.
55 Adapter: Der ESB erledigt alle systemnahen Arbeiten, die für den
Zugang zu bestehenden Anwendungen notwendig sind. Trotzdem
fürchten sich viele vor den komplizierten Details und Schnittstellen
jeder einzelnen Anwendung. Keine Sorge: Es gibt hervorragende
ESBs, die mit gängigen und konsistenten Schnittstellen sämtliche
technischen Details des Anwendungszugangs von Ihnen fernhalten.
Diese Schnittstellen nennt man Adapter. Sie erleichtern den Serviceentwicklern die Arbeit und halten ihnen den Rücken frei für das Wesentliche – die Bereitstellung bestehender Funktionalität als Service.
Bei unseren Ausführungen zum Thema ESB krümmt sich vielleicht der
eine oder andere SOA-Spezialist. Wenn es Ihnen auch so geht, sind Sie
möglicherweise ein Verfechter der klassischen Rolle des ESB. Danach ist
der ESB zentraler Bestandteil der SOA-Infrastruktur und sitzt zwischen
den Serviceanbietern und den Servicenutzern. Die Services selbst befinden sich nicht auf dem Bus. Eine solche Infrastruktur halten wir ebenfalls
für unabdingbar. Im Abschnitt »Service-Mediation« weiter hinten in diesem Kapitel gehen wir ausführlicher darauf ein. Allerdings sind wir nicht
der Ansicht, dass nur Produkte, die sich ESB nennen, die Rolle dieses
Teils der Infrastruktur übernehmen können.
Inzwischen bezeichnen sich viele Produkte als ESB. Sie unterscheiden
sich in puncto Funktionalität und Anwendung jedoch stark voneinander.
In dieser Produktkategorie tummelt sich heute alles, vom Datenmanagement über Human Workflow bis hin zur Event-Verarbeitung. Es würde uns
nicht wundern, wenn SOA-Experten demnächst die Küchenspüle zum unverzichtbaren Bestandteil des ESB erklären! Sie brauchen das ESB-Segment jetzt aber nicht zu durchforsten, um die echten ESBs von den Möchtegern-ESBs unterscheiden zu können. Die Produktkategorie ist unerheblich. Viel wichtiger ist, dass Sie Ihre Anforderungen kennen und dafür ein
passendes Produkt finden. Wenn Sie Serviceanbindung gewährleisten wollen, empfehlen wir einen ESB mit den oben genannten Fähigkeiten.
Wrapper einsetzen
Über ESBs können Serviceentwickler ganz leicht an Anwendungsschnittstellen andocken, ganz egal, welches Protokoll und welche Nachrichtenformate im Spiel sind. Allerdings hat bei Weitem nicht jede Anwendung
eine solche Schnittstelle. Manche sind verschlossen wie eine Auster. Um
da hineinzukommen, braucht man pfiffige Technologien, die oft als Wrapper bezeichnet werden.
9780470483336.indb 34
18.02.2009 11:05:52 Uhr
Wrapper sind in der Lage, sich Zutritt zu einer laufenden Anwendung zu
verschaffen oder sich in interne Programme oder Funktionsaufrufe einzuklinken, um diese dann als Services bereitzustellen. Das muss man sich
ähnlich vorstellen wie im Science-Fiction-Film »Alien«, in dem Außerirdische in den menschlichen Körper eindringen, das Nervensystem entern
und die Menschen manipulieren. Wrapper funktionieren ähnlich, aber
zum Glück ohne jede gruselige Absicht. Technisch kommt es einem wie
Zauberei vor, aber Wrapper funktionieren wirklich. Es gibt sie für unterschiedlichste Plattformen, von C und C++ bis zu Mainframe-Systemen und
-Sprachen wie COBOL oder Natural.
Um Wrapper auf Funktionen anwenden zu können, muss es allerdings jemanden geben, der das Innenleben der Anwendung kennt und entscheiden kann, an welchen Stellen der Wrapper aktiv werden soll. Manche Anwendungen sind leider so alt, dass niemand mehr weiß, wie sie genau
funktionieren. Sie sind eine regelrechte Blackbox, die niemand versteht
und an die sich niemand herantraut. Wenn Sie vor einer solchen Blackbox
stehen, funktioniert die Anbindung nur noch über den Bildschirm. Selbst
wenn niemand mehr das Innenleben eines Mainframe-Programms kennt,
weiß einer Ihrer Fachleute sicher noch, wie die Anwendungsbildschirme
funktionieren, das heißt welchen Input sie brauchen und welchen Output
sie geben. Mit diesem Wissen und einem Screen Scraper wird es Ihnen gelingen, die Anwendungsbildschirme in Services für Ihre SOA umzuwandeln.
Bei der Umwandlung bestehender Anwendungen zu Services können Sie
die Granularität, die dabei herauskommt, nicht immer beeinflussen. Oft
gibt schon die Art und Weise, mit der ein Prozess in der Anwendung umgesetzt ist, die Granularität des Service vor. Das hängt ganz davon ab, wie
die Anwendung seinerzeit entworfen und programmiert wurde. Deshalb
ist es durchaus möglich, dass in den zentralen Anwendungen hervorragende Prozesse vorhanden sind, die sich aber einfach nicht zu handlichen
Services umwandeln lassen. Das ist natürlich frustrierend, aber daran
können Sie leider nicht viel ändern.
Service-Mediation
In der Liebe wirkt Abstand manchmal Wunder, in der SOA eigentlich immer: Dort kommt es auf den richtigen Abstand zwischen Serviceanbietern
und Servicenutzern an. Zwischen Menschen, die in Unternehmen zusammenarbeiten und die Services anbieten oder nutzen, darf und soll es enge
Beziehungen geben. Aber wenn Systeme Services anbieten oder nutzen,
empfehlen wir Distanz. Serviceanbieter und Servicenutzer sollten lose
gekoppelt sein, damit sich jeder in gewissem Umfang verändern und ent-
9780470483336.indb 35
18.02.2009 11:05:53 Uhr
wickeln kann. Erreicht wird diese lose Kopplung durch die Service-Mediation-Schicht der Serviceinfrastruktur. Hier befindet sich die Serviceschnittstelle. Die Service-Mediation-Schicht erlaubt den Kontakt zwischen
Serviceanbietern und Servicenutzern, hält sie aber gleichzeitig auf gesunder Distanz.
Damit die SOA möglichst flexibel bleibt, sollten Servicenutzer nie direkt
auf die Serviceimplementierung zugreifen, die sich in der Anbindungsschicht (Service-Enablement Layer) befindet, sondern auf die Serviceschnittstelle, die in der separaten Service-Mediation-Schicht liegt.
Service-Mediation eignet sich aber auch ideal, um die Interoperabilität
zwischen Serviceanbietern und Servicenutzern zu verbessern. Da sämtliche Nachrichten die Service-Mediation-Komponenten durchlaufen müssen, kann man dort Nachrichten oder sogar das Protokoll so verändern,
dass sich die Kommunikationspartner auch wirklich verstehen.
Service-Mediation bietet außerdem eine zentrale Infrastruktur für die Implementierung von Betriebsanforderungen, die sich auf die Servicequalität (Quality of Service, QOS) auswirken, zum Beispiel auf Sicherheit und
Performance. Wenn solche Anforderungen von der Logik der Serviceimplementierung abgekoppelt sind, können sich Entwickler ganz auf die
fachliche Logik konzentrieren. Auch die Serviceentwicklung wird kostengünstiger, denn wenn man QOS-Anforderungen ändern kann, ohne den
Service selbst zu ändern, lassen sich Services einfacher wiederverwenden.
Kurzum, Service-Mediation ist bei der SOA-Einführung von unschätzbarem Wert. Der ROI (Return on Investment) der Serviceentwicklung steigt,
und die SOA kann sich ohne große Brüche weiterentwickeln.
Services virtualisieren
Service-Mediation gelingt mithilfe virtueller Services. Ein virtueller Service ist nicht der Service selbst, sondern nur ein Stellvertreter (Proxy).
Dieser Stellvertreter liegt in der Service-Mediation-Schicht und bietet sich
den Servicenutzern als Schnittstelle zum gewünschten Service dar. Die
Servicenutzer rufen den Stellvertreter auf, dieser dreht sich um und
reicht die Nachrichten an den eigentlichen Service – also dessen Implementierung – weiter (siehe Abbildung 4.1).
Durch solche virtuellen Services lassen sich Serviceschnittstelle und Serviceimplementierung trennen und auf zwei separate Schichten aufteilen.
Dadurch treten Servicenutzer und Serviceanbieter nie in direkten
Kontakt.
9780470483336.indb 36
18.02.2009 11:05:53 Uhr
Kapitel 4: Die Infrastruktur der Services Servicenutzer
ServiceMediation
37
Serviceanbieter
Abbildung 4.1: Virtueller Service
Lose Kopplung
Durch Service-Mediation erreichen Sie eine Flexibilität, die Sie mit fortschreitender SOA-Einführung immer stärker brauchen werden. Diese Flexibilität beruht darauf, dass virtuelle Services die Kopplung zwischen Serviceanbieter und Serviceverbraucher lockern, und zwar im Hinblick auf
den Ort, das Transportmittel und die Nachricht.
Unabhängigkeit vom Ort
Mit einem virtuellen Service brauchen Sie den Servicenutzern nicht zu
verraten, an welchem Ort sich der eigentliche Service befindet. Dadurch
können Sie die Serviceimplementierung frei verlagern, ohne die Serviceleistung zu unterbrechen. Bei steigender Nachfrage nach einem Service
kann seine Implementierung zum Beispiel auf einen Hochleistungsserver
verlagert werden.
Unabhängigkeit vom Transportmittel
Durch Virtualisierung lässt sich eine Serviceimplementierung auf mehrere
Transportmittel verteilen. Damit kann man Lücken in der Interoperabilität
schließen und weitere Möglichkeiten der Wiederverwendung schaffen.
Nehmen wir einmal an, Sie haben einen Create-Order-Service implementiert, der ursprünglich über JMS angesteuert wurde. Dieser Service ist inzwischen sehr beliebt, und mehrere Nutzer möchten ihn in ihre eigenen
Anwendungen einbinden und die Create-Order-Funktionalität wiederverwenden. Der Haken ist jedoch, dass viele Servicenutzer nur das HTTPProtokoll unterstützen und mit dem Protokoll des Create-Order-Service
nicht kommunizieren können. Normalerweise müssten Sie jetzt eine weitere Implementierung des Service erzeugen, die HTTP unterstützt. Mit einer guten Service-Mediation-Technologie brauchen Sie das nicht. Sie können die Create-Order-Funktionalität einfach als virtuellen HTTP-Service
bereitstellen, ohne an der eigentlichen Serviceimplementierung etwas zu
ändern. Auf diese Weise wird das Problem der inkompatiblen Protokolle
transparent gelöst, und der Create-Order-Service wird einer neuen Nutzergruppe erschlossen.
9780470483336.indb 37
18.02.2009 11:05:54 Uhr
Unabhängigkeit von der Nachricht
Manchmal klappt die Kommunikation zwischen Servicenutzern und -anbietern nicht, weil die Serviceimplementierung XML-Nachrichten verlangt. Das kann zu Ungereimtheiten bei den Daten und der Semantik führen. Dies ist zum Beispiel der Fall, wenn neue Serviceversionen eingeführt
werden oder wenn Änderungen an XML-Schemata sich auf die Nachrichtenparameter auswirken. Servicenutzer sollten aber grundsätzlich das
Nachrichtenformat verwenden, das der Service erwartet. Wenn Dinge geändert werden, gelingt es nicht allen Servicenutzern, sofort mit den Änderungen zu arbeiten. In diesem Fall hilft Virtualisierung, denn damit lassen
sich Nachrichten so umwandeln, dass sowohl die Nutzer- als auch die Anbieterseite zufrieden ist.
Operationale Anforderungen
Virtuelle Services eignen sich hervorragend für die Umsetzung von operationalen oder qualitätsspezifischen Serviceanforderungen wie:
55 Nachrichtenvalidierung: Gewährleistet, dass XML-Nachrichten
wohlgeformt sind und den Erwartungen der Serviceschnittstelle entsprechen.
55 Authentifizierung und Autorisierung: Prüft die Identität des Servicenutzers und seine Berechtigung zum Aufruf eines Service.
55 Verschlüsselte und signierte Nachrichten: Nachrichtenentschlüsselung und Signaturprüfung.
55 Failover und Load Balancing: Gewährleistet ausreichende Kapazitäten zur Bewältigung des Transaktionsaufkommens und zur Sicherstellung der Serviceverfügbarkeit.
55 Routing von Nachrichten: Leitet Nachrichten inhalts- oder kontextbasiert an verschiedene Serviceimplementierungen.
55 Monitoring und Service-Level-Agreements (SLAs): Verfolgt Servicezustand und Serviceleistung; gewährleistet, dass Services die vereinbarten Leistungen (SLAs) auch erbringen.
Die oben aufgeführten Anforderungen ändern sich wesentlich häufiger als
die funktionale Logik eines Service. Wenn diese Anforderungen in einer
separaten Schicht bedient werden, kann man sie unabhängig von der Serviceimplementierung ändern. Das ist praktisch, denn Eingriffe in die Serviceimplementierung können teuer werden und zu Systemausfällen führen. Wenn Sie von einem Service virtuelle Versionen mit jeweils anderen
QOS-Merkmalen erstellen, steigern Sie seinen Wiederverwendungsgrad.
So lässt sich zum Beispiel für unternehmensinterne Nutzer ein virtueller
9780470483336.indb 38
18.02.2009 11:05:54 Uhr
Service erstellen, der HTTP-Authentifizierung erfordert, und für externe
Nutzer ein anderer virtueller Service, der XML-Verschlüsselung verlangt.
Der Service selbst wird dabei nie verändert. Stattdessen werden virtuelle
Services mit jeweils eigenen QOS-Richtlinien erzeugt. So kann man die
Servicebereitstellung an unterschiedliche Nutzergruppen anpassen.
Sehr vorteilhaft daran ist außerdem, dass die Anforderungen aller Ser
viceanbieter konsistent und mit einer einzigen Methode verwaltet werden
können. Dies hält die SOA überschaubar und senkt die Gesamtkosten für
die Entwicklung und Wartung der Services.
Service-Mediation mit dem Enterprise
Service Bus
Prinzipiell eignet sich ein ESB durchaus als Service-Mediation-Lösung. Ursprünglich war er auch als besonders flexible und skalierbare Lösung dafür gedacht. Allerdings werden unter dem Begriff ESB inzwischen ganz unterschiedliche Funktionalitäten zusammengefasst. Manche ESBs bieten
eine hervorragende Serviceanbindung, sind im Bereich Service-Mediation
aber eher schwach. Wenn Sie einen ESB in Ihre Service-Mediation-Infrastruktur integrieren wollen, sollte er unbedingt eine einfache und sofort
einsatzfähige Servicevirtualisierung bieten. Diese sollte sich über die Konfiguration einstellen lassen und möglichst keinen Programmieraufwand
erfordern.
Manche ESBs bieten sowohl Service-Mediation als auch Serviceanbindung. Dies kann von Vorteil sein: Wenn ein Produkt beide Funktionen abdeckt, können Sie Ihre Serviceinfrastruktur leichter umsetzen; außerdem
fallen geringere Betriebskosten an. Doch auch dann sollten Sie für jede
Schicht eine eigene Instanz des Produkts verwenden, damit die Trennung
von Serviceimplementierung und Serviceschnittstelle immer gewährleistet bleibt.
Servicevermittlungsstellen
beziehungsweise -Gateways
Viele Hersteller bieten als effektive Service-Mediation-Lösung unkomplizierte Servicevermittler oder -Gateways an. Service-Gateways dienen in
erster Linie der Servicevirtualisierung und sind meist nicht so erweiterungsfähig und programmierbar wie ein ESB. Dafür sind sie – vor allem für
SOA-Administratoren – in der Regel leichter zu installieren, zu betreiben
und zu warten.
9780470483336.indb 39
18.02.2009 11:05:54 Uhr
SOA-Appliances
SOA-Appliances sind eine besondere Spielart der Servicevermittlung, werden auf eigener Hardware verkauft und bieten ganz spezielle Eigenschaften und Vorteile:
55 Sie sind ein kompletter Hardware-Baustein, der sofort in Betrieb genommen werden kann.
55 Ihr eingebauter XML-Prozessor bewältigt große Volumina und anspruchsvolle XML-Verarbeitung wie zum Beispiel Verschlüsselung.
55 Sie unterstützen zahlreiche Sicherheitsstandards.
55 Sie schützen XML-Datenverkehr vor Manipulation und Ausspähung.
55 Sie komprimieren und dekomprimieren Nachrichten.
SOA-Appliances eignen sich hervorragend, um den Randbereich eines Unternehmensnetzwerks wirksam zu schützen. Dieser Randbereich ist in der
Regel die DMZ (demilitarisierte Zone). Hier befinden sich die Systeme, die
Kunden und Partner außerhalb des Unternehmens bedienen. Aber auch
Netzwerkgrenzen zwischen Rechenzentren, die über ein WAN verbunden
sind, können dem Randbereich zugeordnet werden. Der Einsatz von SOAAppliances lohnt sich in der Regel dann, wenn
55 Services an Nutzer außerhalb der Unternehmensfirewall bereitgestellt werden (B2B-Szenarien).
55 Servicenutzer und Serviceanbieter sich diesseits und jenseits von
Vertrauensgrenzen (Trust Boundaries) befinden, zum Beispiel bei
Behörden.
55 ein WAN vorliegt.
Eine Service-Mediation-Standardlösung lässt sich mit einer SOA-Appliance
sinnvoll ergänzen. Das Delegieren ressourcenhungriger XML-Verarbeitung
wie Schemavalidierung und Verschlüsselung an eine SOA-Appliance ist
eine gute Vorbereitung auf einen ESB und auf Servicevermittler.
9780470483336.indb 40
18.02.2009 11:05:54 Uhr
Kapitel 5
Die Infrastruktur der Governance
In diesem Kapitel
00
Die Rolle des Registry/Repository
00
Richtlinien kommunizieren und einhalten
00
Das Management der Lebenszyklen
B
ittet man SOA-Spezialisten um eine Definition von SOA, bekommt
man Antworten wie Sand am Meer. Fragt man nach SOA-Governance,
gilt das erst recht, denn das Thema wird kontrovers diskutiert. Zum Glück
sind sich aber alle einig darin, dass SOA-Governance eine wichtige
Voraussetzung für den Erfolg einer SOA ist. Governance betrifft jeden Teil
unseres SOA-Raumfahrtprogramms. In diesem Kapitel geht es aber vor
allem darum, wie Governance unsere Rakete selbst bei größten Turbulenzen auf Kurs hält.
Governance ist der gesamte Komplex aus Rollen, Richtlinien und Verfahren, die mit der Einführung einer SOA einhergehen. Mit der Implementierung der technischen Governance-Komponenten schaffen Sie die Infrastruktur, die diese Rollen, Richtlinien und Verfahren über die gesamte
SOA hinweg unterstützt.
Ein Registry/Repository nutzen
Weil man nur steuern und kontrollieren kann, was man auch sieht,
braucht Ihre SOA-Governance zuallererst ein gemeinsames Verzeichnis,
das allen Beteiligten Aufschluss über die für sie relevanten Elemente der
SOA gibt. Als Standard für dieses Verzeichnis hat sich das Registry/Repository durchgesetzt (manche sagen auch nur Repository dazu). Welche Informationen darin abgelegt werden, hängt ganz von Art, Umfang und Reife
Ihres Governance-Ansatzes ab. Für die meisten Unternehmen kann man
jedoch sagen, dass ein Registry/Repository Folgendes enthalten sollte:
9780470483336.indb 41
18.02.2009 11:05:54 Uhr
55 Die in der SOA verfügbaren Services sowie alle Metadaten, die zur
Katalogisierung, zum Auffinden und zur Nutzung von Services erforderlich sind. Servicemetadaten sind zum Beispiel Laufzeitinformationen über die allgemeine Performance eines Service.
55 Die mit den Services verbundenen SOA-Komponenten, zum Beispiel
XML-Schemata und BPEL-Prozesse
55 Die Organisationen, die Services bereitstellen (zum Beispiel Projekte, Abteilungen oder Geschäftsbereiche)
55 Die Anwendungen oder Systeme, die Services nutzen
55 Die Organisationen, die Services nutzen
55 Die Richtlinien, die das Verhalten der am SOA-Lebenszyklus beteiligten Personen und Systeme regeln
55 Die Vereinbarungen zwischen Serviceanbietern und Servicenutzern
55 Die Abhängigkeiten und Beziehungen zwischen allen oben genannten Elementen
SOA-Spezialisten sind sich über den Unterschied zwischen Registry und
Repository nicht immer einig. Registries werden meist der Laufzeitphase
und Repositories der Designphase zugeordnet. Diese Abgrenzung ist ein
bisschen willkürlich und rührt daher, wie sich die Produkte im SOA-Markt
entwickelt haben. Ein gutes Verzeichnis bedient beide Bereiche.
Da das Repository das Fundament Ihres Governance-Systems bilden wird,
sollten Sie bei der Auswahl einer Lösung auf folgende Eigenschaften achten:
55 Unterstützung verschiedener Beteiligter: Governance betrifft
immer mehrere Gruppen. Es reden viele Beteiligte mit, von den
Serviceentwicklern über die SOA-Administratoren bis zu den Sicherheitsarchitekten. Sie alle müssen das Repository als den einzigen,
verbindlichen Bezugsrahmen für den SOA-Bauplan und alle dazugehörenden Informationen anerkennen. Das Repository ist auf die
Bedürfnisse verschiedener Beteiligter ausgerichtet. Ein gutes Repository ist leicht zugänglich (zum Beispiel über einen Webbrowser)
und benutzerfreundlich. Es sollte sich an unterschiedliche Rollen
anpassen lassen, damit jeder Beteiligte genau das sieht, was für ihn
relevant ist.
55 Unterstützung heterogener Umgebungen: Ein gutes Repository
unterstützt alle technischen Plattformen Ihres Unternehmens, die
an der SOA beteiligt sind. Ohne diese Unterstützung werden Sie die
durchgängige Transparenz, die für eine effektive Governance erforderlich ist, kaum erreichen können.
9780470483336.indb 42
18.02.2009 11:05:55 Uhr
Kapitel 5: Die Infrastruktur der Governance 43
55 Anpassungs- und Erweiterungsfähigkeit: Unserer Erfahrung nach
wendet jedes Unternehmen Governance auf eigene Art und Weise
an, und jedes Unternehmen hat eigene Governance-Anforderungen.
Deshalb legt jedes Unternehmen andere Informationen in seinem
SOA-Verzeichnis ab. Das Repository sollte sich deshalb unkompliziert an den jeweiligen Informationsbedarf anpassen lassen.
Richtlinien verwalten
Eine wesentliche Aufgabe von SOA-Governance besteht darin, dafür zu
sorgen, dass Personen und Systeme sich auf eine bestimmte Art und
Weise verhalten. Deswegen müssen Sie Ihre Richtlinien klar kommunizieren. Anschließend müssen Sie diese Richtlinien über den ganzen SOA-Lebenszyklus hinweg konsequent einhalten.
Früher hätten SOA-Architekten solche Richtlinien in wochen- oder monatelanger Arbeit auf Hunderten von Seiten – die letztlich niemand gelesen
hätte – genauestens dokumentiert. Den Beteiligten klarzumachen, dass es
Richtlinien gab, war schon schwer. Noch schwerer war es, Änderungen an
diesen Richtlinien zu kommunizieren. Ein ganzes System manueller Prüfungen und Abnahmen sorgte dafür, dass auch jeder die neuesten Regeln
zur Kenntnis nahm und sich daran hielt. Diese Prüfungen wurden schnell
zum Engpass und verführten die Leute dazu, die Richtlinien zu umgehen.
Das ist natürlich das genaue Gegenteil dessen, was SOA-Governance will.
Doch zum Glück gibt es Lösungen für das Management von SOA-Richtlinien, sogenannte Policy-Management-Lösungen. Mit einer solchen Lösung
kann man
55 Richtlinien verständlich formulieren: Richtlinien können nach Bedarf unkompliziert definiert, geändert und wieder entfernt werden.
55 Richtlinien durchsetzen: Richtlinien werden automatisch auf den
gesamten SOA-Lebenszyklus angewendet. Die Teilnehmer werden
sofort informiert, wenn sie gegen Richtlinien verstoßen. Folgemaßnahmen können in einem solchen Fall automatisch eingeleitet werden.
Das Management von SOA-Richtlinien ist zentraler Bestandteil einer SOAGovernance-Lösung. Es bietet eine klare Orientierung in der Frage, was
mit dem SOA-Bauplan in Einklang steht, und schafft so die Voraussetzung
für eine gelungene SOA-Governance. Policy-Management-Lösungen sorgen
für Verbindlichkeit und konsistente Ergebnisse. Die Automatisierung von
Governance-Prozessen beseitigt Engpässe und ermöglicht es, bei fortschreitender SOA-Einführung immer mehr Services, Serviceanbieter und
Servicenutzer zu verwalten.
9780470483336.indb 43
18.02.2009 11:05:55 Uhr
Aber wie stellt man es an, dass Richtlinien automatisch eingehalten werden? Dazu braucht man Kontrollpunkte, die man sich wie Mautstationen
an der Autobahn vorstellen kann. An der Mautstation werden von den
durchfahrenden Fahrzeugen die Gebühren für die Benutzung der Autobahn kassiert. Kontrollpunkte für die Richtlinieneinhaltung sind ebenfalls
an geeigneten Stellen platziert und sorgen dafür, dass Governance-Richtlinien beachtet werden.
Das Registry/Repository als
Kontrollpunkt der Designphase
Das Registry/Repository eignet sich hervorragend als Kontrollinstanz,
denn alle Serviceartefakte müssen es auf ihrem Weg zur endgültigen Bereitstellung durchlaufen.
Wenn eine SOA-Komponente im Registry/Repository publiziert wird, kann
das System automatisch prüfen, ob sie die Architekturstandards des SOABauplans erfüllt.
Wird dann noch ein maschinenlesbarer Standard wie XML verwendet,
lässt sich die SOA-Komponente gleich nach der Publikation automatisch
auf Interoperabilität prüfen.
Mit dem Registry/Repository kann man alle Aspekte eines Service in die
gewünschten Bahnen lenken, also auch die Servicebeschreibung. So können Sie zum Beispiel per Richtlinie vorschreiben, dass publizierende Teilnehmer ihre Services mit einer hierarchischen Struktur (Taxonomie) klassifizieren müssen. Eine solche Anforderung macht Services leichter auffindbar. Genauso können Sie für jeden Service eine Begleitdokumentation
vorschreiben, die erläutert, wann und wie der Service zu verwenden ist.
Für diese Dokumentation können Sie außerdem festlegen, dass sie durch
Personen aus der Zielgruppe des betreffenden Service abgenommen werden muss.
Um die automatische Validierung von SOA-Artefakten zu erleichtern, wird
der SOA-Bauplan für viele Artefakte das XML-Format vorschreiben. Da
XML maschinenlesbar ist, kann das Registry/Repository XML-Komponenten automatisch validieren, sobald sie dort eingestellt werden.
Manche Richtlinien lassen sich aber nicht direkt über das Registry/Repository umsetzen, sondern erfordern das Handeln von Personen. Dies betrifft insbesondere den Abnahmeteil einer Richtlinie. So könnte eine
Richtlinie zum Beispiel vorschreiben: »Ohne Abnahme durch QA-Teamlei-
9780470483336.indb 44
18.02.2009 11:05:55 Uhr
ter Mayer wird kein Service publiziert.« Bei den meisten Registry/Repository-Produkten lassen sich solche Human-Workflow-Richtlinien definieren
und anwenden. Dieser Richtlinientyp spielt beim SOA-Lebenszyklus-Management, auf das wir weiter hinten eingehen werden, eine zentrale Rolle.
Das Prinzip des Lebenszyklus
Bei SOA-Governance stellt sich grundsätzlich die Frage, wann die Einhaltung von Richtlinien am besten kontrolliert werden soll. Nehmen wir einmal an, Herr Mayer publiziert einen Service im Registry/Repository. Muss
der Service zu diesem Zeitpunkt schon alle Richtlinien erfüllen? Wenn Sie
das vorschreiben, steht Herr Mayer unter großem Druck und muss alles
richtig gemacht haben, bevor er seinen Service herausgibt. Es bedeutet
aber auch, dass der Service bis zum Erreichen seiner Einsatzfähigkeit außerhalb des Governance-Systems bleibt. Nehmen wir weiter an, dass Herr
Mayer schließlich seinen Service publiziert, dass dieser aber leider immer noch ein paar Richtlinien nicht erfüllt. Jetzt ist Herr Mayer ziemlich
verärgert, weil er seinen Service noch einmal überarbeiten muss und
seine Deadline verpasst. Allmählich findet Herr Mayer, dass Governance
ihm nur Steine in den Weg legt und unnötige Bürokratie ist. Aber wie wäre
es, wenn Sie Herrn Mayer helfen und im gesamten Entstehungsprozess
immer wieder prüfen würden, ob sein Service die Richtlinien einhält?
Diese Unterstützung ist möglich, wenn Sie mit Lebenszyklen arbeiten.
Ein Lebenszyklus legt fest, welche Phasen ein Service als aktiver Bestandteil der SOA durchlaufen muss. Abbildung 5.1 zeigt, wie der Lebenszyklus
eines Service aussehen kann.
Business Owner
Antrag
Entwickler
Design
Entwicklung
SOA-Architekt
Operator
Test
Produktion
Qualitätsmanager
Abbildung 5.1: Lebenszyklus eines Service
Die Definition eines solchen Lebenszyklus gehört zu den wichtigsten
Governance-Maßnahmen überhaupt. Das Registry/Repository sollte Ihnen
ermöglichen, diesen Lebenszyklus explizit zu modellieren und zu über
wachen. Die meisten IT-Fachleute kennen das Prinzip des Lebenszyklus
9780470483336.indb 45
18.02.2009 11:05:56 Uhr
und wissen, dass man Prozesse damit einfach gliedern und überwachen
kann. Für SOA-Governance bietet ein Lebenszyklus außerdem den Vorteil,
dass man an den Übergängen zwischen den Phasen wunderbar Kontrollpunkte einbauen kann. Wenn Sie die Einhaltung der Richtlinien in jeder
Phase des Lebenszyklus kontrollieren, geben Sie frühzeitig die Richtung
an und vermeiden Ärger und Nachbesserungen.
Diese Verknüpfung von Lebenszyklus und Richtlinien schafft ein flexibles
Governance-System, das jede Form der Zusammenarbeit auf dem weiteren Weg fördert.
Auf diese Weise wird SOA-Governance harmonisch und einfach mit bestehenden Prozessen im Lebenszyklus in Einklang gebracht. Architekten und
SOA-Kompetenzzentren können das bestehende Projektmanagement und
die bestehenden Lebenszyklusprozesse übernehmen und Richtlinien darin einbetten. Diese automatisieren dann nach und nach den SOA-Lebenszyklus. Das fördert die Kooperationsbereitschaft der beteiligten Gruppen
und stärkt die Governance-Lösung in ihrer Funktion als SOA-Kommandozentrale.
Verschiedene Komponenten haben auch verschiedene Lebenszyklen. Der
Lebenszyklus eines XML-Schemas sieht mit Sicherheit anders aus als der
eines Service. Deshalb sollte Ihre Governance-Lösung zulassen, dass Sie
für jede Komponente den passenden Lebenszyklus definieren.
SOA stellt Ihr Qualitätsmanagement (QM) vor neue Herausforderungen.
Da sich in einer SOA und in den Beziehungen zwischen SOA-Komponenten ständig etwas ändert, stoßen herkömmliche Qualitätssicherungsmethoden vielleicht an ihre Grenzen. Bei der Änderung einer Komponente
müssen unter Umständen Dutzende anderer Komponenten und Systeme
neu getestet werden. Komponenten werden wiederverwendet, also müssen vielleicht sogar sämtliche Wechselwirkungen getestet werden, und
zwar nicht nur mit Einzeltests. Dies können Sie lösen, indem Sie in einer
geeigneten Phase des Lebenszyklus eine Richtlinienkontrolle einbauen,
die dafür sorgt, dass alle Test- und Validierungskriterien der SOA erfüllt
werden. Eine solche Kontrolle sollte möglichst komplett automatisiert
sein, damit die Lebenszyklusphasen vor der Produktion automatisch QMErgebnisse mit dem QM-System abgleichen und eine Zusammenfassung
der QM-Ergebnisse im Registry/Repository ablegen, wo sie von den Beteiligten eingesehen werden kann.
Runtime-Management
Während der Lebenszyklus des Service im Repository überwacht und
verwaltet werden kann, erfolgt der tatsächliche Aufruf des Service außer-
9780470483336.indb 46
18.02.2009 11:05:57 Uhr
halb des Repository, nämlich zur Laufzeit und in der Serviceinfrastruktur.
(Vergleichen Sie hierzu auch den Abschnitt über Laufzeitrichtlinien in Kapitel 3.) Einige der wichtigsten Governance-Richtlinien müssen beim Serviceaufruf zur Laufzeit überwacht werden. Aber auch die Vereinbarungen
zwischen Serviceanbietern und Servicenutzern gilt es zur Laufzeit umzusetzen und zu verfolgen.
Wie lässt sich die automatische Einhaltung von Laufzeitrichtlinien in der
SOA bewerkstelligen? Dies gelingt mit einem Kontrollpunkt, der die Richtlinieneinhaltung zur Laufzeit überwacht. Diesen Policy Enforcement Point
(abgekürzt PEP) muss man sich vorstellen wie eine Mautstation an einer
gebührenpflichtigen SOA-Straße (siehe Abbildung 5.2). In unserem Fall befindet sich die Mautstation auf der Zufahrt zu einem Service, das heißt im
Netzwerk zwischen dem Serviceanbieter und dem Servicenutzer. Hier hat
der PEP die Möglichkeit, Nachrichten zwischen Anbieter und Nutzer auf
Richtlinienkonformität zu prüfen.
SOA-Governance zur Laufzeit erfolgt über den Laufzeit-PEP (Policy
Enforcement Point) der SOA. Dieser prüft SOA-Nachrichten beim Serviceaufruf.
Anfrage
Antwort
Servicenutzer
Broker
Serviceanbieter
Abbildung 5.2: Richtlinieneinhaltung zur Laufzeit
Wir verwenden den unspezifischen Begriff Policy Enforcement Point (PEP)
deshalb, weil die Kontrollfunktion in der Praxis von verschiedenen Systemen übernommen werden kann. Ein hervorragender Ort für Laufzeit-PEPs
ist die Service-Mediation-Schicht der SOA-Infrastruktur (mehr über Service-Mediation finden Sie in Kapitel 4). Die Service-Mediation-Komponenten sitzen zwischen Serviceanbietern und Servicenutzern und bilden eine
zentrale Infrastruktur, in der operationale Anforderungen wie Sicherheit
oder Nachrichtenversand umgesetzt werden. Viele dieser operationalen
Anforderungen fallen ebenfalls unter die Laufzeit-Governance und sollten
mit Richtlinien geregelt werden. Die Richtlinienkontrolle in der MediationSchicht hat den Vorteil, dass Richtlinien einheitlich angewendet werden,
ganz unabhängig davon, wo sich Serviceanbieter und Servicenutzer befin-
9780470483336.indb 47
18.02.2009 11:05:57 Uhr
den. Sie brauchen sich auch keine Gedanken zu machen, ob die verschiedenen Protokolle und Nachrichtenformate der Anbieter und Nutzer sich
verstehen. Die Mediation-Schicht kann mit dieser Vielfalt umgehen und
wendet Richtlinien durchgängig auf alle Nachrichten an, die zwischen Anbietern und Nutzern ausgetauscht werden. Und da Richtlinien deklarativ
und leicht änderbar sind, kann viel schneller auf neue operative Anforderungen reagiert werden.
Service-Mediation-Komponenten eignen sich hervorragend als Kontrollpunkte für die Richtlinieneinhaltung zur Laufzeit.
On-boarding zwischen
Nutzer und Service
Wenn ein Servicenutzer im Registry/Repository einen passenden Service
gefunden hat, verbindet er sich in einem entsprechenden Prozess (Onboarding) mit diesem Service. Dieser Prozess eignet sich ideal, um Laufzeitrichtlinien zwischen Serviceanbieter und Servicenutzer zu vereinbaren.
Bevor sich die Nutzer mit dem Service verbinden, legen sie in einem Service-Level-Agreement (SLA) Authentifizierungsregeln fest, damit der Ser
viceanbieter nur ihnen Zugriff auf den Service gewährt. Um diese Verbindungsstelle vor Hackern zu schützen, werden meist auch Sicherheitsmaßnahmen vereinbart.
Diese Vereinbarungen werden in der Regel über das Registry/Repository
getroffen und dort als Vertrag (Contract) abgelegt. Dieser Vertrag legt die
speziellen Laufzeitrichtlinien fest, die für die jeweilige Beziehung zwischen Servicenutzer und Service gelten sollen. Wenn sich der Nutzer mit
dem Service im Registry/Repository verbindet, erhält er die Adresse einer
virtuellen Schnittstelle dieses Service, die sich im Policy Enforcement
Point (PEP) befindet.
Die direkte Verbindung mit einem Service nennt man enge Kopplung. Bei
enger Kopplung ist es sehr schwer, einen angebotenen Service zu ändern.
Deshalb sollten Nutzer keine Möglichkeit bekommen, sich direkt an einen
Service zu koppeln. Sie sollten immer eine Schnittstelle erhalten, die den
Service zur Laufzeit vertritt.
Auch hier ist die Service-Mediation-Schicht der ideale Ort, um verbindliche Richtlinien und Vereinbarungen zur Laufzeit umzusetzen. Mit ServiceMediation-Komponenten ist die Erstellung von virtuellen beziehungsweise
Proxy-Services sehr einfach. Mit mehreren virtuellen Services lässt sich
9780470483336.indb 48
18.02.2009 11:05:58 Uhr
ein bestimmter Service je nach Nutzer individuell bereitstellen. Die Kombination aus Service-Mediation und Laufzeit-Governance fördert die Wiederverwendung und erlaubt es, flexibel mit ständigen Veränderungen umzugehen.
Der Kreis schließt sich
Eine clevere Governance-Lösung nutzt die Echtzeit-Transparenz, die die
Runtime-Management-Komponente verschafft, und leitet wertvolle Erkenntnisse in das Repository zurück. Die Integration zwischen RuntimeManagement-Lösung und Repository bietet vor allem folgende Vorteile:
55 Services werden automatisch gefunden und ebenso automatisch im
Repository publiziert.
55 Wechselbeziehungen zwischen Services und anderen Komponenten
zur Laufzeit werden erkannt und automatisch im Repository dokumentiert.
55 Servicenutzer werden erkannt und automatisch im Repository eingetragen.
55 Die Serviceperformance wird in aussagekräftigen Daten dokumentiert. Das erleichtert Governance-Entscheidungen.
55 Diskrepanzen zwischen Registry-Daten und dem tatsächlichen Laufzeitgeschehen werden erkannt und gemeldet (der Administrator
wird zum Beispiel gewarnt, wenn die WSDL eines Service, der in
einem Servicecontainer abläuft, nicht mit der WSDL im Repository
übereinstimmt).
55 Governance-relevante Ereignisse wie Richtlinien- oder SLA-Verstöße
werden im Repository festgehalten.
9780470483336.indb 49
18.02.2009 11:05:58 Uhr
9780470483336.indb 50
18.02.2009 11:05:58 Uhr
Kapitel 6
Services zusammensetzen
(Composition)
In diesem Kapitel
00
Voraussetzungen für Composition
00
Die Vorteile von Business Process Management (BPM)
00
Mit Composite Applications arbeiten
I
n den 60er- und 70er-Jahren des vorigen Jahrhunderts stellten Unternehmen Programmierer ein, die mit Programmiersprachen – zum Beispiel C oder COBOL – individuelle Anwendungen entwickelten. Dies war
zwar ein Fortschritt, doch dabei entstand eine große Zahl hoch spezialisierter Systeme mit hohen Wartungskosten.
In den 80er-Jahren stellten Softwarehersteller wie SAP dann fest, dass
man viele Funktionen, die Unternehmen routinemäßig in ihre individuellen Anwendungen einbauten, zu Paketen schnüren und verkaufen konnte.
Software einzukaufen ging deutlich schneller und war viel einfacher, als
selbst welche zu schreiben. Ohne Programmierung ging es aber trotzdem
nicht, denn die gekaufte Software musste noch an die individuellen Anforderungen der Unternehmen angepasst werden.
Mitte der 90er-Jahre besaßen die Unternehmen eine unhandliche Menge
von Standardpaketen und mussten parallel eine große Zahl von LegacySystemen unterhalten. So bunt diese Mischung war, so abhängig war man
von ihr geworden. Die Systeme waren aus dem Tagesgeschäft nicht mehr
wegzudenken, und ein Komplettaustausch oder eine Neuentwicklung
wäre viel zu teuer gewesen. Aber die Unternehmen fanden Möglichkeiten,
die Systeme enger zu integrieren und miteinander kommunizieren zu lassen. Diese Entwicklung führte schließlich zu SOA und Composition.
Mit SOA können Unternehmen in kürzester Zeit neue Anwendungen zusammensetzen und Geschäftsprozesse über verschiedene Systeme hinweg automatisieren. SOA strafft und optimiert Geschäftsabläufe und
9780470483336.indb 51
18.02.2009 11:05:59 Uhr
schützt gleichzeitig die hohen Summen, die Unternehmen bereits in Softwareanwendungen und -prozesse investiert haben. Das ist die Zukunft der
Composition.
Voraussetzungen für Composition
Composition ist die Grundlage für die größte Verheißung von SOA: Flexibilität. Wenn eine ausreichende Anzahl Services in Betrieb ist, kann man
ganz einfach neue Funktionen erstellen. Man braucht nur die richtigen
Services zusammenzusetzen. Und wenn sich im Unternehmen etwas ändert? Kein Problem. Man setzt die Services neu zusammen, bis die neue
Anforderung erfüllt wird. Eine verlockende Vorstellung, oder?
In der Praxis setzt Composition voraus, dass man die richtigen Services
und Abläufe definiert hat. Die Technologie, mit der die Services zu Funktionen verknüpft werden, muss fachlich orientiert sein. Und sie muss vor
allem schnelle Änderungen an Geschäftsanwendungen ermöglichen. Ob
Sie es glauben oder nicht: Solche Technologien gibt es tatsächlich.
Business Process Management
(BPM)
Innovative Unternehmen zeichnen sich nicht nur durch ihre Produkte aus.
Vielmehr bieten sie ihre Produkte und Services auch besonders effizient
an, erkennen Probleme und Chancen rechtzeitig und reagieren schnell. Im
Wettbewerb haben diejenigen die Nase vorn, die sich auf ihre Geschäftsprozesse konzentrieren.
Eine Business-Process-Management-Lösung stellt reale Geschäftsprozesse – zum Beispiel die Auftragsbearbeitung vom Eingang bis zur Zahlung oder die Schadenbearbeitung – in Form automatisierter IT-Funktionen bereit. Wenn man diese prozessorientierte Bereitstellung von IT-Funktionen mit SOA kombiniert, ergeben sich mehrere Vorteile:
55 Geschäftsprozesse werden in Teilschritte aufgespaltet, die man mit
wiederverwendbaren Services – zum Beispiel CheckCredit, Check
Inventory oder PlaceOrder – implementieren kann. BPM schafft
effektiv und fachlich orientiert Klarheit darüber, welche Services die
IT-Abteilung erstellen soll.
55 Wenn eine SOA vorhanden ist, kann man mit Services aus dem gesamten Unternehmen in kürzester Zeit Prozesse implementieren. Je
weiter die SOA-Einführung voranschreitet, desto mehr Services
9780470483336.indb 52
18.02.2009 11:05:59 Uhr
Kapitel 6: Services zusammensetzen (Composition) 53
stehen zur Verfügung und desto schneller geht die Automatisierung
neuer Geschäftsprozesse.
55 Mit einer BPM-Lösung wird die Definition von Geschäftsprozessen
grafisch unterstützt, was ähnlich aussieht wie ein Flussdiagramm.
Deshalb braucht man zum Erstellen oder Ändern eines Prozesses so
gut wie keine Programmierkenntnisse.
55 Wenn SOA-Services in einen BPM-Prozess eingebunden werden,
erhält man verschiedene Überwachungspunkte. Dort können Technologien wie Business Activity Monitoring Echtzeitanalysen durchführen und Kennzahlen zur Geschäftsperformance bereitstellen. Mit
diesen Informationen können Unternehmen ihre Prozesse analysieren und optimieren.
55 BPM verwendet eine Sprache, die sowohl IT-Fachleute als auch
Business-Experten verstehen. Dadurch betrachten beide Seiten den
Prozess aus einer gemeinsamen Warte.
Zusammengesetzte Anwendungen
entwickeln
Technologien für die Erstellung zusammengesetzter Anwendungen (Composite Applications) nutzen die Vorteile von SOA und eröffnen neue Möglichkeiten der Anwendungsentwicklung. Um eine neue Anwendung zu erstellen, verknüpft man lediglich bestimmte Services mit einer leistungsfähigen Benutzeroberfläche. Programmierkenntnisse braucht man so gut
wie keine. Stattdessen kommen neue Hilfsmittel zum Einsatz, zum Beispiel
Portlets (kleine, in sich geschlossene Webanwendungen) und Mash-ups
(Anwendungskombinationen). Mit ihrer Hilfe werden Daten aus unterschiedlichen Quellen zu einer einzigen Anwendung zusammengesetzt.
Mit einer Kombination aus BPM und Technologien für zusammengesetzte
Anwendungen kann man für den manuellen Teil von Prozessen komfortable Benutzeroberflächen erstellen.
9780470483336.indb 53
18.02.2009 11:05:59 Uhr
9780470483336.indb 54
18.02.2009 11:05:59 Uhr
Kapitel 7
Flexible Strukturen
In diesem Kapitel
00
Strukturen und Verhalten in Organisationen
00
Der SOA-Lebenszyklus
00
Die unterschiedlichen SOA-Lebenszyklen
00
Die Weiterentwicklung der SOA im Griff behalten
00
Eine fiktive IT-Organisation als Beispiel
T
raditionell sind Unternehmen in Anwendungslandschaften struk
turiert. Daraus ergibt sich die Problematik, dass auch die Anforderungen an die IT im Unternehmen über diese Anwendungen definiert
werden. Für solche Unternehmen ist die Einführung einer SOA strukturell
eine Herausforderung. Um siloartiges Denken und Handeln aufzubrechen,
die Weichen auf Flexibilität zu stellen und erfolgreich eine SOA einzuführen, sind neue Strukturen und Prozesse notwendig. Diese Prozesse werden oft als SOA-Lebenszyklus bezeichnet. Kombiniert man sie mit der richtigen Organisationsstruktur, lassen sich Machtkämpfe zwischen den
Interessengruppen leicht verhindern.
Moderne IT-Abteilungen müssen ihrem Unternehmen unter hohem Druck
kostengünstig und pünktlich Lösungen bereitstellen. Hierfür setzen sie gemeinsam genutzte technische Komponenten und Strukturen ein, arbeiten
aber auch an projektübergreifenden Initiativen, um die Synergien zwischen
den Abteilungen zu stärken. Wenn Unternehmen diese Lösungen mit einer
Servicementalität kombinieren (wobei Service nicht technisch, sondern
als Dienstleistung gemeint ist), sind sie bereits auf dem Weg in Richtung
SOA.
Damit Sie Ihren individuellen Weg zur SOA finden, brauchen Sie das folgende Rüstzeug:
55 Die richtige Mentalität: Denken Sie in Wertschöpfungsketten und
verlieren Sie nie die Kundenzufriedenheit aus den Augen.
9780470483336.indb 55
18.02.2009 11:05:59 Uhr
55 Methodisches Vorgehen: Schauen Sie über den Tellerrand Ihrer Anwendungen hinaus und führen Sie projektübergreifend strukturierte
Prozesse (Lebenszyklen) ein.
55 Mitarbeiter und Strukturen: Erfüllen Sie Ihre SOA-Ziele, aber entwickeln Sie auch Ihr Unternehmen weiter, indem Sie Machtkämpfe
zwischen Interessengruppen überwinden.
55 Technologie: Richten Sie Ihre Technologie auf die Mentalität, die
Methoden und Mitarbeiter aus, damit diese Elemente harmonisch
ineinandergreifen. Konzeptionell gesehen macht Technologie nur
einen kleinen Teil von SOA aus.
Wenn Mentalität, Methoden, Mitarbeiter, Strukturen und Technologie richtig kombiniert werden, kann die SOA-Einführung einem Unternehmen zu
deutlich mehr Effizienz und Flexibilität verhelfen.
Machtkämpfe überwinden
Ab einer gewissen Größe bilden sich in jeder Organisation Gruppen, die
ihre Interessen gegen andere Gruppen durchsetzen wollen. Für diese Interessen kämpfen sie. Natürlich nicht im wörtlichen Sinn, zumindest wollen
wir das hoffen. Aber die Erfüllung eigener Bedürfnisse ist ihnen wichtiger,
als andere Gruppen oder die Gesamtorganisation zu unterstützen. Das gehört zum Wesen des Menschen und kann überall beobachtet werden.
Bei ihren Machtkämpfen wenden Interessengruppen oft folgende Strategien an:
55 Sie horten Unternehmensdaten: Wenn eine Gruppe die Hoheit über
Daten hat, lässt sie nur diejenigen darauf zugreifen, die ihr genehm
sind.
55 Sie halten Know-how zurück: Außerhalb der Gruppe darf niemand
erfahren, wie ein IT-System funktioniert, damit bestimmte Jobs nicht
gefährdet werden. Dies erschwert die Verwaltung und Wartung der
Systeme.
55 Sie kämpfen um Plattformen: Es wird versucht, die IT des ganzen
Unternehmens auf einen bevorzugten Anbieter oder eine bevorzugte
Entwicklungsumgebung auszurichten.
55 Sie kämpfen um Richtlinien und Prozesse: Andere Gruppen werden
gezwungen, die Richtlinien und Prozesse der eigenen Gruppe zu
übernehmen.
55 Sie kämpfen um Budgets und Personal: Der Kampf um finanzielle
oder personelle Ressourcen gehört in der IT leider zum Alltag.
9780470483336.indb 56
18.02.2009 11:06:00 Uhr
Kapitel 7: Flexible Strukturen 57
Die Winkelzüge der Interessengruppen machen anderen das Leben
schwer. IT-Gruppen halten sich oft über Wasser, indem sie Kosten und
schwierige Aufgaben an andere Organisationen auslagern, zum Beispiel
an Offshore Center. Diese arbeiten meist viel günstiger. Die Probleme werden durch die Verlagerung von einer Gruppe zur nächsten aber nicht beseitigt, und die Kosten, die durch diese Verlagerung entstehen, holen die
ursprünglichen Einsparungen wieder ein .
SOA beinhaltet viele Vorschläge, wie sich Organisationsstrukturen, Verhaltensweisen, Prozesse, Richtlinien und Systeme verbessern lassen. Diese
Veränderungen sind für manche Gruppen günstiger als für andere. Eine
gut konzipierte SOA-Einführung wird deshalb darauf achten, dass das gemeinsame Interesse aller immer oberste Maxime bleibt. Sonst verkommt
SOA zum Schauplatz für IT-Machtkämpfe.
Der SOA-Lebenszyklus
Der SOA-Lebenszyklus hilft den Beteiligten, effektiver zusammenzuarbeiten, und gibt der SOA-Einführung eine Struktur. Gleichzeitig lässt er dem
Einzelnen ausreichend Gestaltungsfreiheit und Verantwortung für seinen
Ausschnitt des Prozesses. Die Planung des SOA-Lebenszyklus ist ein wesentlicher Teil der SOA-Einführung.
Wenn Sie den SOA-Lebenszyklus umsetzen, müssen Sie Zuständigkeiten
aufteilen. Sie sollten auf keinen Fall neue, zentrale Verantwortungen schaffen. Ein übermäßig zentralisierter SOA-Lebenszyklus, der die Aktivitäten
der Gruppen bis ins Detail reglementieren will, wird nur Widerstand gegen
die SOA-Einführung hervorrufen.
Weil SOA auf die Harmonisierung von Komponenten, Services und Prozessen abzielt, beinhaltet der SOA-Lebenszyklus nicht nur technische Ser
vices, sondern auch
55 wiederverwendbare Komponenten: Nachrichten, Geschäftskomponenten und Geschäftsregeln
55 Prozesse: Geschäftsprozesse (BPM)
55 Benutzeroberflächen: Benutzerinteraktionen und Informa
tionsdarstellung
Der SOA-Lebenszyklus erstreckt sich nicht auf Code oder operationale
Komponenten wie Application Server oder Datenbanken. Um ein konsistentes Modell zu erhalten, müssen Sie die Lebenszyklen für Code und Systembetrieb mit den SOA-Plänen harmonisieren.
9780470483336.indb 57
18.02.2009 11:06:00 Uhr
Widerstehen Sie der Versuchung, im Zuge der SOA-Einführung neue und
zentralisierte Verantwortlichkeiten zu schaffen. Belassen Sie ausgereifte
Lebenszyklen, vor allem für Code und Systembetrieb, dort, wo die Kompetenz bereits vorhanden ist.
Anbieter- und Nutzer-Lebenszyklus
SOA erfordert, dass Services sowohl aus der Nutzerperspektive als auch
aus der Anbieterperspektive betrachtet werden. Da sich aus diesen Per
spektiven verschiedene Anforderungen und Verantwortlichkeiten ergeben,
unterscheidet man zwischen
55 dem Anbieter-Lebenszyklus und
55 dem Nutzer-Lebenszyklus.
Diese beiden Lebenszyklen erfordern Beteiligte, die für ihren Teil des Prozesses verantwortlich sind, die abgeschlossene Aktivitäten des SOA-Lebenszyklus abnehmen und diese an den nächsten Beteiligten übergeben.
Die Beteiligten definieren
Der Lebenszyklus legt einen bestimmten Ablauf von Aktivitäten und Entscheidungen fest und weist sie folgenden Beteiligten zu:
55 Business Owner: Der Business Owner, also der fachlich verantwortliche Mitarbeiter, formuliert die Anforderungen an eine neue
fachliche Funktion, Lösung oder einen Prozess. Am besten geht das
mit Prozessmodellen oder mit BPMN (Business Process Modeling
Notation, Modellierungsnotation für Geschäftsprozesse). Mit Prozessmodellen lassen sich Anforderungen an eine IT-Implementierung
besonders gut veranschaulichen. Der Business Owner definiert auch
die nichtfunktionalen (zum Beispiel qualitativen) Anforderungen an
die Funktion, die Lösung oder den Prozess.
55 SOA-Architekt: Der SOA-Architekt analysiert die fachlichen Anforderungen und unterteilt sie in Servicedesign und Prozessdesign.
Vielleicht entscheidet er sich dafür, einen bestehenden Service
wiederzuverwenden, anstatt eine neue Komponente zu erstellen. In
diesem Fall wird er die Anforderung in einen Nutzer-Lebenszyklus
verwandeln, damit die bestehende Komponente wiederverwendet
wird. Wenn der SOA-Architekt eine neue Service- oder Prozessimplementierung vorschlägt, spezifiziert er sie mit Zustandsdiagrammen,
Prozessmodellen und Schnittstellendesigns. Außerdem bringt er die
nichtfunktionalen Anforderungen (NFR, Nonfunctional Require-
9780470483336.indb 58
18.02.2009 11:06:01 Uhr
ments) an die Komponente (wie Verfügbarkeit, Sicherheit, Performance und so weiter) in die richtige Form.
55 Entwickler: Auf der Grundlage der Designspezifikationen, die der
SOA-Architekt ausgearbeitet hat, implementiert der Entwickler die
Komponenten und erstellt Testpläne. Er baut auf der Arbeit des
SOA-Architekten auf und bringt so Technologie und Methode in Einklang.
55 Qualitätsmanager: Der Qualitätsmanager zieht den Input von
Business Owner, Architekt und Entwickler heran und prüft die Korrektheit des implementierten Service oder Prozesses. Dann führt
er anhand der vom Entwickler bereitgestellten Testpläne einen Lösungstest in einer Staging-Umgebung durch und validiert Qualitätskennzahlen, Nebeneffekte und nichtfunktionale Merkmale.
55 Operator: Der Operator übernimmt die getesteten und freigegebenen Lösungen, implementiert sie im Rahmen der standardisierten
IT-Prozesse und stellt sie damit den Nutzern bereit. Anhand der
spezifizierten nichtfunktionalen Anforderungen betreibt er eine virtualisierte Lösung, die die vorgegebenen Service-Level-Agreements
(SLAs) einhält. Runtime-Governance-Lösungen für SOA unterstützen
dies, indem sie dafür sorgen, dass nichtfunktionale Anforderungen
und SLAs eingehalten werden.
Abnahmen
Abnahmen sind dazu da, geleistete Arbeiten vor dem Übergang in die
nächste Phase des Lebenszyklus zu bewerten und freizugeben. Bevor zum
Beispiel das Design eines Service in die Entwicklungsphase übergehen
kann, wird geprüft, ob der Designvorschlag die organisatorischen und
technischen Standards erfüllt, ob das Wiederverwendungspotenzial ausgeschöpft wurde und ob auch keine Redundanzen vorliegen. Meist führt
ein Kompetenzzentrum diese Abnahmen durch.
Wenn irgend möglich, sollten Sie Ihre Abnahmen automatisieren. Ein Kompetenzzentrum ist zwar notwendig, aber ansonsten sollten Sie die Zuständigkeiten besser aufteilen, als neue, zentrale Instanzen zu schaffen. Bei
aufgeteilten Zuständigkeiten gibt es weniger Spannungen, denn niemand
hat es gern, wenn man ihm später wieder Verantwortung und Autorität
wegnimmt.
Je besser Technologie und Methode aufeinander abgestimmt sind, desto
mehr Abnahmen können in der Designphase durch Governance-Technologien automatisiert werden. Diese Technologien sorgen dann für die korrekte Umsetzung von Entscheidungen beziehungsweise Richtlinien im
SOA-Lebenszyklus.
9780470483336.indb 59
18.02.2009 11:06:01 Uhr
Verträge aufsetzen
Der Hauptunterschied zwischen Anbieter- und Nutzer-Lebenszyklus besteht darin, dass im Nutzer-Lebenszyklus der Nutzer den Anforderungen
des Anbieters zustimmen muss und umgekehrt. Ein Schritt im AnbieterLebenszyklus ist die Isolierung nichtfunktionaler Anforderungen. Für den
Nutzer gibt es einen zusätzlichen Schritt: Er muss seine nichtfunktionalen
Anforderungen an die Komponente, die er nutzen will, spezifizieren. Die
Vereinbarung über die NFR zwischen Nutzern und Anbietern nennt man
Vertrag. Moderne Technologien für den SOA-Lebenszyklus und für SOAGovernance unterstützen das Prinzip des Vertrags, um
55 Nutzer nachzuverfolgen,
55 kritische SLA-Events melden zu können,
55 Fakturierungs- und Bereitstellungsdaten zu erhalten.
Die Beziehungen zwischen Anbietern und Nutzern müssen in jeder SOAImplementierung dokumentiert werden, damit Versionierungs- und Änderungsprozesse korrekt ablaufen.
Die Entwicklung der SOA
im Griff behalten
In einer hochgradig verteilten, komponentenbasierten Umgebung wie einer SOA muss man den Überblick über Änderungen behalten. Das ist unbestritten. Ganz einfach ist es aber nicht, schließlich haben die Lösungen
unterschiedliche Owner, und der Wunsch des Unternehmens nach Konsistenz und Kontrolle wird auch nicht geringer. Um die Entwicklung von einer bestehenden, anwendungsorientierten IT-Landschaft zu einer SOA im
Griff zu behalten, brauchen Sie ein hohes Maß an Disziplin.
Die folgenden Tipps helfen Ihnen dabei:
55 Planen Sie im Lebenszyklus einen eigenen Prozess für die Verwaltung von Service- oder Prozessänderungen ein. Da sich eine einzige
Änderung in einer verteilten Umgebung auf mehrere andere Lösungen auswirken kann, ohne dass man es auf Anhieb merkt, müssen
alle Beteiligten in diesen Prozess eingebunden werden.
55 Um alle Auswirkungen einer Änderung zu erkennen, sollten Sie auch
die Verträge zwischen Anbietern und Nutzern überprüfen.
55 Benachrichtigen Sie aktive Nutzer bei unmittelbar anstehenden Änderungen oder wenn ihr Einverständnis zu einer beantragten Änderung nötig ist.
9780470483336.indb 60
18.02.2009 11:06:01 Uhr
55 Ergänzen Sie die Verträge um eine zeitliche Komponente, innerhalb
derer eine Änderung verhandelt werden muss. Das erinnert Anbieter
und Nutzer an ihre Verantwortung und fördert eine Einigung.
55 Wenn eine Lösung schnell bereitgestellt werden soll und dies aus
Stabilitätsgründen noch nicht möglich ist, können Sie mit Versionierung arbeiten.
Die Versionierung von Services und Prozessen hilft beim Management der
SOA-Entwicklung. Dabei sollten Sie Folgendes beachten:
55 Ändern Sie das Verhalten von Services oder Prozessen nur, wenn es
unbedingt sein muss. Implementieren Sie stattdessen einen neuen
Service oder Prozess, der das gewünschte Verhalten aufweist.
55 Änderungen an Service- oder Prozessschnittstellen sollten über TopDown-Versionierung umgesetzt werden. Die Vorteile sind:
• Neue Schnittstellen werden modelliert.
• Die Funktionalität verschiedener Versionen kann parallel
angeboten werden, zum Beispiel durch Änderungen am
Namensraum der Service- oder Prozessschnittstelle.
• Alte Schnittstellen können ersetzt werden, indem man die
Semantik der alten Schnittstelle mit Orchestrierungs
technologie simuliert.
55 Wenn Sie die Versionierung Ihrer Services und Prozesse organisieren, sollten Sie eine Ablauffrist in die Verträge aufnehmen, damit
Anbieter und Nutzer die Wandlungsfähigkeit der SOA erkennen und
sich auf Änderungen gefasst machen.
Ein Beispiel
Dem ständigen Wandel kann sich auch eine IT-Abteilung nicht entziehen.
Sie muss sich ohnehin ständig in alle Richtung strecken und befindet
sich so immer irgendwie im Übergang. Abbildung 7.1 zeigt das Organigramm einer fiktiven IT-Abteilung. Wie man sieht, sind viele IT-Funktionen
zentralisiert. Es gibt zum Beispiel je eine Gruppe, die sich mit der Unternehmensarchitektur befasst, eine Gruppe, die für IT-Services zuständig
ist, sowie eine Gruppe, die sich ausschließlich mit Risk Management
beschäftigt.
9780470483336.indb 61
18.02.2009 11:06:01 Uhr
CIO
Assistent
Risk
Management
UnternehmensRessourcenstrategie und
Management
Architektur
IT-Services
Unternehmensanwendungen
Datenschutz
Programmmanagement
HR
Technologie
und Netzwerke
SAP
Sicherheit
Unternehmensarchitektur
Investitionen
Rechenzentren
Oracle
Entsorgungsmanagement
Beschaffung
Records
Mangement
Krisenintervention
Datenservices
Geschäftsbereich A
Geschäftsbereich B
Anwendungs- Anwendungsentwicklung
entwicklung
QA
QA
Support für
Support für
Anwendungen Anwendungen
Business
Analyst
Beratung
Business
Analyst
Dokumentation Dokumentation
Abbildung 7.1: Eine IT-Abteilung im Übergang
Das Unternehmen hat zwei Geschäftsbereiche, und jeder Geschäftsbereich hat seinen eigenen Lebenszyklus für die Systementwicklung mit jeweils eigenen Gruppen (Anforderungsanalyse, Entwicklung, Qualitätsmanagement, Support und Dokumentation).
Was das Organigramm nicht zeigt, sind die verdeckten oder offenen Konflikte zwischen den Gruppen.
Spannungen in der zentralen IT
Unsere Beispielorganisation hat durch eine Übernahme Zuwachs bekommen. Deshalb gibt es in der zentralen IT jetzt zwei ERP-Systeme, eines von
Oracle und eines von SAP. Jede ERP-Gruppe möchte die andere am liebsten loswerden und hätte gern, dass das Unternehmen auf ihr Paket standardisiert. Dieses Szenario mag übertrieben klingen, doch es gibt sogar
Organisationen mit 25 verschiedenen ERP-Systemen.
Weiterer Stress ergibt sich dadurch, dass bestimmte Funktionen seit der
Übernahme doppelt besetzt sind. Und die beiden Enterprise-Architekten
9780470483336.indb 62
18.02.2009 11:06:02 Uhr
(aus der alten und der neuen Firma) haben völlig verschiedene Ansichten
dazu, in welche Richtung es weitergehen soll.
Das Organigramm der zentralen IT zeigt an der betreffenden Stelle zwar
nur ein Kästchen, aber der CIO hat einen Manager zum VP Unternehmensstrategie und einen zweiten zum VP Unternehmensarchitektur ernannt.
Beide VPs hegen Ambitionen auf den Posten des CIO und jeder hat eigene
Zukunftspläne für die IT entwickelt, bei denen die Systeme der e
igenen
Ursprungsfirma weitergeführt werden. Die VPs tauschen keine Informationen aus, und jeder hofft auf die Entlassung des anderen. Jeder strebt danach, dass seine Pläne umgesetzt werden, denn dann
55 wird auf seine bevorzugte Anbieterplattform standardisiert,
55 behalten möglichst viele seiner Leute ihren Job,
55 kann er am ehesten den CIO beerben.
Jeder VP pflegt enge Beziehungen zu seinem Anbieter, fährt auf dessen
Kosten zu Benutzertreffen in exotische Länder und hat inzwischen jahrelange Erfahrung mit seinen Technologien. Obwohl sie für Architektur und
Strategie zuständig sind, werden diese beiden Führungskräfte ihre Plattform niemals freiwillig aufgeben.
Spannungen zwischen Geschäftsbereich A
und zentraler IT
Laut Organigramm berichtet der VP Enterprise Strategy zwar an den CIO,
aber er befindet sich in einer Matrix-Organisation und berichtet deshalb
auch an den IT-Leiter der Geschäftsbereiche. Zwei Herren zu dienen kann
anstrengend und frustrierend sein.
Der IT-Leiter von Geschäftsbereich A wurde von seinem VP beauftragt, innerhalb von sechs Monaten eine E-Commerce-Lösung auf die Beine zu
stellen. Wenn es nicht klappt, verliert er seinen Job. Neulich hat er sich
auf dem Flur lautstark mit dem Leiter Risk Management gestritten, der
seinem Projekt strenge Sicherheits- und Datenschutzauflagen gemacht
hat. Der Bereich Unternehmensarchitektur verlangt auch noch die Einhaltung eines bestimmten Standarddatenschemas. Dieses Standardschema
erfasst aber bestimmte Daten nicht, die er unbedingt braucht. Zu allem
Überfluss verwendet das Standardschema teilweise die gleichen Datenfelder wie sein Format, aber mit einer komplett anderen Bedeutung. Außerdem hat einer seiner besten Entwickler ein attraktives Angebot von einer
anderen Firma und verlässt das Unternehmen vielleicht in Kürze.
9780470483336.indb 63
18.02.2009 11:06:02 Uhr
Der Leiter Risk Management befürchtet natürlich, dass eine Sicherheitslücke ihn seinen Job kosten könnte. Deshalb will er den Geschäftsbereichen
bei den Auflagen keinen Zentimeter entgegenkommen.
Der IT-Leiter von Geschäftsbereich A befürchtet, dass sein E-CommerceProjekt bei all diesen Anforderungen nicht rechtzeitig fertig wird und er
den Kopf dafür hinhalten muss. Das ist schon seinem Vorgänger passiert,
der bei der Übernahme entlassen wurde.
Misstrauen zwischen den
Geschäftsbereichen
Geschäftsbereich B hat mit Geschäftsbereich A schon einmal eine
schlechte Erfahrung gemacht. Bereich A hat mit der Datenservice-Gruppe
gemeinsame Sache gemacht und die Kundendatenbank von Bereich B in
einen unternehmensweiten Service verwandelt. Anschließend hat Bereich
A die Kunden von Bereich B mit einer Direktmarketing-Kampagne überzogen.
Dies hat einige Kunden von Bereich B verärgert. Einige haben ihre Geschäftsbeziehung mit dem Unternehmen beendet, und einer wollte sogar
klagen und hat das Unternehmen als Spammer bezeichnet.
Der Austausch von Daten ist eine tolle Sache, aber es müssen Regeln dafür gelten. Die Interessengruppen müssen unbedingt im Gespräch miteinander bleiben.
Spannungen zwischen den Beteiligten
im Lebenszyklus
Den Lebenszyklus eines Service kann man sich vorstellen wie eine Fertigungsstraße in der Autofabrik. Das Fließband befördert das Fertigungsstück von einem Team zum nächsten. Ein Team montiert den Motor, das
nächste bearbeitet die Karosserie und so weiter. So ist es auch beim Servicelebenszyklus. Jede Gruppe erledigt ihre Aufgabe, bis der Service fertig
ist.
An dieser Service-Fertigungsstraße gibt es manchmal Spannungen zwischen den Spezialisten. Die Entwickler schreiben hervorragenden neuen
Code, aber sie erzeugen auch Fehler und Support-Probleme. Die wichtigsten Interessengruppen innerhalb des Servicelebenszyklus sind:
9780470483336.indb 64
18.02.2009 11:06:02 Uhr
55 Softwareentwickler
55 Enterprise-Architekten
55 Sicherheitsfachleute
55 Operatoren
55 Qualitätsfachleute
55 Business-Analysten
55 Integrationsentwickler
Jede dieser Gruppen hat ihre eigenen Prioritäten und stellt ihre Arbeit in
den Vordergrund. Jede hat ihre eigene Sicht auf die IT-Prozesse und ihren
eigenen Lebenszyklus, der sich vom Lebenszyklus der SOA unterscheidet.
In diesen Verhaltensmustern ist gedanklich kein Platz für wiederverwendbare Services, Interoperabilität oder andere SOA-Werte.
In unserer Beispielorganisation sträubt sich die Entwicklergruppe gegen
die Wiederverwendung der Services im Registry/Repository. Ihr Hauptvorwurf lautet, dass die Services schlecht dokumentiert sind und dass die
Wiederverwendung eines Service deshalb genauso lange dauert wie die
Entwicklung eines neuen. Auch unter Designaspekten möchten die Entwickler keine »fremden« Services in ihrem Code nutzen, denn wenn der
Code nicht funktioniert, werden sie dafür verantwortlich gemacht, selbst
wenn der Fehler nicht auf ihr Konto geht. Dem Code anderer vertrauen
sie nicht.
9780470483336.indb 65
18.02.2009 11:06:03 Uhr
9780470483336.indb 66
18.02.2009 11:06:03 Uhr
Kapitel 8
Finanzierung der SOA
In diesem Kapitel
00
Die Unterstützung des Managements sichern
00
Die Organisation motivieren
U
m ihre Effizienz und Produktivität zu verbessern, führen
IT-Abteilungen neue Technologien ein. Denken wir nur an Case,
Objektorientierung und Client-Server. Technologien, deren Vorteile leider
schwer messbar und auch nicht leicht zu erklären waren. Die Optimierungsziele der IT lagen in ferner Zukunft. Wenn eine Lösung in kurzer Zeit
keine spürbaren Verbesserungen brachte, machte sich nach der ersten
Euphorie Ernüchterung breit.
Der Nutzen eines Produkts, das Sie fertig kaufen, ist meist offensichtlich.
Der Nutzen eines Handlungsprinzips hingegen springt nicht sofort ins
Auge. SOA ist ein Handlungsprinzip, und deshalb gilt es herauszufinden,
wie Ihr Unternehmen dieses Handlungsprinzip optimal nutzen kann.
Überzeugende Argumente
für SOA finden
Meistens werden in Kosten-Nutzen-Analysen IT-Projekte anhand ihres Return on Investment (ROI) bewertet. Der ROI wird wie folgt ermittelt:
1. Man schätzt den Aufwand für die Bereitstellung einer neuen
Funktionalität ab.
2. Man bewertet Effizienz- und Produktivitätssteigerungen oder die
Zeitersparnis.
3. Man berechnet, wann Umsatzsteigerungen oder Kosteneinsparungen, die aufgrund der neuen Funktionalität erzielt werden, die
Einführungskosten wieder wettmachen.
9780470483336.indb 67
18.02.2009 11:06:03 Uhr
Der Nutzen eines SOA-Projekts lässt sich mit einer herkömmlichen Kosten-Nutzen-Analyse nicht zufriedenstellend abbilden, weil diese wesentliche SOA-Ziele nicht erfasst:
55 SOA zielt darauf ab, bestehende IT-Technologien und -Prozesse so
lange wie möglich weiterzuverwenden. Dadurch schöpft das Unternehmen frühere Investitionen maximal aus. Um es betriebswirtschaftlich auszudrücken: Man verbessert den Return on Investment
(ROI, Rendite des investierten Kapitals) bereits getätigter Investi
tionen und erzielt einen maximalen Return on Assets (ROA, Gesamt
kapitalrendite).
55 SOA nutzt IT-Synergien. Die unternehmensweite Wiederverwendung von Komponenten setzt Kapazitäten frei, die für andere
wichtige Aufgaben – Automatisierung, Innovationen oder Kostenreduzierung – eingesetzt werden können.
55 SOA macht Unternehmen so flexibel, dass sie neue Lösungen
schnell zusammensetzen können. Setzt man Lösungen nur noch
zusammen, stehen sie erheblich früher zur Verfügung. Unternehmen
können ihre Services mit vorhandenen Technologien und vorhandenem Know-how implementieren.
Das müssen die drei großen konkreten Ziele sein. Es muss möglich sein,
diese Ziele in absehbarer Zeit zu erreichen, und die Ziele dürfen nicht zu
abstrakt formuliert werden. Bei der Erstellung der Kosten-Nutzen-Analyse
für eine SOA-Einführung sind drei Ansätze möglich. Mit der jeweils passenden Argumentation wird es Ihnen leichter fallen, die ideelle und materielle Unterstützung des Managements zu gewinnen.
Der taktische Ansatz
Viele IT-Landschaften sind über einen langen Zeitraum entstanden. Hier
stellt sich die Frage, ob die bestehenden Anwendungen zu vertretbaren
Kosten und Risiken erhalten und gewartet werden können. Veränderte
Marktbedingungen und Geschäftsanforderungen verlangen außerdem die
Integration dieser Anwendungen zu durchgängigen Lösungen.
Der Austausch bestehender Anwendungen durch Neuentwicklungen oder
Standardpakete ist riskant und birgt die Gefahr ausufernder Kosten. Stellen Sie sich vor, Sie schalten über Nacht ein altes System ab, ohne zu wissen, ob das neue am nächsten Morgen genauso gut funktioniert – ein riskantes Vorgehen!
Die Überführung einer bestehenden (nicht serviceorientierten) Anwendung in eine SOA klappt am besten, wenn man die Anwendung in
eigenständige, das heißt gekapselte Komponenten aufspaltet und diese
9780470483336.indb 68
18.02.2009 11:06:03 Uhr
Kapitel 8: Finanzierung der SOA 69
mit wohldefinierten Schnittstellen ausstattet, hinter denen technische
Aspekte verborgen bleiben. Bei dieser Vorgehensweise weiß man immer
genau, in welcher Phase des Übergangs man sich gerade befindet. Man
erhält ein flexibles System, und der Fokus richtet sich nicht länger auf die
kostspielige Gesamtanwendung als solche, sondern auf den Wert ihrer
einzelnen Komponenten.
Bei der Aufteilung einer Anwendung in Komponenten kann das Management die gewonnene Flexibilität auch leichter nachvollziehen. Das Unternehmen kann frei über die weitere Vorgehensweise entscheiden. Das Gefühl, Sklave einer bestehenden Anwendung zu sein, weicht der Sicherheit,
über den notwendigen Handlungsspielraum zu verfügen. Eine in Komponenten aufgeteilte Anwendung lässt sich meist auch viel leichter warten
oder ersetzen.
Wenn man die Komponenten einer Anwendung voneinander löst, werden
die Beziehungen zwischen ihnen sichtbar. Die Folgen von Änderungen lassen sich leichter abschätzen und es gibt weniger Nebeneffekte. Die Qualität des Systems steigt.
Die Modernisierung und Integration bestehender Anwendungen über eine
SOA bietet klare Vorteile:
55 Kostenkontrolle (keine Überraschungen)
55 Schnelle Ergebnisse (Integration)
55 Zufriedene Anwender (zusammengeführte Anwendungen)
55 Geringere Support-Kosten
Der strategische Ansatz
Wenn Sie eine SOA-Infrastruktur implementieren wollen, um schneller
neue Anwendungen zusammensetzen zu können, müssen Sie strategisch
denken. In einer Composition-Umgebung sind Funktionen und Komponenten interoperabel, im gesamten Unternehmen verteilt und werden gemeinsam genutzt. Man nutzt sie als ein erweiterbares Modell für die Bereitstellung von Lösungen. Für die strategisch ausgerichtete SOA-Einführung ist
eine organisatorische und technische Governance notwendig. Sie sorgt
dafür, dass IT-Maßnahmen projekt- und abteilungsübergreifend aufeinander abgestimmt werden (siehe auch Kapitel 7). Bei diesem Ansatz geht es
darum, Synergien auszuschöpfen und Redundanzen zu beseitigen.
Eine strategische SOA-Einführung zielt in erster Linie auf die Bereitstellung von Lösungen ab und nicht auf die Schaffung von etwas völlig
Neuem. Hierfür muss die SOA-Philosophie aber von jedem IT-Mitarbeiter
vollständig verinnerlicht worden sein. Geeignete SOA-Lösungen finden Sie
9780470483336.indb 69
18.02.2009 11:06:04 Uhr
am besten, indem Sie Geschäftsanforderungen mit Wertschöpfungspotenzial suchen, die sich über mehrere technische und funktionale Bereiche
erstrecken. Eine strategische SOA darf nie zum Selbstzweck werden. Sichern Sie sich die Unterstützung der Geschäftsleitung, trainieren Sie Ihr
Team und schaffen Sie Anreize, damit es Ihre Strategie mitträgt.
Sehr wichtig ist nicht zuletzt, dass der Erfolg der strategischen SOA gemessen werden kann. Weisen Sie nach, dass die zusammengesetzten Anwendungen einer SOA-basierten Infrastruktur zu kürzeren Entwicklungszeiten und zu mehr Flexibilität führen. Je eher Sie diese Daten präsentieren, desto besser sind Ihre Erfolgsaussichten.
Der praktische Ansatz: BPM
Unterstützung für eine SOA lässt sich sehr effektiv auch dadurch gewinnen, dass man sie mit BPM (Business Process Management) kombiniert.
BPM stellt dem Unternehmen nicht nur zuverlässig Lösungen bereit, sondern erlaubt auch die flexible Durchführung von Änderungen. Wenn Prozesse isoliert und in ein ablauffähiges Modell überführt werden, sind Änderungen erheblich schneller möglich als mit herkömmlicher Codeentwicklung. BPM macht Unternehmen flexibler, braucht dafür aber auch
eine flexible Infrastruktur. Die Kombination von SOA und BPM sorgt für
Konsistenz ohne starre Codebeziehungen.
Wenn Sie in einer BPM-Umgebung Prozesse entwickeln, merken Sie
schnell, welche Services die SOA-Plattform bereitstellen muss, damit Prozesse automatisiert werden können. BPM zeigt die konkreten Vorteile von
SOA sehr klar und korrigiert das Image von SOA als Verursacher hoher
Kosten und Komplexität. Durch die klare fachliche Ausrichtung wird deutlich: SOA bietet wertvolle Services und steht nicht nur für die Kombination beliebiger Schnittstellen.
Die Organisation motivieren
Der Erfolg einer SOA-Einführung steht und fällt mit der Motivation der
Mitarbeiter, sich ernsthaft auf SOA einzulassen. Deshalb sind Aufklärung
und Anreize unabdingbar. Hierbei gilt es zwei Gruppen zu berücksich
tigen:
55 Serviceanbieter: Wenn Funktionen bisher als Teil isolierter Anwendungen betrachtet wurden, sind Mitarbeiter manchmal nicht bereit,
Services anzubieten beziehungsweise mit anderen zu teilen. Nicht
weil sie einen schlechten Charakter haben, sondern weil sie den
Vorteil nicht erkennen und niemand die zusätzliche Verantwortung
9780470483336.indb 70
18.02.2009 11:06:04 Uhr
Kapitel 8: Finanzierung der SOA 71
für die Servicebereitstellung übernehmen will. Je mehr Nutzer einen
Service in Anspruch nehmen, desto mehr Zeit muss der Anbieter in
die Wartung der Anwendung investieren und desto mehr Klagen
muss er sich anhören. Und wie sieht es mit den Kosten aus? Ist es
etwa in Ordnung, wenn ein Projekt die Entwicklungskosten übernimmt und andere später kostenlos profitieren?
55 Servicenutzer: Der Held eines Projekts war früher immer der Entwickler, der in kürzester Zeit jede Menge exzellenten Programmcode
produzierte. Entwickler fürchten vielleicht, dass ihre Kreativität
nicht mehr gefragt ist, wenn sie die Services anderer Anbieter wiederverwenden sollen.
Aus diesen Gründen reichen herkömmliche Motivationsstrategien bei der
SOA-Einführung nicht aus. Denken Sie über folgende Anreize nach:
55 Bereitstellung von Services an andere: Je mehr Services der Anbieter erstellt und anschließend anderen zugänglich macht, desto
höher sollte die Anerkennung für den Entwickler und das Projekt
ausfallen.
55 Servicenutzung: Belohnen Sie den Mitarbeiter, der die meisten Services anderer nutzt. Wenn Sie die Effizienz eines Projekts oder einer
Implementierung bewerten, sollten Sie sich nicht an der Implementierungsdauer orientieren, sondern an der Zahl der implementierten
Funktionen und wiederverwendeten Services.
55 Umlage von Servicekosten: Nutzer, die durch Wiederverwendung in
kürzerer Zeit mehr Funktionen implementieren können, sollten dem
Serviceanbieter einen Teil der eingesparten Kosten erstatten.
55 Wartung von Services: Belohnen Sie den Serviceanbieter, wenn
andere seine Services in Anspruch nehmen, sowohl durch eine Kostenumlage als auch durch sichtbare Anerkennung. In einer SOA-Organisation ist derjenige der Held, dessen Service am häufigsten von
anderen genutzt wird. Wenn Nutzer Services geändert haben wollen,
müssen sie einen Teil der Kosten übernehmen.
55 Services als Wert: Beurteilen Sie Services nach ihrem Wert. Sehen
Sie sie nicht als Belastung, sondern als Nutzenbringer. Servicenutzer
sollten sich immer auch als Serviceanbieter verstehen. Das unterstreicht den Gedanken der IT-Wertschöpfungskette.
Anreize müssen ausgewogen sein, damit sie Mitarbeiter über ihren jeweiligen Bereich hinaus zur gemeinsamen Nutzung und Wiederverwendung
von Services motivieren. Mit den richtigen Anreizen wird es der Organisation gelingen, die SOA-Einführung nicht von oben nach unten, sondern
von innen heraus voranzutreiben.
9780470483336.indb 71
18.02.2009 11:06:04 Uhr
9780470483336.indb 72
18.02.2009 11:06:04 Uhr
Kapitel 9
Ihr erstes SOA-Projekt
In diesem Kapitel
00
Ein SOA-Projekt implementieren
00
Auf dem richtigen Kurs bleiben
00
Automatisierung einsetzen
D
as Denken in Projekten ist in der IT weit verbreitet: Ein Projekt reiht
sich scheinbar willkürlich an das andere, keines baut auf Vorhandenem auf und keines berücksichtigt zukünftige Anforderungen. Jedes
Projekt dient nur den Interessen einer bestimmten Gruppe, aber das ist
nicht das Hauptproblem. Schlimmer ist, dass niemand über den heutigen
Tag hinaus denkt und sich überlegt, welche Konsequenzen die Projekte
haben werden.
So verlockend ein fertiger Architekturbauplan auch aussehen mag, so klar
muss man wissen: Einen Elefanten kann man nicht auf einmal verzehren,
und eine SOA kann man nur Projekt für Projekt einführen.
Mit den richtigen Partnern und Verbündeten wird es Ihnen aber gelingen,
in einer sinnvollen Abfolge Projekte umzusetzen, die auf Vorhandenem
aufbauen und zukunftsfähig sind. Dieses Kapitel erklärt, wie Sie technische Hürden der SOA-Einführung Projekt für Projekt überwinden.
Ein SOA-Projekt aufsetzen
SOA-Projekte sind sehr flexibel und können im Prinzip jedes Geschäftsproblem lösen. Damit hat ein SOA-Projekt auch viele potenzielle Förderer
und Geldgeber.
Nehmen wir einmal an, Ihr erstes Projekt hat mit Business Process Management zu tun. Durch welche Eigenschaften wird es zum SOA-Projekt?
9780470483336.indb 73
18.02.2009 11:06:04 Uhr
Ein SOA-Projekt hält sich an die vereinbarten SOA-Standards, -Prozesse
und -Richtlinien Ihres Unternehmens und bringt es der Architektur und
Organisationsstruktur, die im Bauplan vorgesehen sind, einen Schritt näher. Deshalb kann praktisch jedes IT-Projekt zum SOA-Projekt werden.
Mögliche Projektbeispiele sind:
55 Business Process Management
55 Integration von Mainframe-Daten
55 Integration nach Firmenübernahmen oder Fusionen (M&As)
55 Referenzdaten
55 Stammdaten
55 Datenqualität
55 Modernisierung von Bestandssystemen
55 Enterprise Architecture
55 Rationalisierung von Anwendungen, Datenschemata
55 Identitätsmanagement
55 Konsolidierung von Rechenzentren
55 Erfüllung regulatorischer Auflagen
55 Flexible/iterative Methoden
55 Vereinheitlichung von Bereitstellungskanälen (Handy, F
ilialen, Internet, Callcenter, Geldautomaten)
Mit den richtigen Services beginnen
Die ersten gemeinsamen Services, die Sie in einem Registry/Repository
bereitstellen, sind ausschlaggebend dafür, wie gut das SOA-Konzept im
Unternehmen akzeptiert wird. Wählen Sie deshalb Services aus, die von
allgemeinem Interesse sind und zentrale Funktionen mit Mehrwert bieten.
Wenn Sie clever sind, suchen Sie einen Prozess oder Service aus, der zur
Einhaltung einer regulatorischen Anforderung nötig ist oder ein anderes
elementares Bedürfnis erfüllt. Wenn zum Beispiel eine Adressdatenbank
zur Abwicklung von Gehaltszahlungen verwendet wird, kann man sicher
sein, dass die Mitarbeiter sie sorgfältig pflegen.
Wenn die Mitwirkenden in Ihrer SOA durch die Erfüllung der SOA-Anforderungen auch eigene grundlegende Anforderungen abdecken, werden Sie
sie nach und nach für Ihre Sache gewinnen.
9780470483336.indb 74
18.02.2009 11:06:04 Uhr
Kapitel 9: Ihr erstes SOA-Projekt 75
Neue Verbündete
SOA-Projekte bringen die unterschiedlichsten IT-Akteure an einen Tisch,
zum Beispiel Anwendungsentwickler und ERP-Spezialisten oder Integrationsexperten und Manager von B2B-Portalen. Seien Sie Ihren Verbündeten
gegenüber aufgeschlossen und nutzen Sie die neuen Beziehungen.
Auf Kurs bleiben
Damit die SOA auf Kurs bleibt, sind immer wieder projektinterne und projektübergreifende Korrekturen notwendig.
Überwachen Sie kontinuierlich, ob IT-Maßnahmen mit den Richtlinien und
Prozessen des SOA-Bauplans in Einklang stehen. Neue Services müssen
wiederverwendbar und kompatibel sein, sonst kommen Sie Ihrem SOABauplan kein Stückchen näher. Auch die fachlichen Ergebnisse müssen
überwacht werden – damit auch das nächste SOA-Projekt genehmigt wird
und die Servicenutzer Ihre ersten Services finden, einsetzen, wiederverwenden und Nutzen daraus ziehen. Wenn technisch oder fachlich etwas
nicht stimmt, müssen Sie sofort Korrekturen vornehmen.
Die SOA-Tauglichkeit von
IT-Projekten bewerten
Für uns ist jedes IT-Projekt SOA-tauglich, das mit Ihren SOA-Richtlinien
und -Prozessen in Einklang steht und das Sie Ihrem SOA-Bauplan näher
bringt. Ohne diese zweite Voraussetzung ist Ihr Projekt kein SOA-Projekt.
Manchmal werden Projekte als SOA-Projekt bezeichnet, auch wenn sie
SOA-Richtlinien oder -Prozesse nicht erfüllen. Wenn Sie das regelmäßig
tun, werden Sie Ihren Bauplan nie umsetzen. Aber es gibt auch Fälle, in
denen sich diese Taktik bewährt hat, um die Unterstützung des Managements oder zusätzliche Gelder für die Governance-Infrastruktur zu sichern.
Ob SOA-Richtlinien und -Prozesse eingehalten werden, lässt sich anhand
folgender Kriterien feststellen:
55 Wie oft muss ein neuer Service entwickelt werden, anstatt einen
vorhandenen Service zu nutzen?
55 Wie oft muss ein Service versioniert werden?
55 Wie viele Nutzer hat ein Service?
9780470483336.indb 75
18.02.2009 11:06:05 Uhr
55 Wie lange dauert die Erstellung eines neuen Service?
55 Wie viele »wilde« Services gibt es außerhalb der Governance-Struktur?
55 Gibt es Service-Level-Agreements?
55 Wie viele Änderungs- und Versionierungswünsche werden eingereicht?
55 Wie viele Support-Anfragen werden gestellt?
55 Wie wird die Serviceinfrastruktur genutzt?
Die Kennzahl Gesamtkosten über den gesamten Lebenszyklus veranschaulicht den Beteiligten sehr gut, wie viel günstiger die Wiederverwendung
im Vergleich zur Erzeugung neuen Codes ist. Berechnen Sie die Kosten
möglichst nicht pro Gruppe, sondern für alle Gruppen zusammen.
Setzen Sie Kennzahlen als Motivationsinstrument ein. Sie können mit Prämien arbeiten oder das Erreichen der Kennzahlen als allgemeines Unternehmensziel vorgeben – beides hilft, Ergebnisse mit dem Verhalten der
Beteiligten in Beziehung zu setzen.
Den ROI für die Abteilungen messen
Aus der Sicht des Geldgebers ist ein IT-Projekt dann erfolgreich, wenn es
einen ROI (Return on Investment) erzielt. Deshalb sollte Ihr erstes SOAProjekt unbedingt einen ROI nachweisen. Wichtig ist auch: Sobald Sie Ihr
SOA-Projekt mit fachlichen Zielen verknüpfen, ist der Verdacht »SOA um
der SOA willen« widerlegt.
SOA ist mehr als reine IT. SOA dreht sich ums Geschäft. Deshalb wollen
die Fachabteilungen bei einem Service vor allem Folgendes wissen:
55 Was kostet dieser Service?
55 Was kostet es, den Service zu unterstützen?
55 Wie viel haben wir letzten Monat durch diesen Service verdient beziehungsweise ausgegeben?
55 Wer zahlt, wenn der Service geändert werden muss?
Diese Fragen helfen Ihnen auch, wenn Sie über Prämien, Beförderungen
und Führungsziele entscheiden müssen.
9780470483336.indb 76
18.02.2009 11:06:05 Uhr
Kapitel 9: Ihr erstes SOA-Projekt 77
Richtlinien und Prozesse
automatisieren
Um im Unternehmen möglichst wenig Widerstand gegen Richtlinien und
Prozesse hervorzurufen, sollten Sie diese schrittweise automatisieren.
Langsam vorgehen
Bei Ihrem ersten SOA-Projekt könnten Sie zum Beispiel die Nutzung eines
Service-Registry einführen, mit dem Sie koordinieren, wie verschiedene
IT-Gruppen einen Service gemeinsam verwenden. Mit der Einführung des
Registry richten Sie einen neuen Prozess für die gemeinsame Servicenutzung ein. Später dient das Registry dann zur Verwaltung von Designrichtlinien und zur Koordinierung der Prozesse im SOA-Lebenszyklus.
Schon von dem Tag an, an dem Sie Ihre ersten Services offiziell zur Nutzung freigeben, wird automatisch ein Ausleseprozess beginnen, bei dem
schlecht entworfene, eng gekoppelte Services ausgemustert werden.
Sagen Sie ruhig ganz deutlich, dass jeder, der »wilde« Services nutzt, die
nicht im Registry gespeichert sind, zusehen muss, wie er zurechtkommt
und dass Ihre Abteilung keine Gewähr für die Zuverlässigkeit, Sicherheit
oder Qualität solcher Services übernimmt.
Frühzeitige Einführung der
Governance-Infrastruktur
Die Governance-Infrastruktur besteht aus dem Registry/Repository und
dem Runtime-Management-System.
Das Registry/Repository dient als Kontrollpunkt für die Richtlinien der
Designphase. Ohne diese Komponente lässt sich die Einhaltung von De
signrichtlinien nur schwer automatisieren.
Noch vordringlicher als das Registry/Repository ist der frühe Einsatz des
Runtime-Management-Systems als Kontrollpunkt für die Laufzeitrichtlinien. Warum ist das so wichtig?
Ohne Governance-Kontrollpunkte können die Nutzer direkt an Services
andocken. Services, mit denen sich Nutzer bereits direkt verknüpft haben,
sind von diesem Moment an aber nicht mehr flexibel. Nur mit einem Registry/Repository kann zurückverfolgt werden, wer einen Service verwendet. Und nur mit einem Runtime-Management-System kann die Zuverläs-
9780470483336.indb 77
18.02.2009 11:06:05 Uhr
sigkeit und Qualität des Service gewährleistet werden. Dies wurde in Kapitel 5 ausführlich erläutert.
Wenn Sie keine Governance-Infrastruktur verwenden und eine direkte Anbindung an Services zulassen, entstehen folgende Probleme:
55 Sie wissen nicht, wer den Service nutzt.
55 Wenn Sie den Service ändern, werden alle Nutzer davon abgeschnitten.
55 Wenn ein Service nicht läuft, funktionieren von ihm abhängige Ser
vices unter Umständen auch nicht mehr.
55 Ein Nutzer könnte alle Serverressourcen eines Service blockieren
und andere Nutzer dadurch ausschließen.
Bei jeder direkten Anbindung kommt es zu einer engen Kopplung, die Sie
weder verfolgen noch warten können und die Sie von Ihren SOA-Zielen abbringt.
Führen Sie Ihre Governance-Infrastruktur frühzeitig und noch vor Inbetriebnahme Ihres ersten Service ein. Richtlinien für diese Umgebung sollten Sie dann aber nur allmählich einführen.
Nach jeder eingeführten Richtlinie sollten Sie genau beobachten, ob sie
sich technisch und fachlich bewährt.
9780470483336.indb 78
18.02.2009 11:06:06 Uhr
Kapitel 10
Das SOA-Raumfahrtprogramm
In diesem Kapitel
00
Das SOA-Raumfahrtprogramm
00
Das richtige Ziel anpeilen
00
SOA wird Normalität
D
ieses Kapitel stellt unser SOA-Raumfahrtprogramm vor. Es erstreckt
sich vom ersten SOA-Projekt über die Koordination nachfolgender
SOA-Projekte bis zur Erfüllung des Architekturbauplans und des Bauplans
für die Organisation.
Die Gesetze der Schwerkraft
Selbst nach dem erfolgreichen Start Ihres SOA-Raumschiffs sind Sie noch
nicht aus der Gefahrenzone heraus: Die Schwerkraft droht Sie in alte
Handlungsmuster zurückzuziehen, in defensives Gruppenverhalten und in
gewohntes Projektdenken.
Vom SOA-Projekt zum
SOA-Programm
Bis Sie Ihre SOA-Baupläne umsetzen können, müssen Sie zunächst einmal
mehrere SOA-Projekte erfolgreich abwickeln. Damit das gelingt, gelten im
SOA-Raumfahrtprogramm die folgenden Prinzipien:
1. Kontrollieren Sie den Kurs Ihres Raumschiffs.
Messen Sie kontinuierlich das bereits Geleistete und korrigieren Sie,
was noch nicht funktioniert.
Dies gilt sowohl innerhalb eines Projekts (wo Sie korrigieren, indem
Sie zum Beispiel eine neue Richtlinie hinzufügen oder Prämien
9780470483336.indb 79
18.02.2009 11:06:06 Uhr
aussetzen) als auch projektübergreifend (indem Sie Erfahrungen aus
dem letzten Projekt im nächsten nutzen und es dadurch besser
machen).
2. Motivieren Sie, damit das Tempo nicht abfällt.
Motivieren Sie Ihr Implementierungsteam, aber auch die Geldgeber,
Entscheider und anderen Beteiligten.
Hierfür muss der geschäftliche Nutzen der SOA mit jedem Projekt
deutlicher hervortreten. Diesen Nachweis müssen Sie erbringen,
um weiteren Finanzierungsbedarf zu begründen, weitere Interessengruppen ins Boot zu holen und die Architektur weiter auf SOA
auszurichten.
3. Automatisieren Sie, bis die Schwerelosigkeit erreicht ist.
Die Schwerkraft haben Sie erst dann überwunden, wenn die Richtlinien und Prozesse Ihres Servicelebenszyklus automatisiert sind.
Wenn Ihr gesamter Lebenszyklus dem Prinzip der Serviceorientierung folgt, hat Ihre SOA den Zustand der Schwerelosigkeit erreicht.
Wie Abbildung 10.1 zeigt, wirken die Prinzipien des SOA-Raumfahrtprogramms parallel auf den Architektur- und den Organisationsbauplan.
Organisationsbauplan
Architekturbauplan
1. Messen
2. Motivieren
4. Automatisieren
3. Korrigieren
Zersiedelte
IT-Organisation
Zersiedelte
Systemlandschaft
Abbildung 10.1: Ein zielführender SOA-Ansatz kombiniert den Organisationsbauplan und den Architekturbauplan miteinander.
9780470483336.indb 80
18.02.2009 11:06:07 Uhr
Kapitel 10: Das SOA-Raumfahrtprogramm 81
In der Gefahrenzone
Bis Ihre SOA den Zustand der Schwerelosigkeit erreicht hat, müssen Sie
noch Energie hineinstecken, also Gelder aufbringen, Management und
Fachabteilungen überzeugen und den SOA-Lebenszyklus weiterentwickeln.
Ist die Schwerelosigkeit aber erst einmal erreicht, fliegt Ihre SOA mühelos
Richtung Ziel, ohne dass Sie weitere Anstrengungen unternehmen müssen.
»Schwerelose SOA« bedeutet nicht unbedingt, dass die SOA-Baupläne
schon vollständig umgesetzt sind. Aber es ist ein entscheidender Punkt
erreicht: Ab hier sehen die Geldgeber ein, dass alle Projekte SOA-Projekte
sein müssen, und ab hier bedeutet die Erstellung neuer Services für die
IT-Fachleute keinen Zusatzaufwand mehr. Dann sind auch andere Bereiche
des Unternehmens auf die Vorteile von SOA aufmerksam geworden und
wollen mitmachen.
Auf Kurs bleiben
Raumschiffe berechnen laufend ihren Kurs und korrigieren ihn gegebenenfalls, sonst fliegen sie am Ziel vorbei. Bei Ihrer SOA können Sie den
Kurs nur korrigieren, wenn Sie das Ziel genau kennen (es wird hoffentlich
die Erfüllung der SOA-Baupläne sein) und wenn Sie die Beteiligten ausreichend motivieren.
Um Ihren aktuellen Kurs zu kennen, brauchen Sie die richtige Berechnungsmethode. Die geeigneten Messkriterien beziehungsweise Kennzahlen für Bewertungen innerhalb eines Projekts haben wir im letzten Kapitel
erläutert. In diesem Kapitel geht es darum, mit welchen Kennzahlen man
Fortschritte projektübergreifend messen kann.
Kennzahlen für den IT-Nutzen
IT-Mitarbeiter lassen sich besser motivieren, wenn Sie folgende Kennzahlen vorlegen:
55 Bereitstellungszeit neuer Services: Konnten Sie Ihrer Organisation
den Servicegedanken noch immer nicht richtig vermitteln? Wie flexibel sind die Prozesse Ihres Lebenszyklus?
55 Blockaden im Servicelebenszyklus: Wie lange stecken Ihre Services
in der Abnahme fest oder kommen wegen anderer Probleme (Bereitstellung, Sicherheitsauflagen und so weiter) nicht zum Einsatz? Wie
9780470483336.indb 81
18.02.2009 11:06:07 Uhr
könnten Sie Schritte automatisieren beziehungsweise mit Reports
oder Warnmeldungen auf blockierte Services hinweisen?
55 Anzahl der Schritte im Lebenszyklus: Ein optimaler Lebenszyklus
umfasst eher weniger Schritte als mehr.
55 Prozentuales Verhältnis zwischen neuen und wiederverwendeten
Services: Eine Verschiebung dieses Verhältnisses zugunsten der
Wiederverwendung ist ein guter Nutzen-Indikator.
55 Kosten eines neuen Service über seine gesamte Lebensdauer: Eine
allmähliche Verbesserung dieser Kennzahl zeigt die Dynamik, die Ihr
SOA-Lebenszyklus bereits entfaltet hat.
Diese Zahlen und Vorgaben werden die Entwickler allerdings erst dann
beeindrucken, wenn Sie gruppeninternen Wettbewerb, Leistungsbeurteilungen, Beförderungen und Prämien damit verknüpfen.
Kennzahlen für den
geschäftlichen Nutzen
Je mehr Projekte Sie durchführen, desto mehr Nutzen wollen Sie auch
nachweisen. Aber bevor Sie über geeignete Kennzahlen nachdenken, müssen Sie wissen, wie die Services genutzt werden.
Die folgenden Werte sollten sich mit fortschreitender SOA verbessern:
55 Anzahl wiederverwendbarer Services
55 Anzahl der Nutzeranwendungen pro Service
55 Anzahl der Anwender pro Nutzeranwendung
55 Nutzungsumfang pro Nutzer
55 Bewusstsein, dass wiederverwendbare Services vorhanden sind
55 Bereitschaft zur Servicenutzung
55 Anzahl definierter Anwendungsmuster
Wenn die Zahl der Services zunimmt, jeder Service von immer mehr Anwendungen verwendet wird und jede dieser Anwendungen immer mehr
Nutzer hat, steigt auch der Nutzen für das Geschäft. Noch größer wird
dieser, wenn Services in Prozessen und zusammengesetzten Anwendungen wiederverwendet werden.
9780470483336.indb 82
18.02.2009 11:06:07 Uhr
Leitlinien für den Organisationsbauplan
Nachdem nun die Kennzahlen für den IT- und den geschäftlichen Nutzen
feststehen, können Sie sich an die Veränderung der Strukturen machen
und damit die Weichen für die Erfüllung Ihres Organisationsbauplans stellen. Hierzu gehören Maßnahmen wie:
55 Umstrukturierungen
55 Änderungen am Gehaltssystem
55 Nachweis, dass Erfolge der IT-Abteilung auf SOA zurückgehen (anhand von Kennzahlen)
55 Training oder Neueinstellungen
55 Beförderungen und Kündigungen
55 Änderungen an Rollen und Stellenbeschreibungen
55 Änderungen am Finanzierungsmodell für gemeinsam genutzte IT
Jede dieser Maßnahmen könnte Ihre SOA-Einführung destabilisieren. Beobachten Sie deshalb genau, wie sich Maßnahmen auswirken, und ändern
oder verfeinern Sie sie.
Fallen Sie nicht auf den Irrglauben herein, dass Änderungen der Organi
sation sich nur auf das Geschäft und Änderungen an der Architektur sich
nur auf IT-Mitarbeiter auswirken. Sowohl in den Fachabteilungen als auch
in der IT muss die Motivation der Mitarbeiter stimmen, sonst ändern sie
ihr Verhalten nicht.
Den entscheidenden Schub bekommt Ihre SOA erst durch die Begeisterung, die sie im Unternehmen auslöst. Von ihr lassen sich die Mitarbeiter
aber nur anstecken, wenn sie Karrieremöglichkeiten sehen. Jeder, der
eine SOA einführen will, muss bei allen beteiligten Gruppen beständig ein
hohes Motivationsniveau aufrechterhalten.
Leitlinien für den Architekturbauplan
So wie strukturelle Änderungen zur Erfüllung des Organisationsbauplans
beitragen, helfen Maßnahmen auf Architekturebene bei der Umsetzung
des Architekturbauplans.
Geeignete Maßnahmen sind:
55 Einführung neuer Governance-Richtlinien
55 Erweiterung des SOA-Lebenszyklus um neue Phasen oder Schritte
55 Bedienung neuer Nutzeranforderungen
9780470483336.indb 83
18.02.2009 11:06:08 Uhr
55 Versionierung von Services
55 Änderungen an der Beschreibung oder Klassifizierung von Services
55 Änderungen am Architekturbauplan
Je mehr Richtlinien und Prozesse Sie im SOA-Lebenszyklus automatisieren, desto schneller kommen Sie Ihrem Architekturbauplan näher.
Richtig motivieren
So wie ein Raumschiff Schub braucht, um die Erdatmosphäre zu verlassen, so braucht Ihre SOA hohe Motivation, Unterstützung durch das Management und das nötige Budget, um schwerelos zu werden.
Mitarbeiter werden durch Geld, Unternehmensziele und die Anweisungen
ihres Chefs motiviert. Ohne klare Anreize gelingt eine SOA-Einführung
nicht. Wenn Entscheidungen getroffen werden, sind meist folgende Kräfte
am Werk:
55 Die Datenlage: »Dies ist korrekt.«
55 Der Chef: »Was ich sage, wird gemacht.«
55 Geld: »Dabei verdiene ich etwas.«
55 Pflicht: »Ich habe es versprochen.«
55 Gruppenzwang: »Die anderen machen es genauso.«
55 Freundschaft: »Weil ich dich nett finde.«
55 Konventionen: »So macht man das bei uns.«
Motivieren kann man auch, indem man zwischen Gruppen oder Einzelpersonen Wettbewerb erzeugt. Ein klares Verständnis der Verhaltensmuster
in einem Unternehmen und ihre gezielte Nutzung sind ein wichtiges Element der SOA-Einführung.
Die IT-Abteilung motivieren
Die meisten Entwickler können Vorschriften nicht ausstehen. Ihre Leidenschaft gilt der maßgeschneiderten Lösung eines konkreten Geschäftsproblems. Von Richtlinien und Wiederverwendung sind sie deshalb nur
mäßig begeistert.
Ihre Entwickler sind Profis, und als solche sollten Sie sie auch behandeln.
Begründen Sie jede verlangte Verhaltensänderung mit Kosten, Umsätzen,
Risiko oder anderen quantifizierbaren Größen. Automatisieren Sie Governance-Maßnahmen wo immer möglich und erleichtern Sie den Entwicklern die Einhaltung. Sorgen Sie dafür, dass die Entwickler im Kompetenz-
9780470483336.indb 84
18.02.2009 11:06:08 Uhr
zentrum einen durchsetzungsfähigen und redegewandten Vertreter
haben.
Das Management motivieren
Die Aufmerksamkeitsspanne von Führungskräften ist kurz. Seien Sie realistisch: Es dauert Jahre, bis der ganze SOA-Bauplan umgesetzt ist. Um
das nötige Budget zu erhalten und strukturelle Veränderungen mit der
notwendigen Autorität durchführen zu können, müssen Sie das Management von Ihrer Sache überzeugen.
Abbildung 10.2: Ein gängiges Business Intelligence Dashboard
Präsentieren Sie dem Management Ihre Zahlen mit Dashboards und nutzen Sie dafür Business-Intelligence-Software (siehe Abbildung 10.2). Geben Sie ihm die Möglichkeit, mit Ergebnissen aus Ihren Projekten eigene
fachliche Ziele voranzutreiben. Bitten Sie Ihren Vorgesetzten, auf Veranstaltungen über SOA zu sprechen.
9780470483336.indb 85
18.02.2009 11:06:08 Uhr
Die Fachabteilungen motivieren
Das Engagement der Fachabteilungen ist notwendig, um die Kosten der
SOA-Einführung aufzuteilen und die SOA mit fachlichen Zielen zu begründen.
Fachabteilungen teilen Daten höchst ungern mit anderen. Wiederverwendung mögen sie auch nicht, denn sie betrachten ihre Anforderungen als
nicht übertragbar. Erläutern Sie den Fachabteilungen, dass gerade eine
abstrakte Lösung ihnen heute und in Zukunft mehr Flexibilität verschafft.
Es müssen Mechanismen vorhanden sein, mit denen die Fachabteilungen
an den finanziellen Lasten und Vorteilen der gemeinsamen Infrastruktur
beteiligt werden. Stellen Sie den Nutzen des Systems so dar, dass Business-Experten ihn verstehen. Hierfür eignet sich zum Beispiel Software für
Business Activity Monitoring (BAM).
Alle anderen motivieren
Mit organisatorischen Maßnahmen – also Umstrukturierungen, Kostenverteilung und Prämien – können Sie das Unternehmen motivieren. Aber
ganz entscheidend ist auch, dass Sie sich als Vorreiter einer Bewegung
verstehen.
Profilieren Sie sich in Ihrer Branche als Botschafter Ihrer SOA. Halten Sie
Vorträge. Schreiben Sie einen oder zwei Artikel für eine Fachzeitschrift.
Verfassen Sie mit Ihrem Anbieter einen Anwenderbericht über Ihre SOA.
Nehmen Sie so viele Mitarbeiter wie möglich zu SOA-Fachtagungen mit.
Laden Sie externe Referenten ein, um die Diskussion im Unternehmen anzuregen. Bringen Sie Ihr Topmanagement dazu, innerhalb und außerhalb
des Unternehmens für Ihr SOA-Engagement zu werben. Es macht Eindruck, wenn sich Topmanager klar zu SOA bekennen.
Die schwerelose SOA erreichen
Von Serviceorientierung kann man von dem Moment an sprechen, wenn
die verschiedenen Interessengruppen die Bereiche Wiederverwendung,
Design, Bereitstellung, Änderungen und Tests nicht mehr unter dem Gesichtspunkt des maximalen Eigeninteresses angehen, sondern unter dem
Aspekt des Unternehmenswohls.
Dies zu erreichen ist eine große Aufgabe, denn es geht um nichts Geringeres, als zutiefst menschliche Verhaltensweisen zu ändern – und ein ganzes
System, in dem Machtkämpfe zwischen Gruppen zum Alltag gehören.
9780470483336.indb 86
18.02.2009 11:06:09 Uhr
Wenn Ihre SOA einen hohen Grad an Automatisierung erreicht hat, wird
Ihre IT-Abteilung so zusammenarbeiten wie ein Fußballteam: Jeder Spieler
beherrscht die Regeln im Schlaf, jeder hat das serviceorientierte Denken
und Handeln verinnerlicht und wendet es in jeder Situation an.
Die Reichweite Ihrer SOA
Die Reichweite Ihrer SOA bemisst sich daran, welchen Interessengruppen
sie entgegenkommt:
55 Einem einzigen Geschäftsbereich (plattformübergreifend)
55 Der zentralen IT (lebenszyklusübergreifend)
55 Der zentralen IT plus einem Geschäftsbereich
55 Mehreren Geschäftsbereichen plus der zentralen IT (Enterprise
SOA)
55 Geschäftsbereichen plus Kunden oder Lieferanten (B2B SOA)
55 Mehreren Unternehmen
Dies sind nur Beispiele, aber sie zeigen: Je mehr Interessengruppen abgedeckt sind, desto größer die Reichweite Ihrer SOA. Wenn nur eine Gruppe
berücksichtigt wird, zum Beispiel die Lobby eines bestimmten Anbieters
oder nur die Entwickler, handelt es sich nicht um eine SOA.
Austausch rund um SOA
Vielleicht haben wir jetzt Ihr Interesse am Austausch mit anderen SOA»Raumfahrtexperten« geweckt? Dann besuchen Sie unseren SOA-Adoption-Blog unter http://blog.softwareag.com.
9780470483336.indb 87
18.02.2009 11:06:09 Uhr
9780470483336.indb 88
18.02.2009 11:06:09 Uhr
Kapitel 11
Die SOA-Sterne erreichen
In diesem Kapitel
00
Konkrete Risiken der Gefahrenzone
00
Schwerelosigkeit erleben
00
Neue Galaxien erobern
I
n diesem Kapitel geht es um die Risiken, denen die SOA in der Gefahrenzone ausgesetzt ist. Je mehr Sie über die Risiken einer SOA-Einführung wissen, desto erfolgreicher können Sie die Prinzipien des SOA-Raumfahrtprogramms umsetzen.
Die Gefahrenzone überwinden
Mit den drei Prinzipien des SOA-Raumfahrtprogramms kommen Sie sicher
durch die Gefahrenzone. Je besser Sie wissen, welche konkreten Risiken
drohen, desto gezielter können Sie sie bei Ihren Projekten vermeiden.
SOA-Fallstricke
Ein Risikobereich ist das SOA-Kompetenzzentrum selbst beziehungsweise
das, was es tut. Es kann zum Beispiel bei der Implementierung oder bei
der Entwicklung der SOA-Baupläne Fehler machen.
55 Implementierungsfehler: Das kontinuierliche Messen und Korrigieren des SOA-Raumfahrtprogramms ist dazu gedacht, solchen
Fehlern vorzubeugen beziehungsweise sie zu entschärfen. Kommt
es dennoch dazu, müsste sich das in den Kennzahlen zur Wiederverwendung, Interoperabilität und Performance niederschlagen.
Solche Fehler müssen korrigiert werden, bevor das Projekt an ihnen
scheitert.
9780470483336.indb 89
18.02.2009 11:06:09 Uhr
55 Fehler bei der Architektur: Diese können ein SOA-Projekt (oder -pilotprojekt) zunichtemachen. Aber wenn Erfahrungen aus einem Projekt in das nächste einfließen, kann das Unternehmen aus Fehlern
lernen und sie auf Dauer unterbinden. Ein gescheitertes Projekt kann
die SOA-Motivation der Mitarbeiter allerdings stark beschädigen.
Wenn man sich bewusst ist, dass ein Pilotprojekt auch scheitern kann,
wird man die Erwartungen realistisch ansetzen und die Kräfte, die am
SOA-Raumschiff rütteln, leichter abwehren.
Die lange Reise zu den SOA-Sternen
Bis ein Raumschiff die Erdanziehung überwunden hat, ist es acht Minuten
unterwegs. Bei einer SOA dauert diese Reise leider Monate, wenn nicht
gar Jahre. Das liegt daran, dass eine SOA erst eine kritische Masse von
Services benötigt, bevor man Anwendungen oder Prozesse zusammensetzen und von der daraus resultierenden Flexibilität profitieren kann. Und
es braucht einfach seine Zeit, bis sich eine IT-Abteilung an die neuen Anforderungen des SOA-Zyklus gewöhnt hat. In diesem Zeitraum kann Folgendes eintreten:
55 SOA-Müdigkeit: Die Dauer und Komplexität einer SOA-Einführung
kann eine Organisation mittelfristig ermüden. Dieser Ermüdung können Sie begegnen, indem Sie bei jedem Projekt einen ROI (Return on
Investment) nachweisen und die Beteiligten immer wieder motivieren.
55 Wechsel von Führungskräften: Auf dem langen Weg zur SOA können
Mitarbeiter ausscheiden – sie werden entlassen, finden eine bessere
Stelle oder gehen in den Ruhestand. Alles ist möglich! Dies kann
einen herben Rückschlag bedeuten, aber mit einer gemeinsamen Vision und einem engagierten Team werden Sie solche Veränderungen
meistern.
55 Anbieterprobleme: Softwareanbieter verkaufen ihr Paket, das auch
Komponenten von Drittanbietern enthält, manchmal als SOA-Lösung
aus einer Hand. Zur eigenen Gewinnmaximierung gehen sie dann
aber andere Allianzen ein und bieten nicht mehr die ursprünglich
versprochene Flexibilität und Interoperabilität.
55 Beraterprobleme: Berater wollen die Kontrolle behalten und möglichst viele Stunden abrechnen. Eine SOA kann dies begünstigen
oder dem entgegenwirken. Rechnen Sie damit, dass die Berater ihre
Jagdgründe verteidigen oder vergrößern wollen.
55 Probleme bei den SOA-Akteuren: Wenn die Einhaltung der Richtlinien nicht immer wieder belohnt wird, könnten Entwickler oder
andere wichtige Akteure aktiv oder passiv rebellieren.
9780470483336.indb 90
18.02.2009 11:06:09 Uhr
Kapitel 11: Die SOA-Sterne erreichen 91
55 Finanzierungsstopp: Wenn das Management längere Zeit keinen
messbaren geschäftlichen Nutzen erkennen kann, dreht es Ihrem
SOA-Programm möglicherweise den Geldhahn zu. Messen Sie das,
was Ihrem Management am wichtigsten ist, und sorgen Sie dafür,
dass Ihr SOA-Projekt die Leistungsvorgaben einhält.
Diesen Risiken begegnen Sie am besten, indem Sie kontinuierlich die ITund Geschäftskennzahlen kontrollieren. Mit realistischen Erwartungen
und einer geschickten Darstellung der positiven Auswirkungen auf das
Geschäft gelingt es Ihnen leichter, die SOA-Begeisterung beim Implementierungsteam, bei Budgetgebern und anderen wichtigen Akteuren im Unternehmen aufrechtzuerhalten.
Schwerelosigkeit erleben
Angesichts dieser Risiken fragen Sie sich vielleicht, ob eine SOA-Einführung wirklich das Richtige für Sie ist.
Bedenken Sie, dass schon relativ wenige wiederverwendbare Komponenten zu vielen Kombinationen zusammengesetzt werden können – so wie
die 26 Buchstaben des Alphabets dieses Buch ermöglicht haben. Aus den
ersten Gehversuchen Ihrer SOA werden bald zielstrebige Schritte, und
bald werden Ihre Prozesse das Laufen gelernt haben. Die Prozesse können
dann so schnell geändert werden, wie das Geschäft es erfordert. Ein lang
gehegter Traum, der kontinuierliche Verbesserungsprozess (KVP), geht
damit in Erfüllung.
Die Einführung einer SOA ist schwierig. Wenn man sich vorgenommen
hat, die technische und organisatorische Zersiedelung umzukehren, lassen sich Schwierigkeiten gar nicht vermeiden. Unternehmen, die sie meistern, werden die Markteinführung ihrer Produkte und Dienstleistungen
beschleunigen, den Kundenservice verbessern und Kunden besser an
sich binden. Sie werden übernommene Firmen besser integrieren und die
Kosten und Risiken ihrer Aktivitäten senken. Kurzum, sie werden es besser machen als der Wettbewerb.
Vorstoß in neue Galaxien
Häufig fragt man uns, was denn nach SOA kommen wird. Bei den Architekturen ist ein Trend zur ereignisgesteuerten Architektur (Event-Driven Architecture, EDA) erkennbar, der auch Anwendungen für komplexe Ereignisverarbeitung (Complex Event Processing, CEP) beinhaltet. Die Designprinzipien von EDA sind unseres Erachtens mit SOA vereinbar, da sie auf
9780470483336.indb 91
18.02.2009 11:06:09 Uhr
Nachrichten und auf den Umgang der Systeme mit diesen Nachrichten
ausgerichtet sind. Wir wünschen uns, dass Architekten diesen Trend berücksichtigen und erkennen, dass der Einsatz ereignisgesteuerter Anwendungen in einer gut entworfenen SOA nicht ausgeschlossen ist.
Hosting, Software as a Service (SaaS), Platform as a Service (PaaS) oder
Cloud Computing sind ebenfalls wichtige Trends. Mit einer SOA wird Ihr
Unternehmen in der Lage sein, Prozesse über unterschiedlichste On-Premise- und Off-Premise-Dienste hinweg zu nutzen, zusammenzustellen und
zu entwerfen. Manche Experten orakeln zwar, dass bald sämtliche IT-Services ausgelagert sein werden. Wir meinen jedoch, dass erfolgreiche Unternehmen nicht nur Off-Premise-Services in Anspruch nehmen werden,
sondern sie an Verbraucher, Firmenkunden und Vertriebspartner weitergeben und damit signifikante Umsätze erzielen werden. Manche Unternehmen bieten bereits eine PaaS-Funktion an, mit denen Kunden Funktionen
neu kombinieren können. Daraus ergeben sich Hunderte von Möglichkeiten für neue Geschäfte.
Mit der Einführung einer SOA bereiten Sie Ihre zentralen Systeme auf
diese dynamischen Zukunftstechnologien vor. Damit ist sie ein Schritt in
die richtige Richtung.
9780470483336.indb 92
18.02.2009 11:06:09 Uhr
Software AG ist der weltweit größte unabhängige Anbieter von
Infrastruktursoftware für Geschäftsprozesse. Durch die Moderni
sierung, Automatisierung und Optimierung ihrer vorhandenen
IT-Systeme und -Prozesse erreichen unsere 4.000 Kunden ihre
Geschäftsziele schneller, schaffen sichtbare Werte und reagieren
flexibel auf veränderte Geschäftsanforderungen. Mit den Lösungen
von Software AG öffnen und steuern Unternehmen Informationen,
Systeme, Applikationen, Prozesse und Services und erreichen einen hohen Automatisierungsgrad und durchgängige Transparenz.
Unser Produktportfolio umfasst marktführende Lösungen für das
Datenmanagement, die Erstellung und Modernisierung von Anwendungen, serviceorientierte Architekturen und die Optimierung von
Geschäftsprozessen. Wir verbinden leistungsfähige Technologie
mit Branchen-Know-how und bewährten Best Practices und helfen damit unseren Kunden, ihre Unternehmensziele schneller zu
erreichen.
Software AG − Get There Faster
9780470483336.indb 95
18.02.2009 11:06:09 Uhr
Informationen zum Thema SOA –
schnell, unkompliziert, kostenlos
Erfahren Sie, welchen
Nutzen Sie mit SOA
erzielen können:
Autorenblog. Nutzen Sie diesen Blog, um den Autoren von SOA-Einführung
für Dummies Fragen zu stellen oder sich mit Kollegen zu diesem Thema
auszutauschen. Oder stöbern Sie einfach nach Meinungen, Ideen,
Strategien …
http://blog.softwareag.com
In zehn Minuten wissen Sie, ob Ihr Unternehmen die Voraussetzungen
für SOA erfüllt. Sie erfahren, in welchen Bereichen Sie schon gut für eine
SOA-Einführung aufgestellt sind und welche Aufgaben Sie noch lösen
müssen.
www.soatechnologyassessment.com
Errechnen Sie den Nutzen von SOA. Finden Sie heraus, wo SOA in Ihrem
Unternehmen die größte Wirkung erzielt und wie Sie die Finanzierung Ihres
SOA-Projektes sichern.
www.soavalueassessment.com
Analystenstudien zum SOA-Markt. Diese Untersuchungen führender
Analysten vergleichen verschiedene Anbieter und analysieren deren
Kompetenz bei der Umsetzung serviceorientierter Architekturen.
http://info.softwareag.com/lp/softwareag/SOA_Analyst.html
Mit dem richtigen Instrumentarium wird Ihre SOA-Einführung ein Erfolg.
Mehr dazu unter www.softwareag.com
09_0304_VCH_Anzeige_Software_Ag_1 1
02309312 14:42:27 Uhr
Unter
Wie Sie mit SOA
www.soaadoptionfordummies.com
finden Sie viele weitere
Informationen
Ihre Geschäftsprobleme
lösen
Sie
erfahren:
Wie Sie mit SOA Geschäftsprobleme lösen
Wie Sie SOA-Baupläne
umsetzen
Mit diesem Buch
gelingt die SOA-Einführung!
Gegenstand dieses Buches ist nicht die Architektur selbst. Zu
diesem Thema gibt es mittlerweile genügend Literatur. In diesem
Buch geht es um die SOA-Einführung, um handfeste, praktische
Methoden, die Ihnen bei der Umsetzung Ihrer SOA-Pläne helfen.
Wir stellen Ihnen unser »SOA-Raumfahrtprogramm« vor.
So nennen wir unsere Methode, mit der wir Ihre SOA-Projekte
durch die Gefahrenzone steuern, eins nach dem anderen, ganz
behutsam – damit Sie Ihre Ziele sicher erreichen.
Fach-Chinesisch
Erklärungen ohne
m Ausprobieren
Tipps und Tricks zu
Symbolen
Durchblicken mit
melseite
Handliche Schum
Top-Ten-Listen
und Spaß
Eine Prise Humor
ISBN 978-0-470-48333-6
Nicht zum Verkauf
Wie Sie Richtlinien entwerfen, mit denen Sie das
Wachstum und die Nutzung
Ihrer Services steuern
SOAg
n
u
r
h
ü
Einf
ftware AG
Sonderausgabe So
Machen Sie
sich schlau!
Ihr Unternehmen
Flexibilität
www.fuer-dummies.de
Hier finden Sie alle
unsere Bücher
für Dummies
Wählen Sie aus vielen
verschiedenen
Themengebieten
Download von Probekapiteln, Inhalts- und
Stichwortverzeichnissen
Für Dummies®
Eine Marke von
So führen Sie
Kontrolle
Rendite
Organisation und Motivation
Miko Matsumura
Björn Brauel
Jignesh Shah
sicher zum Ziel!

SOA- Einführung

Transcrição

Documentos relacionados

Vortragsprogramm - CeBIT ERP

RDS einsetzen - softwareschule.ch

Optimieren Sie Ihr Business!

Besprechung der neuen Snowboards für Winter 2013/14

NEWSFlash - Tech Data

MARLEN NEWS 04/10 - Blitzende Luxuskarossen und ein Wok

Lebensläufe im Wandel

Verkabelung von Datenübertragungsanlagen 12 - vh

Hartz IV ist kein Schicksal - Verlag J.H.W. Dietz Nachf.

2. Stromlaufplan der Kühlanlage - vh