SOA Manifest: Wertesystem

Nach der Präambel folgen die Aussagen zum Wertesystem das gemäß SOA-Manifest mit SOA verbunden wird:

Through our work we have come to prioritize:

  Business value over technical strategy
  Strategic goals over project-specific benefits
  Intrinsic interoperability over custom integration
  Shared services over specific-purpose implementations
  Flexibility over optimization
  Evolutionary refinement over pursuit of initial perfection

That is, while we value the items on the right, we value the items on the left more.

Dieses Wertesystem wird in einem besonderen Format definiert, das vom Agilen Manifest übernommen wurde. Der erste und der letzte Satz rahmen dabei sechs zentrale Aussagen zum Wertesystem ein und erläutern, wie diese Aussagen zu verstehen sind:

Im Rahmen unserer Arbeit sind wir zu folgender Priorisierung gekommen:
...
Das heißt, obwohl wir die Werte auf der rechten Seite schätzen, sind uns die Werte auf der linken Seite wichtiger.

Es geht also um eine Priorisierung von Werten, die im Rahmen von SOA eine Rolle spielen. Alle diese Werte sind wichtig und gut. Die Werte auf der rechten Seite sind also nicht Werte, die wir nicht unterstützen. Es geht um die Frage, welchen Werten wir im Zweifelsfall den Vorzug geben (wenn wir uns also zwischen den Werten entscheiden müssen). In dem Fall stehen die Werte auf der linken Seite bei der Umsetzung von SOA im Vordergrund.

In der Mitte folgen dann die verschiedenen Werte-Aussagen, die nachfolgend erläutert werden:

Geschäftswert über technische Strategie

Strategische Ziele über projektspezifischen Nutzen

Immanente Interoperabilität über maßgeschneiderte Integration

Gemeinsam verwendete Services über zweckgebundene Implementierungen

Flexibilität über Optimierung

Evolutionäre Vervollkommnung über Streben nach anfänglicher Perfektion

Die erste Aussage zum Wertesystem lautet:

Geschäftswert über technische Strategie

Zunächst bedeutet diese Aussage, dass beides, Geschäftswert und technische Strategien, Werte sind, die wir verfolgen und für sinnvoll halten. Technische Strategien sind also gut und wichtig, wie immer sie auch lauten. Noch wichtiger ist es allerdings, Geschäftswert zu liefern. Wie bereits in der Präambel formuliert wurde, geht es in erster Linie darum, mit SOA einen Mehrwert zu schaffen. Kunden, Anwendern, Auftraggebern muss (für ihr Geld) etwas geliefert werden, das eine nützliche und hilfreiche Verbesserung darstellt. Dies sollte natürlich immer der Fall sein und nicht nur im Umfeld von SOA gelten. Aber auch und insbesondere für SOA ist diese Aussage wichtig, denn in unserem Business wird ganz gerne übersehen, dass wir Technologien nicht zum Selbstzweck einführen sollten.

Da man SOA als technische Strategie betrachten kann, bedeutet diese Aussage auch, dass SOA kein Selbstzweck sein sollte. Das SOA-Manifest rät also im Zweifelsfall von SOA ab. Dies ist ein kleines Paradoxon: Wer diesem Prinzip folgt, beherzigt also den Rat, diesen empfohlenen Prinzipien im Zweifelsfall nicht zu folgen. In gewissem Sinne von sich selbst abzuraten ist übrigens auch ein Element des Agilen Manifests, denn die erste Aussage zum agilen Wertesystem lautet "Individuen und Interaktion über Prozesse und Werkzeuge" (engl.: "Individuals and interactions over processes and tools"), was im Zweifelsfall agile Prozesse infrage stellt.

Für mich ist ein derartiges Infragestellen der eigenen Werte und Prinzipien wesentlich. Hinterfragen ist immer wichtiger, als einer Idee einfach nur blind zu folgen. Im Grunde ist es völlig egal, ob man SOA macht oder nicht. Das Einzige, was zählt, ist, ob das, was man macht, sinnvoll und angemessen ist.

Die zweite Aussage zum Wertesystem lautet:

Strategische Ziele über projektspezifischen Nutzen

