Baut man Software in einer bestehenden Landschaft, ist die Service-Orientierung ein Segen. Man muss nicht alles selbst bauen und kann Bestehendes wiederverwenden. Aber kennt Ihr das auch? Man will nur kurz die Postleitzahl zu einer Adresse ermitteln und der entsprechende Service steht sogar bereit, doch die Adresse kann nur für einen Auftrag eingegeben werden. Diesen hat man aber bei dem fachlichen Szenario gar nicht parat. Theoretisch könnte man ja mit einem Dummy-Auftrag arbeiten, doch auch der benötigt einen Kunden im Kundenstamm. Und so weiter, entlang der ewigen Liste der Abhängigkeiten. Wie man sich auch bemüht, ist der Service irgendwie zu groß und die Anbindung daran eine Qual.
Versagt die Service-Orientierung also in der Praxis? Nein, denn Service-Orientierung bedeutet nicht, die bestehende Software über irgendwie geartete Services zur Verfügung zu stellen – es ist ein Entwurfsparadigma, bei dem die Modularisierung der Software mit der Trennung der Verantwortlichkeit gezielt nach fachlicher Kohäsion kombiniert wird. Das Ganze passiert auch nicht aus purer Willkür, sondern zum Zweck der losen Kopplung, um damit die Flexibilität des Systems oder der gesamten Landschaft zu erreichen. Wird dieser Zweck aus den Augen verloren, rächt sich die Service-Orientierung sofort und die Architektur wird starr und unflexibel. Die angebotenen Services haben dann gefühlt immer einen falschen Schnitt und sind zu groß.
Aber wie entstehen diese UBER-Services? Ihr ahnt es schon: die wachsen historisch! Man startet mit einem System, dem man eine Schnittstelle verpasst, um es mit einem anderen System zu verbinden. Dann gibt es kleine Änderungen oder ein weiteres System kommt ins Spiel, so dass die Schnittstelle erweitert wird. Für das weitere Projekt wird noch mehr erweitert und das so lange, bis der Service so groß geworden ist, dass es für neue Verbraucher nicht mehr attraktiv ist, sich anzuschließen. Man wird so einen UBER-Service auch nicht schnell los – wer weiß denn schon, welche Verbraucher ihn verwenden? Auch verändern kann man ihn nicht – schließlich weiß man nicht, welche Parameter für welches Einsatzszenario relevant sind. Ein weiteres Problem: wem gehört es? Wer ist der Besitzer und wer fühlt sich dafür verantwortlich? Der Auftraggeber sieht sich längst nicht mehr in der Pflicht, nachdem so viele Sachen in weiteren Projekten darangebaut wurden.
Aber ist denn so ein UBER-Service schlimm? Schließlich leistet er doch gute Dienste und alle, die sich angebunden haben, nutzen ihn. Ja, so wäre es in einer statischen Welt, die stehenbleibt. Doch unsere Welt ist veränderlich, manchmal sogar hochdynamisch! Das was gestern wichtig und richtig war, ist es heute nicht mehr. Wo gestern große Märkte, Wachstum und Margen waren, herrscht heute harter Konkurrenzkampf. Das bedeutet vor allem für die IT, dass die Integration und Flexibilität der Systeme den Unterschied machen. Man spricht dabei über Business-IT-Alignment. So ein UBER-Service ist alles, aber nicht flexibel, so dass die Anforderungen aus dem Business nicht erfüllt werden können. Dabei gibt es keinen festen Zeitpunkt, an dem man den UBER-Service identifizieren kann. Vielmehr ist es ein schleichender Prozess, der dadurch gekennzeichnet ist, dass die Wartungskosten immer höher werden und die Anpassungen komplizierter durchzuführen sind. Irgendwann ist rein finanziell der Punkt erreicht, an dem kaum noch Anpassungen möglich sind und der UBER-Service verwaist, während sich die Geschäftsanforderungen immer weiter auftürmen.
Bevor es so weit kommt und nur noch eine neue Investition hilft, den UBER-Service zu ersetzen, müssen die Anpassungen an der bestehenden Landschaft durchgeführt werden. Es empfiehlt sich eine Auftrennung der Services nach dem Zweck. Dies stellt eine Kombination aus zwei Grundprinzipien des Softwareentwurfs dar: dem Single Responsibility Principle (Prinzip der eindeutigen Verantwortlichkeit) und dem Interface Segregation Principle (Schnittstellenaufteilungsprinzip). Dabei bleiben die Services einfach in der Handhabung, sowohl für den Betreiber als auch für den Benutzer. Apropos Betreiber: wenn der Servicezweck klar definiert und abgegrenzt ist, bereitet es den meisten keine Mühe, einen Serviceverantwortlichen (oder Service Owner) zu finden. Am besten geht das, wenn der Serviceschnitt den geschäftlichen Anforderungen folgt und den Zugang zu klar definierten Geschäftsfunktionen bereitstellt. Wenn man beim Serviceschnitt der Wertschöpfung im Business folgt, ergeben sich im Geschäftskontext genau die Grenzen der Verantwortlichkeit und damit auch des Einflusses bei Veränderung, derer es auch in der IT bedarf. Damit bleibt der Service stets flexibel und kann den Veränderungen im Business folgen: voilà Business-IT-Alignment.
Die Verwendung von vielen kleinen Services bringt eine Menge Koordinationsaufwand mit sich. Oje, sagen Sie sich, wie soll man da noch die richtigen finden? Hier hilft der Standardtrick der Römer, wenn zu viele Sachen im Spiel sind: teile und herrsche. Die Businessfunktionen sind nicht völlig unabhängig voneinander. Manche verwenden gleiche Geschäftsobjekte, manche haben eine logische Abhängigkeit zueinander und manche eine kausale. Diese Ähnlichkeit oder Kohärenz sollte dazu verwendet werden, die Services in fachliche Bereiche einzuteilen – die sogenannten Geschäftsdomänen. Jede Domäne deckt dabei z.B. einen fachlichen Bereich ab. Um eine gute Aufteilung des Unternehmens zu finden, können z.B. Business Capabilities verwendet werden (wir haben dazu in diesem Blogbeitrag berichtet und uns einem Selbstversuch unterzogen). Entscheidend ist, dass die Prinzipien wie Services den Domänen zugeordnet, festgehalten und in der IT-Governance verankert werden müssen. So ist auch langfristig sichergestellt, dass die richtigen Services implementiert sind und sich stets an den Anforderungen aus dem Business orientieren. Um die Übersicht über die Services einer Domäne zu behalten, kann unter Umständen die Etablierung der Rolle des Domänenarchitekts helfen.
In der letzten Zeit ist ein neuer Trend in Architektur zu beobachten: die Microservices. Heißt es, dass die Service-Orientierung als Prinzip und damit die serviceorientierte Architektur ein Irrtum war? Nein, keineswegs! Im Grunde ergänzen sich die Konzepte und haben einen Punkt gemeinsam – der Schnitt der Services muss der Fachlichkeit folgen, denn nur mit einem klar abgegrenzten Zweck und einem Verantwortlichen lässt sich ein Service langfristig betreiben. Und die Frage, ob dabei eine größere firmenweite Infrastrukturkomponente benötigt wird oder jeder seinen Service auf eigenen Servern betreibt, ist zweitrangig.
