Die einzige Best Practice: Keine Best Practice nutzen

Inhaltsverzeichnis

Softwaresysteme sind kompliziert. Best Practices für den Systementwurf könnten dabei helfen, die Komplexität möglichst einfach zu bändigen. Leider nützen sie wenig.

Dave Snowden teilt mit dem Cynefin-Framework Probleme, Systeme und Aufgaben in unterschiedliche Domänen ein:

• Einfache Systeme haben eine offensichtliche Ursache-Wirkung-Beziehung. In diesen Fällen kommen etablierte Ansätze als Best Practices zum Einsatz. Beispielsweise kann eine Reparaturanleitung für ein Gerät oder ein Gesprächsleitfaden für ein Callcenter eine solche Best Practice für das Vorgehen im jeweiligen Kontext darstellen.
• Komplizierte Systeme haben eine nicht offensichtliche Ursache-Wirkung-Beziehung. In diesem Fall gibt es mehrere effektive Wege (Good Practices). Ein Beispiel für diese Domäne kann die Fehlersuche nach einem komplizierten Bug in einem Programm sein. Es gibt zwar eine deterministische Ursache-Wirkung-Beziehung, aber das Ermitteln der Ursache des Fehlers ist schwierig. Zudem ist jede Fehlersuche anders. Es gibt aber dennoch effektive Wege, die weiterhelfen und Programmer:innen sich üblicherweise aneignen.
• Komplexe Systeme: Hier sind Ursache und Wirkung im Vorhinein nicht zu erkennen. Also bieten sich Emergent Practices an: Wir reagieren auf das, was passiert. Dazu ist die Zusammenarbeit von Personen aus verschiedenen Bereichen notwendig. Beispiel dafür kann das Erschließen eines neuen Markts sein, was oft das Ziel eines Softwareentwicklungsprojekts ist. Im Vorhinein ist nicht klar, wo das Softwareprodukt erfolgreich sein wird und welche Eigenschaften dafür notwendig sind, aber man kann auf Erfolge und Misserfolge reagieren und so das Produkt zum Erfolg führen.
• Chaotische Systeme haben keinen Zusammenhang zwischen Ursache und Wirkung. So etwas kommt beispielsweise bei einem Notfall oder einer Katastrophe vor. Dann muss das System stabilisiert und Novel Practices angewendet werden.

Cynefin-Framework und Best Practices

Diese Blog-Post kann keine vollständige Einführung in das Cynefin-Framework sein. Aber aus dem Cynefin-Framework ergibt sich, dass Best Practices nur bei einfachen Systemen mit klaren Ursache-Wirkung-Beziehungen sinnvoll sind. Softwaresysteme sind jedoch in den meisten Fällen nicht nur technologisch komplex: Die Entwicklung findet in einem komplexen sozialen System statt, in dem die verschiedenen Rollen im Entwicklungsteam mit den Stakeholdern interagieren. Wie das technologische Softwaresystem auf der einen und die soziale Entwicklungsstruktur auf der anderen Seite miteinander interagieren, lässt sich schwer vorhersagen. Wir reden also von komplizierten oder komplexen Systemen. Es mag Ausnahmen geben, aber einfache Systeme rechtfertigen wohl kaum den Aufwand für die Implementierung von Individualsoftware, weil die Probleme eben einfach lösbar sind – beispielsweise durch Standardsoftware.

Wenn Softwareprojekte aber komplex oder kompliziert sind, dann gibt es in der Softwareentwicklung im Wesentlichen nur Good Practices oder gar Emergent Practices. Wer also einfach Ansätze aus einem anderen Kontext übernimmt und auf Best Practices setzt, wählt gegebenenfalls eine für diese Aufgabe ungeeignete Lösung. Wir arbeiten an einer Aneinanderreihung von unterschiedlichen, speziellen Herausforderungen und müssen uns jedes Mal auf diese andere Umgebung passend einstellen und Lösungen anbieten, die den aktuellen Herausforderungen gerecht werden.