Hier gehen wir eine Stufe tiefer und stellen heraus, dass uns im Zweifelsfall strategische Ziele wichtiger sind als der Nutzen für ein spezifisches Projekt. Es geht also um projektübergreifende Nachhaltigkeit. Wie gesagt ist uns der Wert auf der rechten Seite auch wichtig. Natürlich ist in jedem Projekt alles wichtig, was diesem Projekt hilft und es weiterbringt. Falls der Nutzen für ein konkretes Projekt aber in Konflikt zu strategischen Zielen steht, sind uns diese strategischen Ziele wichtiger.
Diese Priorisierung regelt eine Situation, die im Alltag von Projekten immer wieder vorkommt. Gehen wir den billigeren Weg, der für ein Projekt eine schnelle und durchaus passende Lösung liefert, oder nehmen wir mehr Geld und Ressourcen zur Erfüllung der strategischen Ziele in die Hand? Es geht im Grunde um ein Bekenntnis zu Investitionen, die sich langfristig bezahlt machen.

Der Preis für langfristiges Handeln ist dabei nicht zu unterschätzen. Ich verweise hier auf Fred Brooks, der schon vor über 30 Jahren in [Brooks75] für die Integration eines Produkts in ein Gesamtsystem als Faustformel einen Faktor von 3 angesetzt hat (zusammen mit dem Faktor 3 für die Wartbarkeit durch verschiedene Personen ergab sich ein Faktor von 9 für ein Produkt, das integriert und wartbar ist).

Konkrete Beispiele für derartige Zielkonflikte gibt es bei SOA zuhauf. Eine der typischsten ist die Entscheidung, am Anfang in eine Abstraktionsschicht von Services und einen dazugehörigen Service-Bus zu investieren, anstatt zwei Systeme einfach direkt mit Mitteln zu verbinden, die "out of the box" zur Verfügung stehen. Denkt jedes Projekt nur an sich, hat man irgendwann eine nicht mehr wartbare Anzahl von individuellen Verbindungen zwischen einzelnen Systemen. Mit mehr Investition, hat man zumindest aus technischer Sicht eine gewisse Vereinheitlichung, die die Wartung und Nutzung von Services in anderen Kontexten erleichtert.

Die ersten beiden Aussagen zum Wertesystem kann man natürlich auch kombinieren, denn das Wort Strategie steht in der ersten Aussage auf der rechten und in der zweiten Aussage auf der linken Seite. Zusammen ergibt sich folgende überspitzt formulierte Priorisierung: Projekte sind uns wichtig, noch wichtiger sind aber Strategien, und am wichtigsten ist der Mehrwert für unser Geschäft.

Die restlichen vier Aussagen werden etwas konkreter und beschäftigen sich mit Begriffen, die bei der Umsetzung von SOA immer wieder im Vordergrund stehen.

Die dritte Aussage zum Wertesystem lautet:

Immanente Interoperabilität über maßgeschneiderte Integration

Hier geht es um das Thema Interoperabilität, also die Frage, wie einfach Systeme miteinander verknüpft werden, um von einem System jeweils die Fähigkeiten eines anderen Systems zu nutzen. Der Wert auf der rechten Seite besagt, dass eine spezifische Lösung zur Integration zwischen Systemen einen anzustrebenden Wert darstellt. Noch wichtiger ist aber eine "immanente" Interoperabilität. Das Wort "immanent" steht hier bewusst. Es geht nicht darum, dass Interoperabilität irgendwie dazugehört oder ermöglicht wird. Das Prinzip Interoperabilität muss vielmehr fundamentaler oder inhärenter Bestandteil einer SOA-basierten Lösungsstrategie sein.

Wie eine immanente Interoperabilität sicherzustellen ist, wird im Manifest nicht formuliert. Es handelt sich hier um das Wertesystem, für das in der Praxis von Fall zu Fall entschieden werden muss, wie eine Umsetzung aussehen kann. In manchen Fällen mag das die bewusste Einführung und Verpflichtung zu einem Enterprise-Service-Bus (ESB) oder einem gemeinsamen Standard sein. In anderen Fällen mag das dazu führen, dass zwischen Anbietern (engl.: provider) und Nutzern (engl.: consumer) von Services wohldefinierte Schnittstellen bzw. Verträge (engl.: contracts) definiert werden müssen. Selbstverständlich können auch fachliche Vorgaben und Richtlinien dazu führen, dass es zunehmend einfacher und selbstverständlicher wird, Dienste von anderen Systemen aufzurufen.

