Baukunst für Softwarearchitekten - Was Software mit Architektur zu tun hat

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 immateriell und komplex ist. Mein persönlicher Favorit aus „Pragmatic Programmer“ erschien nur kurz später und hob hervor, dass unsere Arbeit eher dem „Garteln”8 entspricht, da Software organisch ist. Entsprechend sind wir keine Hochhausarchitekten, sondern Unkrautjäter. John Brøndum hat mehrfach geschrieben, dass die Gebäudemetapher zu weit hergeholt ist. Ebenso Martin Fowler9, der dazu Martin Pollan heranzieht, der auch ein großer Fan des Gartens ist, und argumentiert, dass der Architekt eigentlich ein Häufchen Elend ist. Im „Code Complete“ führt uns Steve McConnell erst einmal in die Probleme von Metaphern generell ein, um dann doch zu klären, warum er „bauen“ sinnvoller als „farming“ (eine dem Garteln ähnliche Herangehensweise) betrachtet. Deshalb umschiffen Standards wie die IEEE SWEBOK den Begriff Architektur elegant und sprechen von „Software Construction“. Dirk Riehle10 verbindet dieses Bauen mit dem Alterungsprozess aus „How Building Learn“ und erklärt, wie wenig Einfluss Architekten tatsächlich auf die Architektur haben. Vielleicht ist das der Grund für die sehr ausgewogene Herangehensweise der iSAQB-Zertifizierung: Sie akzeptieren den Begriff als Metapher, benutzen ihn aber nicht als Daseinsberechtigung. Denn Metaphern sind, wie Eric Evans festgestellt hat, zur Kommunikation nützlich. Sie helfen dabei, etwas zu identifizieren, was sonst informell und vage vor sich geht. Die beste Zusammenfassung dieses Problems liefert wohl Ruth Malan11:

„You could say a house is but a pile of wood and bricks, nails and such, but it doesn’t make sense to (only) see a house that way, if you want to build one. And it doesn’t make sense to (only) see a software system as a bunch of bits, or even lines of code. We have to see the bigger structures. The rooms, the flow among them, the supporting walls, the sheltering roof. The components, the interactions, the mechanisms, the sub­sys­tems.“

Disclaimer

Letztens habe ich einen Post von Erik Dietrich mit dem Titel „The Building Metaphor is dead“ gelesen, der etwas provokant in Entwickler und Überarchitekten12 trennt, wobei letztere durch ihre pure Genialität den Respekt der Gruppe haben. Doch Respekt in einem Fachgebiet macht noch keinen guten Architekten, es ist die Offenheit für neue Probleme. Dazu ein schönes Zitat von Naveen Jain auf der DLD 14: „As soon as you become an ‘expert’ you stop innovating, you’re an incrementalist.”

Ich war nie Experte, immer eher Generalist. Meine Interessensgebiete waren schon immer „T-Shaped“13, Tiefe in Design sowie IT-Systeme, aber breites Interesse an allem Kulturellen. Das machte mich zum Nerd bei den Nerds, weder bei den Designern noch den Hackern war ich richtig aufgehoben. Dieses Buch ist weder nur für Gebäude- noch nur für Softwarearchitekten geschrieben, sondern versucht eine Brücke zu schlagen, ohne zu „bullshitten“. Und dies weder mit dem Ziel, die beiden Gebiete zu separieren, noch willkürlich zusammenzuwürfeln, sondern die Metapher für sich stehen zu lassen und allen Softwarearchitekten die Geschichte der Architektur näherzubringen, mit dem Ziel, daraus zu lernen – genauso wie man aus der Geschichte der Kunst, Musik oder Mathematik lernen kann.

Softwarearchitekten haben oft ganz unterschiedlichen Hintergrund. Nicht nur von ihrer Ausbildung, sondern auch dem Umfeld, in welchem die Software entwickelt wird. Klein- und Großunternehmen, Start-ups und Forschung, Produkt- und Individualentwicklung. Dieser Kontext wird mir zu häufig in Büchern und Blogs unterschlagen. Deshalb benutze ich häufig die Ich-Form. Ich habe in nicht so vielen Bereichen Erfahrung wie Architekturgurus, bin kein Opinion- oder Thought-Leader, Evangelist oder Fellow. Zwar habe ich sowohl mit prozess- als auch mit datengetriebenen Systemen gearbeitet; SOA, Batch, Messaging und extrem heterogene Architekturen integriert; in Java, JavaScript/Node, PHP, SQL, C++, Delphi und etwas Scala/Play professionell programmiert. Aber in der Produktentwicklung14 war ich nur kurz, und das ist schon etwas länger her. Funktionale Programmierung, Embedded- und Systems-Engineering kenne ich nicht im Industriekontext. An wirklich maschinennahe Programmierung traue ich mich nach zehn Jahren nur noch spielerisch ran. Meine Erfahrung liegt in geschäftsprozessgetriebener Individualsoftware: Informationssystemen, wozu ich auch Mobile- und Webplattformen zähle, deren Integration und Life Cycle. Das...