Damals in meinem Physik-Leistungskurs hatten wir die Tradition, Freitag morgens die Stunde mit einem Witz zu beginnen. Es musste aber natürlich ein Physiker- oder Mathematikerwitz sein. Manchmal hab ich einen Witz erzählt und manchmal mein Physiklehrer. Einer der Witze ging in etwa so:

Ein Ingenieur, ein Physiker und ein Mathematiker übernachten in einem Hotel. Nachts fängt es auf einmal an zu brennen. Der Ingenieur wacht als erstes auf, geht raus auf den Gang, sieht das Feuer, geht zum nächsten Feuerlöscher, liest die dort aufgedruckte Bedienungsanleitung und löscht das Feuer. Dann legt er sich wieder schlafen.

In einem anderen Flügel des Gebäudes brennt es ebenfalls und der Physiker wacht auf. Er bemerkt das Feuer, rechnet, füllt einen Eimer mit genau der ausreichenden Menge Wasser und löscht das Feuer mit minimalem Mitteleinsatz. Dann legt er sich wieder ins Bett.

Kurz darauf erwacht der Mathematiker, dessen Zimmer direkt neben dem des Physikers liegt. Auch er riecht Rauch und bemerkt kurze Zeit später das Feuer. Offensichtlich war es doch noch nicht ganz gelöscht, weil der Physiker das Wasser nicht perfekt auf die Flammen geschüttet hatte. Der Mathematiker sieht den Wassereimer (und auch noch einen weiteren unbenutzten Feuerlöscher). Kaum hat er diese Entdeckung gemacht, geht er wieder zurück ins Bett und legt sie wieder hin. Das Problem ist lösbar.

Man mag das nun witzig finden oder nicht, aber der Witz zeigt sehr schön die unterschiedlichen Herangehensweisen der einzelnen Disziplinen. Letztens hab ich in einem unserer Zielarchitekturworkshops genau diesen Witz wieder erzählt, weil ich glaube, dass in vielen Architekturdiskussionen genau die Herangehensweise des Mathematikers sehr wichtig ist.

In Architekturdiskussionen verliert man sich sehr schnell in Details. Oder aber man läuft Gefahr, so abstrakt zu diskutieren, dass man die Bodenhaftung und den Bezug zur Realität verliert. Gerade bei der Definition einer Zielarchitektur kommt es gerade nicht darauf an, alle Probleme zu lösen. Im Gegenteil: Das wäre genau das Big-Upfront-Design, das nicht funktioniert und der Elfenbeinturm, der ganz zurecht einen schlechten Ruf hat. Overengineering ist ein Problem und keine Lösung.

Trotzdem sind Diskussionen um Detailfragen wichtig, ebenso wie Diskussionen um mögliche zukünftige Erweiterungen und Änderungen am System. Nicht aber um diese Fragen abschließend zu klären und schon gar nicht um das System jetzt schon zu erweitern. Wir tun das nur, um heraus zu finden, ob die Fragen lösbar sind. Architekturentscheidungen haben weitreichende Konsequenzen und wir müssen sicher gehen, dass diese Konsequenzen keine unüberwindbaren Probleme erzeugen. Detaildiskussionen dienen also dazu, den generellen Ansatz zu verifizieren. Als Architekten legen wir uns wieder schlafen, wenn wir herausgefunden haben, dass ein Problem lösbar ist, falls es in Zukunft mal auftreten sollte. Wir lösen die Probleme von heute und maximieren unseren Handlungsspielraum von morgen. Nicht umgekehrt.