Prolog

You cannot only design a building to make it beautiful.
It has to really work well with the huge crowd that is using it.

Jacques Herzog

Warum ein Buch

Jacques Herzog sagt immer wieder, dass er nicht an Bücherüber Architektur glaubt. Nicht weil er Bücher nicht mag, sondern weil er Sekundärliteratur für eine unnötige Einschränkung der Wahrnehmung hält. Als ein Gründer und Vordenker von Herzog& de Meuron, einem der wichtigsten Studios der Welt, muss er es wissen.

Die Zielgruppe dieses Buchs sind Programmierer, die neugierig sind, wie Strukturen ihre Arbeit beeinflussen können und dazu die Qual eines längeren Texts auf sich nehmen.

Dieser Text ist keine Einführung in die Architektur. Zwar wird Softwarearchitektur weder im Studium noch in der Arbeit hinreichend gelehrt, aber es gibt genug gute Sekundärliteratur zur Softwarearchitektur. Durchgängig hochwertige und breit angelegte Einführungen in das Thema Softwarearchitektur sind z. B.„Software Architecture“ von Vogel et al. oder„Software Architecture in Practice“ von Bass et al. und Starke und Hruschkas„Software-Architektur kompakt“. Viel Arbeit haben mir Kathrin Passig und Johannes Jander mit„Weniger schlecht programmieren“ erspart, indem sie ein Buchüber Softwareentwicklung im Allgemeinen schrieben. Ergänzend hat Laurent Bossavit mit„The Leprechauns of Software Engineering“ eine fabelhafte Einführung in die Folklore des Softwareengineerings geschrieben. Beide kann ich guten Gewissens empfehlen. Neben den Büchern von Brooks1, Fowler, Beck, Simon, DeMarco und Cunningham sowie den Beiträgen von Dijkstra, Kay, Fielding, Brand und Brown kann dieses Buch rein fachlich nicht mehr viel beitragen. Deshalb ist dieses Buch eine Reise.

Donald Knuth würde nach eigener Aussage nie mit„The Art of Computer Programming“ fertig werden, wenn er auch noch im Internet stöbern würde. Ich schreibe diese Zeilen als letzten Teil des Buchs, während ich mich eigentlich auf die„MobileTechCon“ in München vorbereiten sollte.Über Twitter laufen interessante Diskussionen zur Architektur, wie jedes Jahr zur Frühjahrskonferenzsaison. Diese kann ich nicht mehr aufnehmen. In Zeiten von Twitter ein aktuelles Buch zu schreiben, ist eigentlich unmöglich.

Der Vorteil eines Buchs gegenüber einem Blog ist der von vorneherein definierte Umfang des Manuskripts, das zu einem festen Zeitpunkt abzugeben ist. Blog wie Buch sind für mich Möglichkeiten, ein Thema neu zu betrachten. Wie Chad Fowler in seinem Blog Martin Fowler mit den Worten zitiert„Whenever I want to really learn about something, I write a book about it.“2 Das Buch zwingt zu einem größeren Rahmen. Als Buchleser bevorzuge ich das, denn dieser Rahmen gibt eine Idee, die im Kopf bleibt. Das Buch ist ein Schnappschuss eines Gedankengangs, wohingegen sich ein Blog weiterentwickelt3. Ein Blog funktioniert nach„Embrace change“, er kann Antworten liefern. Das Buch muss Fragen stellen. Ein Buch muss dichter sein, einen Mehrwert in Form von Verweisen liefern, dieüber die aktuelle Diskussion hinausgehen. Das Buch kann eine Referenz sein, die neben dem Tablet oder PC liegt, man kann es genervt in die Ecke schmeißen und wieder aufnehmen, Seiten einknicken, Fußnoten folgen, es verschenken und in die Kaffeeecke für alle legen.

Ätzende Architekturmetaphern

Auf der JAX 2013 habe ich den Vortrag„Ätzende Architekturmetaphern“ gehalten4, bei dem ich das erste Mal seit meinem Diplom 2009 Gebäude- und Softwarearchitektur gegenübergestellt hatte. Das Thema hatte mich schon lange verfolgt, da ich seit jeher Bücherüber beides lese. Der Vortrag fokussierte vor allem die folkloristische Verwendung von Architekturmetaphern5 im Softwareengineering, wie z. B. dem Wolkenkratzer als Sinnbild für die perfekte Ingenieurskunst, die man so auch im Softwarebereich anwenden solle. Ich hatte nieüberlegt, ein Buch darüber zu schreiben, dennoch nahm ich das Angebot an, um mich dem Thema eingehender widmen zu können.

Viele Autoren haben betont, dass die Gebäudemetapher für Softwaresysteme nicht hilfreich ist und entsprechend auch die Architektenmetapher für die Rolle des Organisators nicht. Mario Barbacci hat 19986 bereits ganz trocken erkannt, dass die Ausbildung des Informatikers eher dem Bauingenieur denn dem Architekten entspricht. Parallel gab es z. B. mit Morville einige, welche den Aufbau von Beziehungen in den Vordergrund gestellt haben, oder wie James A. Highsmith das Lernende mit seinem Bild des Bergsteigers. Auch in Boochs berühmter Präsentation zu UML wird mit dem Beispiel des Hundehauses Architektur ironisch betrachtet. Und Kent Beck schrieb, dass wir uns generell von Metaphern aus der physischen Welt lösen wollten, weil diese immer nur schwer veränderbar seien. Was John Sonmez prägnant zusammenfasst„Software is living– bridges aren’t“7.

In„Beautiful Architecture“ wird gar keine Metapher herangezogen, weil Software eben imma