|
|
SOA Manifest: Prinzipien |
Nach dem Wertesystem folgen die 14 Prinzipien des SOA-Manifests. Die Prinzipien selbst sind unterschiedlich formuliert. Manche Prinzipien werden als Ratschlag oder "Handlungsanweisung" formuliert. Es geht also um etwas, was man tun oder lassen sollte. Andere Prinzipien halten dagegen einfach nur Tatsachen fest, die im Umfeld einer SOA-Strategie zu berücksichtigen sind. Diese Tatsachen sind letztlich auch Ratschläge, indem implizit empfohlen wird, sie nicht außer Acht zu lassen.
Thematisch habe ich diese Prinzipien in verschiedene Gruppen unterteilt, weil mehrere Prinzipien mitunter zu einem gemeinsamen Thema gehören:
Organisatorische SOA-Prinzipien
Prinzipien zu Produkten und Standards
Heterogenität und Harmonisierung
Sonstige SOA-Prinzipien (Trennung von Zuständigkeiten, lose Kopplung, Service-Kataloge)
Eine derartige Gruppierung ist allerdings nicht Teil des Manifests. Im Manifest werden die 14 Prinzipien einfach nur hintereinander aufgelistet. Pro Gruppe werde ich nachfolgend mit dem englischen Original beginnen und danach die deutsche Übersetzung diskutieren.
Respect the social and power structure of
the organization.Recognize that SOA ultimately demands
change on many levels.The scope of SOA adoption can vary. Keep
efforts manageable and within meaningful
boundaries.
Die ersten drei Prinzipien haben im weitesten Sinne etwas mit dem Umfang und den Auswirkungen von SOA auf organisatorischer Ebene zu tun. Für eine SOA-Strategie sind dies also wichtige Punkte, die auch im Topmanagement von Unternehmen eine Rolle spielen:
Respektiere die Sozial- und Machtstruktur der Organisation.
Erkenne an, dass SOA letztlich Veränderung auf vielen Ebenen bedeutet.
Der Bereich, in dem SOA eingeführt wird, kann unterschiedlich ausfallen. Halte die Aufwände in einem überschaubaren und sinnvollen Rahmen.
Das erste Prinzip besagt, dass man bei der Einführung von SOA die existierenden Strukturen einer Organisation berücksichtigen muss (was sicherlich für die Umsetzung jeglicher Strategie gilt). Dies bedeutet, dass in verschiedenen Umgebungen SOA nicht unbedingt dasselbe bedeutet. Je nach vorhandenen Strukturen wird die Umsetzung von SOA unterschiedlich ausfallen.
Das zweite Prinzip weist darauf hin, dass die Auswirkungen von SOA sehr viel größer sein können, als es zunächst scheint. Es geht nicht nur um eine neue Technologie. Es geht auch um Veränderungen bei Prozessen, in der Unternehmenskultur, im Machtgefüge und bei den persönlichen Einstellungen.
Wenn diese Veränderungen nicht möglich sind, kann das zum Problem werden. So ist es relativ unstrittig, dass Zusammenarbeit ein wesentlicher Erfolgsfaktor für die Umsetzung von SOA ist. Isolierte monolithische Systeme werden durch ein Zusammenspiel vieler verschiedener Systeme abgelöst. Das ist aber keineswegs nur ein technisches Problem. Verteilung funktioniert nur dann, wenn eine Unternehmenskultur existiert, die Zusammenarbeit unterstützt. SOA kann deshalb durchaus auch als Problemdetektor dienen, weil dadurch aufgezeigt wird, ob in einem Unternehmen eine Kultur der Zusammenarbeit wirklich etabliert ist. Früher oder später wird SOA damit zur "Chefsache".
Im dritten Prinzip geht es schließlich um die Frage, auf welchen Geltungsbereich sich eine Einführung von SOA bezieht. Es ist keineswegs immer nur ein Unternehmen, das SOA einführt, und selbst wenn das so ist, gibt es erhebliche Unterschiede (wie das erste Prinzip besagt). Man kann SOA-Prinzipien aber auch in Teams oder im Rahmen eines bestimmten Projekts einführen. Es kann sich um ein lokales System, um ein Vorhaben zwischen verschiedenen Teams oder Systemen, eine Unternehmensstrategie oder um einen Ansatz für eine firmenübergreifende Systemlandschaft handeln. Und natürlich wird sich der Bereich mit der Zeit verändern (wenn es gut läuft, trägt das Prinzip Früchte, sodass sich der Geltungsbereich ausdehnt).
Wie auch immer der Bereich aussieht, um den es geht, das Ganze sollte beherrschbar bleiben. Ein großer "Big-Bang"-Ansatz ist da eher ein Rezept für ein Desaster. Gemäß der letzten Aussage des Wertesystems ist eine schrittweise Einführung von SOA angeraten.
Überspitzt kann man diese drei Prinzipien auch wie folgt zusammenfassen: Unterstütze die Einführung von oben, aber fange von unten an ("Support top-down, but establish bottom-up").
Products and standards alone will neither
give you SOA nor apply the service
orientation paradigm for you.SOA can be realized through a variety of
technologies and standards.Establish a uniform set of enterprise
standards and policies based on industry,
de facto, and community standards.
Bei diesen drei Prinzipien geht es um die Rolle von Produkten, Technologien und Standards:
Produkte und Standards alleine werden weder SOA liefern noch das Service-orientierte Paradigma umsetzen.
SOA kann mit unterschiedlichen Technologien und Standards umgesetzt werden.
Etabliere einheitliche Unternehmensstandards und -richtlinien auf der Basis von Industrie- und De-facto-Standards sowie Standards der SOA-Gemeinde.
Hinter dem ersten dieser Prinzipien steckt im Grunde der Satz "SOA kann man nicht kaufen". SOA etabliert man auch nicht dadurch, dass man einfach Standards folgt. Zu SOA gehört sehr viel mehr, da es auch um Prozesse, Strukturen, Kulturen und so weiter geht, die angemessen erstellt bzw. berücksichtigt werden müssen.
Das bedeutet nicht, dass Produkte und Standards dabei nicht helfen können. Das Wort "alleine" ist also wichtig bei diesem Prinzip (Tool-Hersteller werden sicherlich darauf hinweisen).
Allerdings gibt es gemäß dem zweiten Prinzip hier bei den Technologien und Standards (und damit bei den damit verbundenen Produkten) ein großes Spektrum von Möglichkeiten. Es gibt leider nicht die eine, einzig wahre Möglichkeit, SOA umzusetzen. Der Streit zwischen Web-Services und REST wird durch das Manifest also nicht entschieden, und Entscheidungen wie "synchron oder asynchron" müssen nach wie vor selbst getroffen werden (genau genommen wird man in der Praxis früher oder später alles davon vorfinden, denn die Welt ist nun einmal heterogen, worauf das nächste Prinzip nach dieser Gruppe noch eingehen wird).
Zum Thema Standards liefert das dritte Prinzip dieser Gruppe noch einige wichtige Hinweise. Zum einen wird festgehalten, dass es viele davon gibt: Industriestandards, Standards, die sich de facto einfach durchgesetzt haben, und Standards, die aus der "SOA-Gemeinde" kommen, also aus den verschiedenen Kreisen, mit denen man es im Rahmen von SOA zu tun hat.
In Summe sind dies allerdings so
viele Standards, dass man unmöglich alle diese Standards befolgen kann
(zumal es auch Widersprüche gibt). Alleine die Standardtechnologie der
Web-Services umfasst je nach Zählweise zwischen 50 und 100 verschiedene
Standards, die von verschiedenen Organisationen und Personengruppen gepflegt
werden. Man sollte und muss sich deshalb aus all diesen Standards seinen eigenen
Satz von Standards und Richtlinien heraussuchen, die dann unternehmensweit umgesetzt
werden. Dass diese "hauseigenen" Richtlinien bei übergreifenden
Funktionalitäten dann ggf. mit Richtlinien anderer Firmen kollidieren,
lässt dieses Spiel von Neuem beginnen. Auch bei Standards haben wir also
eine Welt voller Vielfalt und Unterschiede, was uns zum nächsten Prinzip
führt.
Pursue uniformity on the outside while
allowing diversity on the inside.
In diesem Prinzip geht es um die Themen Heterogenität und Harmonisierung:
Strebe nach außen Einheitlichkeit an, aber lasse nach innen Vielfalt zu.
Heutzutage muss man einfach akzeptieren, dass unsere Welt ab einer gewissen Größe heterogen ist. Der übliche Versuch, Probleme durch Harmonisierung zu lösen (nur noch eine einheitliche Plattform, nur noch ein gemeinsames Geschäftsobjektmodell, nur ein ESB und so weiter) ist im Kontext größerer Systeme bzw. Systemlandschaften, über die verteilte Geschäftsprozesse realisiert werden, im Grunde keine Option mehr. Auf der anderen Seite ist Harmonisierung wichtig, denn nur so entstehen Synergieeffekte und nur auf Basis einer gewissen Harmonisierung kann man übergreifende Interoperabilität schaffen und verwalten.
Die hier in diesem Prinzip gewählte Formulierung soll dies zum Ausdruck bringen. Es handelt sich um eine etwas schärfere Formulierung als "Finde die richtige Balance zwischen Vereinheitlichung und Vielfalt", was auch als Text für dieses Prinzip diskutiert wurde.
Man beachte, dass die Begriffe "innen" und "außen" relativ sind. Dies trägt insbesondere der Tatsache Rechnung, dass eine Harmonisierung auf bestimmter Ebene eine Ebene höher wiederum nur eine von vielen möglichen Optionen darstellt. Nehmen wir zum Beispiel die Vereinheitlichung von Technologien und Richtlinien, wie sie etwa durch Einführung eines ESB oder durch einen Unternehmensstandard erfolgen kann. Wenn eine derartige Regelung für ein Unternehmen eingeführt und durchgesetzt wird, wird damit eine Vereinheitlichung erreicht, die Interoperabilität massiv unterstützt. Man muss aber immer darauf vorbereitet sein, in einem größeren Kontext, also firmenübergreifend, dann wiederum unterschiedliche Technologien und Richtlinien zu haben. Dieses Prinzip gilt insbesondere auch zeitlich. Jede Regelung und jeder Standard wird über die Zeit durch etwas Neues abgelöst werden. Zumindest für eine Übergangszeit existiert dann eine Vielfalt, mit der man umgehen muss. Tappen Sie also nicht in die Falle, zu meinen, dass mit Einführung eines ESB oder von Web-Services-Standards das Thema Interoperabilität ein für allemal erledigt ist.
Bei der Verabschiedung des Manifests wurde auch diskutiert, ob dieses Prinzip nicht sogar eine Aussage zum Wertesystem sein sollte, aber mein Vorschlag "Akzeptiere Vielfalt über Forcierung von Harmonisierung" konnte sich nicht durchsetzen.
Identify services through collaboration with
business and technology stakeholders.Maximize service usage by considering the
current and future scope of utilization.Verify that services satisfy business
requirements and goals.Evolve services and their organization in
response to real use.
In diesen vier Prinzipien geht es um Services:
Identifiziere Services durch Zusammenarbeit zwischen fachlichen und technischen Interessenvertretern.
Maximiere die Anwendbarkeit von Services durch Berücksichtigung der derzeitigen und zukünftigen Anwendungsgebiete.
Stelle sicher, dass Services fachlichen Anforderungen und Zielen dienen.
Services und deren Ausgestaltung sollten sich anhand der Art und Weise, wie sie wirklich genutzt werden, entwickeln.
Diese vier Prinzipien klingen zum Teil ähnlich, zum Teil aber auch widersprüchlich. Eines ist zunächst klar: Es geht, wie auch schon in der Präambel und im Wertesystem formuliert, immer darum, dass Services kein Selbstzweck sind. Sie entstehen durch Abstimmung mit den Fachseiten, sollen fachliche Anforderungen und Ziele erfüllen und sich an wirklich existierenden Anwendungsfällen orientieren.
Das erste Prinzip dieser Gruppe weist aber auch darauf hin, dass technische Aspekte berücksichtigt werden. Fachliche und technische Interessenvertreter (es wurde bewusst nicht das Wort "Experten" gewählt) müssen zusammenarbeiten.
Aber dann gibt es den Widerspruch zwischen dem zweiten und vierten Prinzip dieser Gruppe:
Nun, beides ist sicherlich richtig, und es läuft darauf hinaus, dass man in der Praxis das richtige Maß finden muss. Wie schon bei der vierten Werteaussage am Beispiel eines Adress-Service erläutert, trägt die Anreicherung eines Service für absehbare zukünftige Anwendungsfälle sicherlich zu seiner Wiederverwendbarkeit bei. Aber gleich einen Service zu entwerfen, der alle möglichen denkbaren zukünftigen Szenarien abdeckt, ist sicherlich nicht die richtige Herangehensweise. Zumal dies ja auch die Komplexität erhöht und die Performance negativ beeinflussen kann.
Was im Rahmen von zukünftigen Anforderungen auf einen Service zukommt (dazu gehört unter anderem, um welche Daten es geht und wie diese geschnitten sind), kann und wird sich erst mit der Zeit herausstellen. Mit jeder neuen Anforderung muss letztlich wieder die Frage beantwortet werden, ob dafür ein existierender Service ausreicht, erweitert werden oder ein neuer Service geschaffen werden muss. Dies ist das Prinzip Evolution, das gemäß der letzten Aussage des Wertesystems priorisiert wurde.
Separate the different aspects of a system
that change at different rates.Reduce implicit dependencies and publish
all external dependencies to increase
robustness and reduce the impact of change.At every level of abstraction, organize each
service around a cohesive and manageable
unit of functionality.
Diese letzten drei Prinzipien beschäftigen sich mit drei Schlüssel-Konzepten von SOA:
Trenne die verschiedenen Aspekte eines Systems, die sich unterschiedlich häufig ändern.
Reduziere implizite Abhängigkeiten und publiziere alle externen Abhängigkeiten, um Robustheit zu fördern und die Auswirkungen von Veränderungen zu reduzieren.
Organisiere jeden Service auf jeder Abstraktionsebene in oder anhand einer zusammenhängenden und überschaubaren Funktionseinheit.
Im ersten dieser Prinzipien geht es um das Prinzip "separation of concerns" also um die Trennung von Zuständigkeiten. Dieses Prinzip gilt sicherlich auch im Rahmen von SOA. Durch Services (wohldefinierte Schnittstellen) trennen wir zum Beispiel Funktionalität und Fachlichkeit von deren Implementierung, was wichtig ist, weil Änderungen an der Implementierung und Änderungen am Verhalten nicht unbedingt zur selben Zeit benötigt werden. Dieses Prinzip ist auch einer der Gründe, zwischen den Themen Interoperabilität und Fachlichkeit besser sauber zu trennen. Business-Logik in einen ESB unterzubringen, führt über kurz oder lang zu etlichen Problemen.
Im zweiten dieser Prinzipien geht es um lose Kopplung. Lose Kopplung ist wichtig, um die Auswirkungen von Ausfällen und Veränderungen zu reduzieren. Allerdings bleiben sicherlich immer auch Abhängigkeiten erhalten. Wenn diese nach außen eine Rolle spielen, sollten sie explizit bekannt gemacht werden.
An dieser Stelle fehlt im Manifest vielleicht der Hinweis, dass auch lose Kopplung kein Selbstzweck ist, da man immer einen Preis dafür zahlt. Da man aber im Prinzip für alles im Leben einen Preis bezahlt, wurde ein derartiger Hinweis im SOA-Manifest nicht aufgenommen (ich hätte ihn gerne gehabt).
Das letzte Prinzip behandelt schließlich das Thema der Verwaltung von Services, also das abstrakte Konzept der Föderation (engl.: federation), das in der Praxis vor allem unter den Begriffen "Repository" und "Registry" bekannt ist. Derartige Funktionseinheiten helfen, um beim Umgang mit Services nicht den Überblick zu verlieren. Sie können aber, wie man an der Formulierung des Prinzips erkennen kann, durchaus verteilt sein und müssen natürlich auch nicht unbedingt Kaufprodukte sein. Wichtig ist, dass eine Möglichkeit geschaffen wird, die Services auf den verschiedenen Ebenen als Ganzes überblicken zu können.