Wer dennoch auf Best Practices setzt, macht es den am Projekt Beteiligten schwer, die gewählten Ansätze zu hinterfragen. Schließlich sind es ja Best Practices. Aber in Wirklichkeit können sie eben ungeeignet sein, weil man in einer anderen Domäne ist. Daher finde ich Aussagen wie "Microservices sind eine Architektur-Best-Practice" oder "Monolithen sind eine Architektur-Best-Practice" nicht hilfreich. Aber natürlich ist es sinnvoll, sich mit Ansätzen zu beschäftigen, die in einem bestimmten Kontext erfolgreich waren, und davon zu lernen.

Best Practices einfach umsetzen?

Der Umgang mit Good oder Best Practice kann auch darüber hinaus problematisch sein. In einem mir bekannten Projekt haben Architekt:innen Schnittstellen, die nur zwei Teams nutzen, als Best Practice kommuniziert. Da immer nur zwei Teams beteiligt sind, können die Schnittstellen einfacher geändert und abgestimmt werden, als wenn mehrere Teams die Schnittstellen nutzen. Wenn man also mehreren Teams Funktionalitäten anbieten will, kann man für jedes Team eine Schnittstelle umsetzen, um so unabhängig zu arbeiten.

Eines der Teams in dem Projekt hatte diese Idee befolgt, obwohl die Schnittstellen relativ ähnlich waren und sich absehbar nicht ändern würden. Der Vorteil der Unabhängigkeit bei Änderungen ist also in diesem Fall unerheblich. Dennoch hat das Team keine einheitliche Schnittstelle umgesetzt. Diese Alternative hatte das Team selbst als bessere bewertet. Ohne die kommunizierte Best Practice der Architekt:innen hätte das Team vielleicht schon früher den eigenen, besseren Ansatz nutzen können. Denn natürlich hat der Ansatz mit vielen Schnittstellen Nachteile. Es entsteht so eine Vielzahl von Schnittstellen, die gewartet und implementiert werden müssen.

Die kommunizierte Best Practice ist vielleicht also nur eine Good Practice – oder der Kontext, in dem sie eine Best Practice ist, muss genauer definiert werden. Der zentrale Punkt ist, dass kommunizierte Best oder Good Practices dazu verleiten, diesen Beispielen einfach zu folgen und eigene, bessere Lösungen nicht zu nutzen. Daher sollte man solche Ansätze immer kritisch hinterfragen.

Entscheidungsvorlagen mit Kernfragen sind flexibler und können bei der Entscheidung zwischen verschiedenen Best oder Good Practices helfen. Solche Vorlagen finden viele nützlich, aber auch sie schränken den Lösungsraum ein, weil sie niemals alle denkbaren Fälle abdecken können.

Fazit

Am Ende werden also die am Projekt Beteiligten individuelle Entscheidungen treffen und verantworten müssen. Sie müssen sie auch begründen. Sich hinter einer Best Practice oder einem "Das macht man heute so!" zu verstecken, ist nicht ausreichend.

Außerdem gibt es unterschiedliche Good Practices. Wenn also jemand einen Ansatz wählt, der vom eigenen bevorzugten Ansatz abweicht, kann das immer noch eine Good Practice sein – oder gar eine Emergent Practice, die speziell auf die Herausforderung angepasst ist. Dann sollte man sich davon verabschieden, die eigene “Best Practice” zu empfehlen. Natürlich kann der gewählte Ansatz gar keinen Sinn ergeben – dann kann man sicherlich einen anderen empfehlen.

tl;dr

Softwareentwicklung ist oft für Best Practices zu komplex. Sie können zwar Orientierung geben, werden sie aber ohne kritische Reflektion angewendet, können für die spezifische Herausforderung suboptimale Architekturentwürfe entstehen.

Vielen Dank an meine Kolleg:innen Robert Glaser, Anja Kammer, Martin Kühl, Joachim Praetorius und Hermann Schmidt für die Kommentare zu einer früheren Version des Artikels. ()