Entscheidend ist also die hier formulierte Betonung von "Interoperabilität von ganzem Herzen". Es muss in jeder Hinsicht einfach und selbstverständlich sein, dass man Fähigkeiten (die typischerweise durch Services repräsentiert werden) an anderen Stellen problemlos nutzen kann. Und im Zweifelsfall ist dies wichtiger als eine maßgeschneiderte Lösung zur Integration zwischen zwei oder mehr Systemen.

Die vierte Aussage zur Wertesystem lautet:

Gemeinsam verwendete Services über zweckgebundene Implementierungen

Diese Aussage geht wie die vorherigen in die Richtung, dass "das große Ganze" wichtiger als ein spezieller Nutzen ist. Hier kommen nun allerdings die beiden eher technischen Begriffe "Service" und "Implementierung" ins Spiel. Auf der rechten Seite steht dabei der Wert der "zweckgebundenen Implementierung". Implementierungen sollten natürlich immer ihren Zweck erfüllen. Aber auch hier wird wieder ein höherer Wert definiert, der zur Nachhaltigkeit von Lösungen führt, die sich damit erst mittel- und langfristig rentieren: gemeinsam verwendete Services.

"Gemeinsam verwendet" führt zum Prinzip der Wiederverwendung. Spezielle zweckgebundene Lösungen sollten dem Prinzip der Wiederverwendung (also dem Nutzen in mehrfachen Kontexten) untergeordnet werden. Dabei wird der Begriff "Service" verwendet, der in der Regel als wohldefinierte in sich abgeschlossene Schnittstelle definiert wird, die Implementierungsdetails verbirgt.

Als konkretes Beispiel kann man nennen, dass es sicherlich besser ist, wenn ein System zur Verwaltung von Kundendaten eine allgemeine Schnittstelle anbietet, die es ermöglicht, diese Kundendaten unabhängig von der konkreten Implementierung abzufragen, anstatt externen Systemen den direkten Zugriff auf die darunterliegenden Datenbanken zu erlauben.
Allerdings möchte ich noch ein paar Hinweise zum Thema Wiederverwendung an sich geben. Hier steht nicht, dass Wiederverwendung automatisch aus der Verwendung von Services folgt. Es wird vielmehr als Ziel ausgegeben, dass es einen Wert darstellt, Services so zu entwerfen, dass sie möglichst wiederverwendbar sind. Und es gelten natürlich auch die Regeln, dass wir letztlich immer einen fachlichen Nutzen bieten müssen. Ein Service, der alles kann und somit den Wert der gemeinsamen Verwendung optimal erfüllt, ist in der Praxis eher kontraproduktiv, weil er zu langsam, zu unhandlich oder einfach zu schwer zu verstehen ist. Gemeinsam verwendete Services können nur Services sein, die auch verwendet werden. Und das bedeutet, dass auch immer berücksichtigt werden muss, welchen Preis man für eine Verallgemeinerung von Services zahlt.

Als konkretes Beispiel kann man deshalb sicherlich sagen, dass ein Service, der die Straße und den Ort eines Kunden liefert, auch dessen Postleitzahl liefern sollte. Aber einen Service zu entwerfen, der jetzt und zukünftig alle Daten liefert, die jeweils zu einem Kunden gehören könnten, geht über das Ziel sicherlich hinaus. Als Konsequenz wird man in der Praxis deshalb nicht nur einen Service haben, der Kundendaten liefert, was das Maß an Wiederverwendung reduziert. Die Zahlen, die ich aus operativen SOA-Systemen kenne, die eine signifikante Größe erreicht haben und eine unternehmenskritische Rolle spielen, lassen darauf schließen, dass Services im Schnitt von etwa zwei bis drei Nutzern verwendet werden (wobei man im Detail noch darüber diskutieren müsste, was genau ein Service ist; mir geht es hier nur um eine qualitative Aussage, dass es nicht "normal" ist, dass Services zigmal verwendet werden).

Zu dieser Werte-Aussage möchte ich schließlich noch anmerken, dass man die englischen Begriffe "service" und "implementation" auch anders übersetzen kann. Das würde dann zu der folgenden deutschen Formulierung dieser vierten Werte-Aussage führen:

        Gemeinsam verwendete Dienstleistungen über zweckgebundene Umsetzungen

Diese Formulierung ist weniger technisch, sagt qualitativ aber Ähnliches aus (wenn auch vielleicht auf etwas höherer Ebene). Wir haben bei der Verabschiedung des Manifests nicht darüber gesprochen, was genau gemeint ist. Vermutlich beides, sodass die genaue Bedeutung einer Aussage auch etwas kontextspezifisch ist. Aber wie schon in der Einleitung geschrieben, ging es uns nicht um exakte Definitionen, sondern um ein Wertesystem, das durch Formulierungen definiert wird, mit denen wir leben können.

