Mal Hand auf’s Herz: Wie viele Repräsentationen und/oder Instanzen eines Kunden gibt es in Ihrem Unternehmen? Auf wie vielen Wegen können die Adresse oder die Kontoverbindung ermittelt werden? Hat da jemand Redundanz gesagt? Wir heben hier jetzt nicht den historisch gewachsenen Zeigefinger. Das können Sie selbst viel besser. Ehrlich. Die Gründe für Redundanzen sind ja nun auch so zahlreich wie mannigfaltig. Und es gibt auch einige gute und sicherlich in der konkreten Situation richtige. Aber worin unterscheidet sich historischer Wildwuchs von sinnvollen Entscheidungen?

Es sitzt nun also der Entwickler vor der Aufgabe, den Vertrag zu einem Kunden zu ermitteln. Er stellt fest, dass dies auf drei verschiedene Arten geht und dass die Verträge mehrfach an verschiedenen Stellen verteilt sind. Aber welcher Weg ist der richtige? Die Doku ist auch nur mittelmäßig aufschlussreich (immerhin gibt es sie…). Er fragt also nach und bekommt zig Antworten, aber leider keine Aussage, welchen Weg er einschlagen soll. In der IT kennt jeder nur den Teil, den er entwickelt hat und im Fachbereich lehnt man ebenfalls dankend ab. Das sei ja nun wirklich die Aufgabe der IT, das zu wissen. Und wo das herkommt, wisse man auch nicht.

Hurra. Und nun? „Wenn das keiner weiß und mir auch keiner sagen kann, wer welchen Weg zu welchem Zweck nutzt, dann bau ich mir doch lieber selber eine eigene Methode. Das ist wenigstens sicher und ich muss mich mit keinem abstimmen. Das Projekt ist eh stressig genug“ mag sich der emsige, aber auch genervte Entwickler denken. Was passiert, ist logisch. Ein weiterer Service (Funktion, Methode – you name it) zur Ermittlung eines Vertrags entsteht. Vollkommen historisch. Und die IT-Landschaft verkrustet ein Stück mehr – will keiner, aber alle machen mit. Und das, obwohl jeder die Folgen kennt:

• Steigende Wartungskosten
• Steigende Betriebskosten
• Service-Leichen, die niemand braucht
• Fachliche Fehler wegen Dateninkonsistenzen
• Wachsender Kommunikationsoverhead

KEIN Einzelfall

Hat der Entwickler nun verrissen? Naja, er fügt sich „seinem“ System. Würden Sie auch tun. Wenn Sie nicht wissen, worin ein Service besteht, was genau die Leistungen sind, was Sie mitbringen müssen und mit welcher Qualität Sie wann ein Ergebnis zu erwarten haben, würden Sie sich ähnlich verhalten. Oder würden Sie Ihre Hose bei einer Reinigung abgeben, bei der Sie nicht erfahren, dass das Waschen 5 EUR kostet, die bei Abholung der sauberen Hose in 3 Tagen zu bezahlen sind? Niemals. Eher waschen Sie die Hose selber.

Und nun?

Wie können wir es aber besser machen? Nun, was sich in dem kleinen Beispiel paart, ist „Über“-Pragmatismus („Hauptsache, ich werde fertig“) mit mangelnder oder schlechter Kommunikation. Dazu fehlt es an geeigneten Mitteln zum Auffinden des richtigen Services (Service Discovery) bzw. einer verlässlichen Dokumentation bestehender Services.

Und tatsächlich braucht es gar nicht notwendigerweise die große Governance-Keule und eine Litanei an Regeln, um dem Herr zu werden. Schon mit wenigen Prinzipien lässt sich einiges verbessern:

• Beschreibe deinen Service so, dass andere verstehen, wie er zu nutzen ist.
• Sorge dafür, dass dein Service und die Informationen zu deinem Service leicht zu finden sind.
• Sei dir des betriebswirtschaftlichen Stellenwerts einer sauberen (Fach-)Architektur bewusst und zeige diesen auch auf. Projektdruck ist doof, Folgekosten aber auch.

Redundanzen ade?

Heißt das, dass es keine Redundanzen mehr gibt? Nein, sicher nicht. In einigen Fällen sind sie ja gut und gewollt. Richtig eingesetzt können sie Performance steigern, Ausfallsicherheit erhöhen und Abhängigkeiten reduzieren. Es geht nicht darum, Redundanzen per se zu verteufeln, sondern sich der Folgen unkontrollierten Wachstums bewusst zu werden und Redundanzen wohlbegründet (und dann bitte auch dokumentiert!) und sparsam einzusetzen.

Microservices to the rescue?

Wenn man die Veröffentlichungen zu Microservices liest, klingt das manchmal so, dass man genau das nicht tun sollte oder muss. Verlockend, oder? Aber auch in einer Welt von Microservices sollte natürlich keine Anarchie herrschen. Ansonsten sind die Folgen dieselben wie oben beschrieben. Und bei Licht betrachtet, haben serviceorientierte Architekturen und Microservices doch mehr gemeinsam, als es manchmal klingen mag. Auch wenn die entstehenden Services vielleicht kleiner sein mögen: ein gewisses Maß an Governance braucht es auch hier, damit wir nicht wieder im Wildwuchs landen.

Ganz schön hat dies Anthony Garvan in seinem Blog beschrieben.