Die fünfte Aussage zum Wertesystem lautet:

Flexibilität über Optimierung

Diese Werte-Aussage könnte sich als die umstrittenste herausstellen, denn wie kann es sein, dass es etwas Wichtigeres als eine optimale Lösung geben kann? Ohne Zweifel ist Optimierung ein wesentlicher Wert jeglicher Entwicklung, aber hier wird auf der linken Seite ein noch wichtigerer Wert angegeben: Flexibilität. Hier sei noch einmal darauf hingewiesen, dass beides wichtig ist. Im Zweifelsfall aber, wenn also eine Entscheidung zu treffen ist, die entweder zu einer optimaleren oder zu einer flexibleren Lösung führt, sollte man zu der flexibleren Lösung tendieren.

Das bedeutet aber nicht, dass Flexibilität um jeden Preis angestrebt werden sollte. Zu viel Flexibilität führt nämlich zu Komplexität. Leider haben wir im gesamten Manifest keinen expliziten Hinweis darauf, dass Einfachheit ein wesentliches Gut großer Systeme ist, aber man kann ja argumentieren, dass komplexe Systeme irgendwann keinen Geschäftswert mehr liefern, was die Präambel und die erste Aussage zum Wertesystem aber klar in den Vordergrund stellen. Ähnlich wie beim Wert der "gemeinsamen Verwendung von Services" in der vorherigen Aussage zum Wertesystem darf auch Flexibilität kein Selbstzweck sein.

Die sechste Aussage zum Wertesystem lautet:

Evolutionäre Vervollkommnung über Streben nach anfänglicher Perfektion

Diese letzte Aussage könnte auch im Agilen Manifest stehen, denn hier geht es im Grunde um die Frage, wie man in größeren Kontexten bzw. komplexen Systemen am besten zu einer guten Lösung kommt. Auf der rechten Seite steht der Wert des Strebens nach anfänglicher Perfektion. Auch wenn man Perfektion in größeren Systemen nie erreichen kann, so ist doch das Streben danach völlig berechtigt. Es muss uns natürlich immer darum gehen, möglichst gute oder sogar exzellente Lösungen zu schaffen. Und das gilt natürlich von Anfang an.

Aber - alle Erfahrungen mit großen Systemen zeigen, dass man sich dort an eine möglichst optimale Lösung nur Schritt für Schritt herantasten kann. Dafür gibt es vor allem zwei Gründe: Zum einen ändern sich Anforderungen ständig. Zum anderen steigt mit jedem Schritt zu einer Lösung auch der Erkenntnisgewinn darüber, was man eigentlich will, braucht und kann. Es geht also gar nicht anders, als sich Schritt für Schritt an eine optimale Lösung heranzutasten (eine Erkenntnis, die zum Selbstverständnis aller agilen Prozesse gehört).

Konkret bedeutet das zum Beispiel, das es kein guter Ansatz ist, zu versuchen, im ersten Wurf einen Service zu entwerfen, der jetzt und zukünftig alle Bedürfnisse abdeckt. An das richtige Design eines Service muss man sich "herantasten". Standards, Richtlinien und Erfahrung mögen da helfen, aber ob es wirklich passt, wird man erst mit der Zeit feststellen.

Das Gleiche gilt natürlich auch für die Einführung von SOA an sich. Eine SOA-Landschaft entsteht nach und nach, wobei viel gelernt und korrigiert wird. Versuchen Sie erst gar nicht, alles von vornherein richtig zu machen. Es gibt nur zwei Möglichkeiten, wie das endet: Man wird mit der Problemanalyse nie fertig (die sogenannte "Analyse-Paralyse") oder man schleift frühe Designfehler viele Jahre durch das System und wundert sich, warum die versprochenen Effekte (Synergien, Flexibilität, Wartbarkeit usw.) nicht eintreten.

Im Grunde ist dies also ein Statement für eine sanfte und schrittweise Einführung von SOA. Diese Aussage ist nicht unwichtig, weil man mitunter den Eindruck hat, man könnte SOA im Rahmen eines einzelnen Projekts umsetzen. SOA ist eine Strategie.

Auf Basis dieses Wertesystems existieren im SOA-Manifest 14 Prinzipien, die unsere Arbeit begleiten.