Baukunst_Softwarearchitekten.png

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

ISBN: 978-3-86802-640-5

© 2014 entwickler.press
Ein Imprint der Software & Support Media GmbH

Bibliografische Information Der Deutschen Bibliothek
Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Ihr Kontakt zum Verlag und Lektorat:
Software & Support Media GmbH
entwickler.press
Darmstädter Landstraße 108
60598 Frankfurt am Main
Tel.: +49 (0)69 630089-0
Fax: +49 (0)69 630089-89
lektorat@entwickler-press.de
http://www.entwickler-press.de

Lektorat: Theresa Vögle
Korrektorat: Nicole Bechtel, Jennifer Diener, Frauke Pesch
Satz: Dominique Kalbassi
Umschlaggestaltung: Maria Rudi, Flora Feher
Titelbild: ©iStockphoto.com/Corben_D, ©iStockphoto.com/Hiob und © S&S Media

Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder anderen Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.







For Nadia

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 ist der Kontext dieses Buchs.

Auch hat dieses Buch keinen wissenschaftlichen Anspruch, trotzdem nutze ich Referenzen zum Verweis auf interessante Quellen. Von diesen Quellen ging fast jeder Absatz aus. Ich habe dieses Buch mithilfe eines Kanban-Boards geschrieben. Erste Skizzen, Zitate oder Konzepte habe ich auf Papier an meiner Wohnzimmerwand geführt und diese dann als Phase „Idee“ ins „Backlog“15 übernommen. Von dort ging jede Idee in Entwurf, einen Absatz, ein Unterkapitel und ein Kapitel über. Dadurch ist das Buch sehr dicht, streckenweise frei assoziierend, geworden. Dies habe ich bewusst nicht reduziert, für mich sind die Querverweise genauso wichtig wie der Lesefluss.

Dieses Buch enthält wahrscheinlich Unschärfen und Fehler. Unter Twitter @janpeuker freue ich mich über Hinweise und konstruktive Kritik.

Aus Lesbarkeitsgründen benutze ich das Maskulinum für Titel. Ich möchte klarstellen, dass ich in jeden Titel alle Personen einschließe. In meiner täglichen Arbeit habe ich das Glück, mit Kollegen beider Geschlechter, unterschiedlicher Kulturen und Hintergründe zusammenarbeiten zu dürfen, für einen Arbeitgeber, dem Gleichberechtigung und Respekt für jedes Individuum so wichtig sind wie mir. Apropos Arbeitgeber: Die Ansichten und Beispiele in diesem Buch sind meine private Meinung und stellen keine Aussage von Accenture dar.

Danksagung

Sebastian Meyen möchte ich für seine Anregung danken, dieses Buch zu schreiben. Oswald W. Grube danke ich für seine architekturhistorischen Klärungen, Daniel G. Siegel und David Zülke für ihre Anregungen zur Technologiearchitektur und besseren Fokussierung, Henrik Mitsch und Boran Gögetap für ihre Gastbeiträge. Des Weiteren möchte ich mich bei vielen Kollegen bei Accenture bedanken, die mich unterstützt haben. Last but not least geht ein herzlicher Dank an Kathrin Schubert für ihr stilistisches Lektorat.

1 Brooks ist mein Lieblingsautor. Wenn man ihn liest, weiß man nicht, was man noch schreiben soll. Seine Erfahrungen gehen hauptsächlich auf IBM System/360 zurück, von dem Dijkstra geschrieben hat, es sei nicht nur „Logisches Spaghetti“, sondern „Logischer Stacheldraht“. Das motiviert mich, Fehler machen zu dürfen und trotzdem etwas beisteuern zu können.

2 Chad Fowler, „On Having Something to Say“, http://chadfowler.com/blog/2014/01/21/on-having-something-to-say/

3 Siehe z. B. „Stock and Flow“: http://snarkmarket.com/2010/4890

4 Verfügbar auf Prezi: http://prezi.com/mj8wveox8dbs/atzende-architekturmetaphern-jax-2013/

5 Metaphern als „regulative Idee“ (Blumberg) oder „Systems Metaphor“ will ich nicht diskreditieren, aber klären, dass sie nur Kommunikationsmittel sind.

6 http://www.sei.cmu.edu/library/abstracts/news-at-sei/architectsep98.cfm

7 http://elegantcode.com/2011/06/22/why-software-development-will-never-be-engineering/

8 http://www.chrisaitchison.com/2011/05/03/you-are-not-a-software-engineer/

9 http://martinfowler.com/bliki/BuildingArchitect.html

10 http://dirkriehle.com/2012/10/20/software-architecture-is-a-poor-metaphor/

11 Bredermeyer, „Architect, what’s in a name?“, http://www.bredemeyer.com/Architect/WhatsInAName.html

12 http://www.daedtech.com/uber-architects-the-building-metaphor-is-dead

13 Design Thinking Jargon, z. B. http://www.ceri.msu.edu/t-shaped-professionals/

14 Ich verwende hier die Trennung von produkt-/marketinggetriebener Entwicklung vs. Objective-/Value-getriebener Software z. B. von Bob Hughes. Ein gutes Buch zur Produktentwicklung ist „Beyond Software Architecture“ von L. Hohman, Addison-Wesley

15 Eine Listen von Aufgaben, die abgearbeitet werden sollen

1 Planbarkeit

A1_Titel.png


„To create architecture is to put in order.
Put what in order? Function and objects.“

Le Corbusier


Architektur als Platz und Schutz existiert, seitdem der Mensch die Natur verändert. Seitdem man sich zusammentun muss, um Ressourcen gemeinsam zu nutzen, wird Stein um Stein gefeilscht. Je komplizierter die Architektur wurde, je mehr wurde sie zu einem Machtinstrument, die Macht über Schutz und Ressourcen hatte. So verwundert es nicht, dass Architektur schon zu römischen Zeiten ewige Macht symbolisierte und mit der Ewigkeit auch den perfekten Plan – den Masterplan. Ich möchte das erste Kapitel mit der Frage beginnen: Ist Architektur planbar?

1.1 Chandigarh

Für den Schweizer Charles-Édouard Jeanneret-Gris war die Antwort einfach: Städte kann man perfekt entwerfen. Und er sollte diese Theorie im Alter von 60 Jahren endlich beweisen dürfen. Zu diesem Zeitpunkt war er bereits einer der berühmtesten Architekten der Geschichte und hatte sich den Künstlernamen Le Corbusier zugelegt.

Als 1947 Lahore Pakistan zufiel, suchte der indische Bundesstaat Punjab eine neue Hauptstadt – und entschloss sich, sie von Grund auf von Le Corbusier planen zu lassen. Also nahmen er und sein Cousin Pierre Jeanneret ein Tretboot und schipperten den See um Chandigarh an. Die Fürsten der Vergangenheit planten Städte wie Feldzüge am Reißbrett von oben. Le Corbusier bevorzugte die menschliche Perspektive – aus sicherer Entfernung.

A1_1.png

Abbildung 1.1: Der Garten auf der Unité d’Habitation (vincent desjardins)

Nachdem er in Paris den Stahlbeton und die Möglichkeiten der industriellen Fertigung kennengelernt hatte, formulierte er ein Manifest für das zweckmäßige Bauen nach geometrischen Formen: Die „fünf Punkte zu einer neuen Architektur“. Es war ein Gegenentwurf zum vorherrschenden Jugendstil, dem Ornamentalen und Prunkvollen, aber auch eine Reaktion auf den höheren Wohnraumbedarf. In Deutschland und Österreich wurde parallel das „Neue Bauen“ entwickelt, die Theorie, die den architektonischen Stil des Bauhaus in Dessau untermauerte. Le Corbusier griff die klaren Linien und den Funktionalismus des Neuen Bauens auf, wobei er sie um neue technische Möglichkeiten, wie nicht tragende Wände und eine wissenschaftliche Basis für komfortables Wohnen, erweiterte. Mit seinen Beiträgen zur Architektur wurde der begnadete Selbstdarsteller zu Lebzeiten eine Legende. Dieses Marketing war so überzeugend, dass er und seine Sozietät nach Indien eingeladen wurden, um ein modernes Monument, die Utopie eines neuen Bundesstaats zu errichten.

Le Corbusier war noch in einer Zeit aufgewachsen, in der man an das kartesische Weltbild und an das mechanische Menschenbild des funktionierenden Uhrwerks glaubte. Seit der Französischen Revolution hatte man sich wieder auf die Werte der Aufklärung besonnen. Obwohl in Literatur und Kunst neue Epochen eingeläutet wurden, war die Architektur recht unbeeindruckt im „Neoklassizismus“ verhaftet geblieben. Sie wiederholte immer wieder die gleichen Formen aus der Antike und dem Mittelalter. Doch nun war die Zeit angebrochen, in der man die Grenzen der Mechanik erkannte. Fotografie, Psychologie und Pharmakologie schienen wie Wunder, die dem Menschen seine Grenzen aufzeigten. Städte explodierten und mit ihnen soziale Unruhen. Marx und Engels hatten ihre kommunistische Stadttheorie aufgestellt, die Kapitalisten hatten ihre Cité Industrielle. Freud hatte von unserer Frustration von der Kultur geschrieben. Angesichts der „modernen Zeiten“ musste Ornament wie reiner Zynismus aussehen.

Die Relativitätstheorie war aufgestellt worden. Le Corbusier entwickelte, mit Albert Einstein im freundschaftlichen Kontakt stehend, seine industriell geprägten Ideen weiter. Er wandte sich einer Funktionalität des Bauens mit dem Menschen als Maßstab zu – einem Ordnungsprinzip, das er „Modulor“ nannte. Häuser waren für Le Corbusier „Wohnmaschinen“, industriell gefertigte Räume mit höherem Komfort und an den Grundbedürfnissen einer neuen Gesellschaft ausgerichtet, der Plattenbau als Idealtyp. Die Industrie sollte „Arbeitsmaschinen“ bereitstellen, die nach Fords Prinzipien der Massenfertigung funktionierten1, gemeinsam sollte dies Klassengrenzen aufheben und trotzdem die Produktivität hochhalten. Solange ein Masterplan das Zusammenleben nach klaren Regeln ordnete, konnte man Freiheit im Detail zulassen. Das war die Idee der Ville Radieuse, nach der dann z. B. Niemeyer, die brasilianische Hauptstadt Brasília baute. Le Corbusier wollte sie zusammen mit Sigfried Giedion auf seinem Kongress für die Moderne, den Congrès Internationaux d‘Architecture Moderne (CIAM), als Konzept für die Zukunft der Gesellschaft manifestieren. Das geschah 1933 in der „Charta von Athen“. 1932 war übrigens Huxleys „A Brave New World“ erschienen.

A1_2.png

Abbildung 1.2: Verfallende Gebäude in Chandigarh

Städte sind für Le Corbusier perfekt, wenn sie vier spezifische Funktionen getrennt voneinander immer wieder wiederholend anbieten. Diese definierten er und seine Mitstreiter in der Charta von Athen: Wohnen, Arbeiten, Erholen und Bewegen. Indem man diese iteriert, verkürzt man Transitzeiten und balanciert gleichzeitig die Interessen von Individuum und Allgemeinheit. Dazu wird die Stadt makroskopisch unterteilt, in eine innere Zone für Handel, Konsum und Kultur, eine Industrie- und Gewerbezone sowie Satelliten-wohnstädte. In den Wohnstädten vereinen Hochhäuser, die vertikalen Städte, alle wichtigen Lebensfunktionen. Jeder Sektor erlaubt dann kurze Routen, bei gleichzeitig großer Gesamteffizienz. Für Le Corbusier hatte die Großstadt kein Zentrum mehr, sondern eine Zentrale2. Die Idee klang einleuchtend, human und wurde nicht nur in Chandigarh, sondern auch teilweise in vielen europäischen Städten umgesetzt – Zonen hatte es ja schon im Mittelalter gegeben. In Chandigarh, wo sie am dogmatischsten verfolgt wurde, endet die Restrukturierung jedoch schließlich in der Zersplitterung der einst so modernen Stadt. Sie konnte nicht mithalten mit ökonomischen und demografischen Veränderungen, wurde genauso unkontrollierbar wie gewachsene Städte3.

1.2 Die Geschichte der idealen Stadt

Weder Le Corbusier noch Stadtplaner der Moderne „erfanden“ die Ideale Stadt. Sowohl Könige als auch Kirchen und Clans nutzten entsprechende Konzepte, um ihre Macht zu demonstrieren. Erst in der Renaissance entwickelten sich Städte hin zu eigenständigen, nationsunabhängigen Zentren. Das moderne Bild der Stadt entstand durch die Stadtplanung von Bürgern.

Die Renaissance4 markiert den Übergang des Mittelalters zur Neuzeit, die Wiederentdeckung der Natur und der Realität. Der Humanismus nimmt den einzelnen Menschen als kultiviertes Individuum wahr, antike Schriften, Wissenschaften und Philosophien werden wieder studiert. Die Bewegung entstand vor allem durch die wachsende Wehrhaftigkeit und Freiheit der Städte und ihrer Bürger. Handelsfamilien, wie die Medici und die Fugger, blühten in ihren Städten auf.

1.2.1 Leonardo da Vinci

Leonardo da Vincis Ideen beeindrucken uns bis heute. Natürlich hat auch er über Stadtplanung geschrieben, wenn auch hauptsächlich über technologische Aspekte wie Hygiene und Verkehrsplanung5. Als in Mailand die Pest ausbrach, konnte er sie mit Plänen zur Trennung von Brauch-, Ab- und Trinkwasser in der Kanalisation eindämmen. Er organisierte zudem die erste Müllabfuhr aus der Stadt hinaus. Für uns ist aber seine Idee am wichtigsten, die Stadt je nach Reinheit in Sektoren zu untergliedern, an welchen sich die Infrastruktur ausrichtete. Zu dieser Zeit waren Festungsbau und Stadtplanung noch eine gemeinsame Kunst – weshalb Schutzüberlegungen, z. B. für den Belagerungszustand, in die Stadtplanung mit einflossen.

Im Mittelalter waren Gilden bzw. Zünfte bestimmte Stadtteile mit jeweils einer Kirche zugewiesen, die sie fast selbstständig verwalteten. Die Stadtteile waren strikt nach Gesellschaftsklassen orientiert. Mit der Renaissance reorganisierte sich die Stadt langsam: Handwerk und Industrie rückten an den Rand, die reichen Händler ins Zentrum. Werke aus der Antike wurden neu übersetzt, Künstler entdeckten wieder römische Ideale. Die Stadtluft machte frei und die Kirche verlor langsam ihren Einfluss. Die wachsende Macht des Fürsten erforderte eine zentrale Planung, was zu neuen Stadttypen und massiven Umbauten führte. Ihre Prachtbauten waren Statussymbole, nach denen ganze Stadtteile ausgerichtet wurden. Wie im alten Rom sollten profane, nicht sakrale Bauten, breite Siegesstraßen und Raster Ordnung in die neuen Städte bringen.

1.2.2 Der vitruvianische Mensch

Die Wiederentdeckung der Perspektive in der Malerei führte dazu, diese Idee der Planbarkeit eines Organismus den Fürsten verständlich zu machen6. Im Gegensatz zum Aufriss erlaubte die Perspektive einen höheren Blickwinkel und die Darstellung von Schatten, wodurch man dem Problem von Modellen ausweichen konnte, an denen immer nur Details diskutiert wurden. Damals war die Selbstdarstellung schon genauso wichtig wie später bei Le Corbusier; Modelle blieben nun einmal hinter strahlenden Gemälden mit dem Herrscher darauf zurück.

Diese gegenseitige Beeinflussung von Macht und Architektur wurde in der Renaissance erfunden. Idealisten schufen Gemälde zusammen mit Stadtplanungsideen, die an der Perspektive, am Raster, an der Lenkung und damit an einer machiavellischen Formung der Stadtbewohner ausgerichtet waren. Bereits Vitruvius hatte zu Beginn unserer Zeitrechnung den Mensch als Basis der Architekturästhetik und den „Modulus“7 als Maßeinheit definiert, Augustinus im 5. Jahrhundert den Gottesstaat in seiner „City of God“ entworfen. Leonardo da Vinci griff diese Ideen auf und baute sie, gemeinsam mit der Organismusidee des Humanismus, weiter aus.

Der Nachteil an Vitruvius’ Konzept war die ausschließliche Nutzung von menschlichen Proportionen als Basis. Das war zwar einerseits sehr praktisch, weil man auf der Baustelle einfach Referenzelemente verteilen konnte, aber andererseits schwierig zu planen. Angeblich war dieses Problem beim Brüsseler Justizpalast aufgetreten. Ein falscher Grundstein kam in flämischen Ellen auf die Baustelle, und das Bauwerk wurde exakt 20 Prozent größer als geplant skaliert, bis zu jeder Treppenstufe und jedem Fensterrahmen.

Da Vinci nahm also Vitruvius’ Idee, bemaßte und vereinheitlichte die Notation und schuf damit die Ästhetik eines gesellschaftlichen Idealbilds, das berechnet werden konnte. Dieses Bild des Menschen, der „vitruvianische Mensch“, das Titelbild dieses Kapitels, ist Popkultur geworden, abgebildet auf den Krankenkassenkarten bis hin zur italienischen Euromünze. Es zeigt das Urselbstverständnis des Architekten, als Idealbild des Menschen und der Planbarkeit.

Auf ihn folgte Filarete, eigentlich Antonio di Pietro Averlino. Sein Werk ist weniger kühn und visionär, sondern baut auf der tatsächlich damals vorherrschenden Architektur auf. Sein Hauptwerk „Trattato di architettura“, das um ca. 1460 die ideale Stadt beschreibt, ist zudem als Roman erschienen, was gerne zur Verniedlichung benutzt wird. Er entwirft darin die Stadt „Sforzinda“. Er kümmert sich darin auch um die weniger schönen Aspekte des Planens, wenn er beispielsweise ausführlich die Hygiene in Spitälern, Kanalisation und exakte Bautechniken beschreibt. Als Festungsbauer stand er in Diensten des Fürsten8, der auch da Vinci beschäftigte. Filaretes Stadt ist daher eine große Festung, ein schwer angreifbarer Stern, der dadurch auch direkt die Stadtteile und Segmente definierte. Ziel war es, einen Organismus zu schaffen, denn seit der Renaissance wollte man alles auf ein aristotelisches Modell von organischen, aber kontrollierbaren Kräften herunterbrechen. Wenn wir heute von organisch sprechen, meinen wir oft evolutionär, nicht steuerbar. Damals wurde der Organismus als mechanisch, von Gott geschaffen angesehen, den man nachahmen wollte. Wäre dieser Organismus kontrollierbar, wären es auch seine Bewohner.

1.2.3 Alberti

Leon Battista Alberti, geboren 1404, war bereits mit der Erfindung eines Hilfsmittels zur perspektivischen Zeichnung berühmt geworden: Albertis „Fenster“. Er nahm Leonardos Idee der berechneten Proportionen und wandte sie konsequent, und vor allem am erfolgreichsten, auf die Architektur an. Er formalisierte den Bauentwurf endgültig rein geometrisch, legte die Notation fest und führte maßstabsgetreue Zahlenreihen als Bemaßung ein. Er betrachtete die Rolle des Architekten systemisch, wie auch die des Gebäudes im Stadtbild. Damit verdeutlichte er, dass die perspektivische Zeichnung nur „Marketing“ gegenüber dem korrekten Plan ist. Mit seiner Erfindung des Plans als Heilsbringer ist er der Urgroßvater aller selbsternannten Experten, Projektplandogmatiker, UML- und 5-GL-Evangelisten und Zukunftsforscher.

Er beendete aber auch den Mythos des Baumeisters als Universalgenie und steckte die Grenze zwischen „Architekt“ und „Architektur“ ab. Für ihn ist die Aufgabe des Architekten die Entwurfsplanung, nicht die Konstruktion. Er war besessen von der Idee der Kopie und der Reproduzierbarkeit und hegte eine krankhafte Angst gegenüber qualitativ niedrigwertigen Kopien. Das ist eine interessante Parallele zur heutigen Zeit, nur ging es Alberti um Qualität, nicht um Quantität. Er vertraute anderen Werkzeugen grundsätzlich nicht, und er ließ mangels Techniken zur Reproduzierung nur Originalpläne zu, wie Mario Carpo in einem meiner Lieblingsbücher „Alphabet und Algorithmus“ schreibt: „In Albertis Theorie ist der Entwurf eines Gebäudes das Original, und das Gebäude die Kopie.“

Deshalb kann man Alberti auch als einen der ersten neuzeitlichen Informatiker ansehen. Er war es, der Verschlüsselung und Entschlüsselung in seiner Schrift „De Cifris“ neu erfand – bis diese Technologie von Alan Turing9 überholt wurde. Dies hing eng mit seiner Idee der Autorenschaft und Planbarkeit zusammen. Diese Idee baute schließlich Filarete weiter aus und teilte Albertis Proportionen den Bauphasen zu, es gab pro Phase feste Maßstäbe. Er sah es als seine Aufgabe, mit seinem Auftraggeber, dem Fürsten, nur über die groben Maßstäbe zu sprechen. Damit beanspruchte er das Prestige, mit dem Fürsten auf einer Stufe zu stehen, und nicht mehr auf der Baustelle stehen zu müssen.

Die Idee von Planbarkeit, wie sie Alberti vorgesehen hatte, traf auf Widerstand. Das lag gar nicht an der Planung, denn Alberti hatte deutlich mehr Freiheitsgrade10 für die einzelnen Bauleiter vorgesehen, sondern an der ungewohnten Freiheit der Handwerker. Diese hielten sich nun mit Kommunikation auf, da sie nicht „frei“ genug waren, selbst zu entscheiden. Heute würde man das Gruppendynamik nennen. Dabei hatte es Alberti nur gut gemeint, z. B. mit seiner Vorgabe, Holzmodelle so einfach wie möglich zu gestalten, um nicht den Eindruck des Masterplans zu erwecken. Diese Idee haben unsere Wireframe-Tools in den vergangenen Jahren wiederentdeckt. Doch die Handwerker sahen das ganz anders: Es war nicht ihr Job, ständig über die Architektur zu diskutieren, sie hatten schon genug Probleme in den Zünften.

Marco Carpo erzählt die Geschichte von Brunelleschi, einem Zeitgenossen. Der konnte die Kuppel des Doms von Florenz angeblich nur bauen, weil er die damalige Bauorganisation sprengte. Sprengen ist hier wörtlich gemeint, denn die Bauweise war vom Baumeister und einer mehr oder weniger agilen Organisation rund um die Zünfte geprägt. Was herauskam war meist „Design by Committee“, eine suboptimale Lösung. Zudem waren Korruption und Manipulation weit verbreitet, Machtspiele an der Tagesordnung, der ein oder andere Brudermord unter Freunden. Brunelleschi wollte die Autorenschaft für die Kuppel beanspruchen und nahm sich Albertis Prinzipien zu Herzen. Allerdings kehrte er es um: Er war ständig auf der Baustelle, betrieb für jedes Detail Mikromanagement und beantwortete jede Frage sofort und umfassend. Gleichzeitig kämpfte er ständig gegen die Zünfte, unterschlug Informationen und spielte sie gegeneinander aus. Den Typ würden Gernot Starke und Peter Hruschka im „Knigge für Softwarearchitekten“ als „Edlen Ritter“ bezeichnen, vermischt mit dem negativen Touch des „Proaktiven“. Simon Munroe nennt ihn „Embedded Architect“11. Ein Charakter, der nach außen freundlich und immer helfend erscheint, aber doch immer nur Teile offenbart. Im Endeffekt bleibt der Plan, die „Hidden Agenda“, im Kopf, ein Problem der Autorschaft, das erst hunderte Jahre später mit dem Patentrecht gelöst werden sollte.

1.2.4 Palladio

Nicht hunderte, sondern nur hundert Jahre später trat Andrea di Piero della Gondola, genannt Palladio auf den Plan. Alberti hatte die Architektur grundlegend verändert und Palladio wagte den nächsten Schritt: die Auftrennung des Plans und damit die Öffnung der Architektur gegenüber der Gesellschaft. Zur selben Zeit war Morus’ „Utopia“ erschienen, der erste Roman einer idealen Gesellschaft in einer idealen Stadt. Auf Albertis Basis konnte Palladio endlich nur noch Architekt sein und verfasste in diesem Sinne die „Quattro Libri“, seine Bücher zur Architektur. In diesem theoretischen Werk entwickelt er eine konsistente Formensprache um einfach anwendbare, ableitbare Regeln, eine Pattern Language der Renaissance. Er hebt den Kontext der architektonischen Lösungen hervor, die Bedeutung des Ortes, der Wege, des Lichts und der Unterscheidung von Stil und Konstruktion. Er ist einer der ersten Funktionalisten und baut Gebäude im Hinblick auf ihre Nutzung aus streng geometrischen Formen und Proportionen auf. Aber er erwartet auch vom Bewohner, sich diesen Funktionen zu unterwerfen. Seine Villa Capra, genannt „La Rotunda“, ist bis heute ein Beispiel für idealisierte Architektur und wird immer wieder als Beispiel für die perfekte Villa genannt. Damals sollte sie auch ein humanistisches, utopisches, „perfektes Leben“ implizieren. Übrigens trägt ein MDD12-System den Namen Palladio: sehr treffend.

1.2.5 Descartes

Es dauerte weitere hundert Jahre bis Descartes in der Aufklärung das „kartesische Weltbild“ prägte. Er sah die Architektur als Ideal des Rationalismus und übertrug ihren mechanisch-planerischen Idealanspruch als Struktur auf alle Wissenschaften. Er beginnt sein Werk „Discours de la méthode“ als Schule eines neuen Denkens (daher unser Begriff der Scholastik) mit dem Beispiel des Hausbaus auf einem neuen Fundament – und zieht diese Metapher konsequent durch. Als Vater eines Großteils unserer Mathematik und der Berechenbarkeit der Geometrie ist er, nach Alberti, einer der ersten Informatiker. Man könnte also sagen, er hat 1637 das erste Mal die Architekturmetapher in der Informatik genutzt, unter der wir bis heute leiden. So steht auch Le Corbusier klar in kartesischerer Tradition.13 Seine mathematischen Proportionen, wie die Fibonacci-Sequenzen, die natürliche Ordnung unterstreichen sollten, beruhen auf Prinzipien da Vincis und Palladios, algorithmisch weiterentwickelt. Colin Rowe beschreibt diese hunderte Jahre überdauernde Tradition in „The Mathematics of the ideal villa“14, die Palladios „La Rotunda“ wie folgt analysiert: „Geometrically, both architects may be said to have approached something of the Platonic archetype of the villa.“

Vielleicht ist genau diese ideale Ordnung der Grund, warum Rationalismus und Palladianismus als Architekturstile in den USA erfolgreicher waren als in Europa. Die protestantisch geprägten Siedler bevorzugten analytisch-logische Lösungen. So wurden die meisten Universitäten nach neohumanistischen Prinzipien gebaut, mit lateinischen Slogans, und Washington oder New York als streng gezonte Raster angelegt, wie römische Planstädte. Und vielleicht war es genau diese Architektur, welche die Grundsteine für die Informationstechnologie nach ihrem Ebenbild gelegt hat: Divide et Impera.

1.3 Was wir aus der Geschichte lernen können

Irgendwann im „Mittelalter der IT“ gab es wahrscheinlich einen ähnlichen Moment, in dem jemand in PowerPoint entdeckte, dass man Layer als Rechtecke darstellen kann. Eine weitere Entdeckung war, dass Systemarchitekturen sofort verständlicher sind, wenn die Rechtecke eine schöne Zahl ergeben und sauber aufeinandergestapelt sind. Genau wie die Architekten der Renaissance erkannte man den Vorteil des Marketings: Dass man mit Planbarkeit und Macht über Prozesse nicht nur persönlichen Status erlangen kann, sondern vielleicht sogar einen Platz in der Geschichte. Wie Descartes nahm man sich das Ideal der Formensprache, aus der sich alles zusammensetzen lässt, zur Hand und entwickelte daraus eine neue Methodik: auf einer Zeitachse angetragen vielleicht die funktionale oder objektorientierte Programmierung. Und irgendwann kam der Le Corbusier der IT-Architekten, skalierte diese Planbarkeit und argumentierte, wenn man nur alles bis hin zur gesamten IT-Landschaft aus Formen und natürlichen Constraints errechnen würde, basierend auf einer Unified Modeling Language, wären die Systeme ein platonisches Ideal.

Mit der Vereinheitlichung von Individualisierung und Produktion nahm Le Corbusier das Bausteinprinzip der Architektur voraus und damit eine Metapher, die uns Softwarearchitekten bis heute begleitet, der allgegenwärtige Legostein als Element der SOA, ROA, WOA und ähnlich einfach zusammensteckbarer Modulsysteme. Es wäre ja eigentlich möglich gewesen, jede andere Metapher für Softwaresysteme zu verwenden, nachdem jemand herausfand, dass Modularisierung Sinn mache. Die frühen Kybernetiker nutzen Elektrotechnikbegriffe für ihre Systeme, die objekt­orientierte Programmierung militärische Begriffe, weil sie in diesem Umfeld erfunden wurde15, oder in Deutschland industrielle Begriffe, wie z. B. „Verfahren“, was ein immer noch häufig gebrauchter Terminus ist. Die Taxonomien von Geografie, Logistik, Biologie und Zoologie sind ähnlich systematisch aufgebaut. Ein zwingender Grund für die Architekturmetapher lag also nicht vor. Aber Le Corbusiers eingängiges Dogma, dass Architektur aufeinander abgestimmte Funktionsbausteine industrieller Produktion seien, setzte sich durch.

Dieses Prinzip schien perfekt anwendbar auf die Softwareproduktion. Funktionsbausteine sind aber statisch, haben feste Grenzen und erlauben keine Aussage über ihre zugrunde liegenden Ideen – ein eher unglückliches Paradigma für Softwareentwicklung. Dijkstra, einer der Architekturpioniere, hatte Metaphern umschifft und lieber Lebenssituationen herangezogen.16 Doch mit seiner Referenz auf Herbert A. Simons „The Architecture of Complexity“, einem Werk aus der Hochphase der Rosa-Brille-Zeit der Anfangsphase der Systemtheorie, trat er eine Welle los. 1968 hatte die erste NATO-Konferenz zum Software-Engineering stattgefunden, T. H. Simpson beklagte sich deutlich über die „Pseudowissenschaft“. Doch kurze Zeit später sprachen Dahl und Nygaard in ihrer Beschreibung von Simula von „Building Blocks“17 . In den 1990er-Jahren manifestierten Perry und Wolf18 sowie Garland und Shaw19 den Begriff endgültig. Dabei gingen sie von einer Evolution des Designs aus, davon, dass Architektur sich ohnehin im Entwicklungsteam entwickelt und man diese Entwicklung nur formalisieren und fachübergreifend definieren müsse.20 Eine gute Idee – bis die Marketingmaschine einsetzte und Architektur als industriellen Planungsprozess bagatellisierte, zu etwas, das ein paar Jahrzehnte zuvor in Chandigarh misslungen war21.

Der Glaube an die kartesische Planbarkeit und eine allumfassende Sprache findet sich leider immer wieder in Enterprise-Architekturen, die durch ihre „Einfachheit“ bestechen und damit die einzelnen Verfahren und Anwendungen in ein Raster zwingen wollen – im Glauben, dadurch würde man innere Ordnung erlangen. Auch gerne benutzt in den Technologiebeschreibungen von COTS-Software, bei denen ein paar Blöcke den Bausteincharakter illustrieren sollen, man aber keinen Hinweis auf Schnittstellenprotokolle, Laufzeitumgebung oder Plattformanforderungen findet. Das war nicht Albertis Idee. Seine Theorien haben bis heute erstaunlich dem Zahn der Zeit standgehalten. Zur rein illustrativen Architektur führte wohl eher eine Mischung aus Managementtheorien und einem zeitweisen Desinteresse an IT sowie an Fehlinvestitionen in New Economy und Wirtschaftskrise, die zum „IT Doesn’t Matter“22 führten. Heraus kam das Schimpfwort „PowerPoint-Architekt”23, der die Entwickler bis an die Grenzen des „Death by PowerPoint“24 trieb. Also Architekturen, bei denen der Plan nicht nur wichtig ist, sondern Plan und Ausführung nur noch wenig gemeinsam haben, bei denen die Architektur als reine Managementinformation gesehen wird und dahinter mehr schlecht als recht unter starkem Budget- und Zeitdruck die Software irgendwie zum Laufen gebracht wird. Die damit einhergehenden Probleme sind reichhaltig. Eine Illustration, die von der Realität zu weit weg ist, trägt irgendwann weder zum Verständnis noch zur Dokumentation bei. Sie wird zu einer „Leaky Abstraction“25 oder eben zum reinen Marketing, zu einem Machtinstrument26, statt zu einem Leitfaden und einer Gedankenstütze.

So wie die Bauleiter des Mittelalters vor Alberti dieses Bauen nach Plan und das neue Prestige des Architekten gar nicht befürworteten, empfinden das auch die Entwickler, wenn einer von ihnen plötzlich eine organisatorisch höhere Hierarchiestufe nur aufgrund eines Titels einnehmen soll. Der Architekturdiskurs der 1990er-Jahre gipfelte in einem generellen Misstrauen gegenüber Architekturplänen, die Martin Fowler 2003 in „Who Needs an architect?“27 zusammenfasste. Er beginnt mit der These, Architektur sei nur die von der Gruppe der Entwickler akzeptierte Menge der wichtigsten Teile einer Software: „Architecture is about the important stuff“. Daraus folgert er, dass der Architekt besser „Lotse“ (Guide) genannt werden sollte, jemand der ständig mitverfolgt, welche wichtigsten Entscheidungen getroffen werden und gegebenenfalls in der Gruppe gegeneinander abwägt. Das Ziel muss sein, die Anzahl der nicht mehr umkehrbaren Entscheidungen und damit die ungewollte Komplexität zu reduzieren. Der Lotse muss vor allem das Team coachen und unumkehrbare Entscheidungen aufzeigen – vor allem jene, die aufgrund von falschen Annahmen (Bias) des Designs, der Organisation oder der Gruppe gefällt werden. Der Architekt ist in der agilen Entwicklung ein reiner Coach, wie z. B. der Scrum Master. Das Problem mit diesem Idealbild ist, dass Architektur nicht einfach nur die wichtigen Dinge umfasst. Diese wichtigsten Dinge erschließen sich nicht immer dem Entwicklungsteam und die Veränderlichkeit kann durchaus anders eingeschätzt werden.28

Unsere Architekturmetapher fußt auf dem kartesischen Weltbild, das die Welt als eine berechenbare Maschine begriff. So wie Chandigarh sich am Ende doch zu einem, wenn auch geordneten, Chaos entwickelte, wurden auch die idealen Städte des Mittelalters kuriose Festungen inmitten dynamisch wachsender Städte. Wenn wir als Software- oder Enterprise-Architekten von vollständig beschreibbaren Systemen ausgehen, müssen wir uns eingestehen, dass wir einer feudalen Denkweise erliegen, und uns dieser Gefahr bewusst sein.

Plattenbau

Wenn Le Corbusier auch den standardisierten, klassenlosen, an menschlichen Bedürfnissen orientierten Wohnraum erfand, so erfand er nicht den Plattenbau im baustatischen Sinne. Le Corbusier bevorzugte die Skelettbauweise. Plattenbauten sind mit ihren korrekt als „Wandscheiben” benannten Elementen selbsttragend, also Massivbauten sowie Mauerwerkgebäude. Skelettbauten haben im Gegensatz dazu tragende Strukturen, wie Säulen und Balken, was nicht tragende Fassaden und Wände möglich macht. Le Corbusier war grundsätzlich an einem hohen Lebensstandard für alle Gesellschaftsmitglieder interessiert und nutzte in seiner Unité d’Habitation deshalb aus Effizienzgründen die Platte. Die Unité d’Habitation, auch genannt Cité radieuse oder vertikale Stadt, war das Ideal der nach Funktionen getrennten Wohnblöcke. Diese waren über Schnellstraßen mit den anderen Zonen für Industrie, Erziehung und Vergnügen verbunden, dazwischen lagen nur Parks. Der Plattenbau war, als er Anfang des 20. Jahrhunderts aufkam und erstmals in New York großflächig eingesetzt wurde, vor allem eine Reaktion auf schnelles Wachstum der Städte und auf gestiegene Qualitätsanforderungen. Beton konnte nicht in hoher Qualität vor Ort hergestellt werden, ihn in Industriehallen wetterunabhängig vorzuproduzieren ging schneller und erforderte vor Ort weniger menschliche und maschinelle Ressourcen. Le Corbusier wollte diesem gedankenlosen Einsatz entgegenwirken und den Plattenbau bewohnbarer machen. In den wenigen realisierten Unités d’Habitation, eine davon in Berlin, schien die Sonne in jedes Wohnzimmer. Es gab Dienstleistungen von der Wäscherei bis zu Kindergärten auf dem Betongartendach und ein Hotel für Gäste.


1 Thilo Hilpert, Funktionelle Stadt, Vieweg, 1978, S. 148

2 Hilpert, Funktionelle Stadt, S. 174

3 http://www.brandeins.de/archiv/2009/stadt/ade-le-corbusier.htm

4 Ich habe die Renaissance herausgegriffen, weil ihre Ideale die IT-Architektur am meisten beeinflussen. Aber auch in der islamischen und asiatischen Welt gab es herausragende Beispiele für Stadtplanung. Bagdad mit seinem konzentrischen Plan, Peking mit dem an den bürokratischen Klassen ausgerichteten Raster, die Städte der Maya, integriert in die natürliche Umgebung. Wen das interessiert, dem sei Joel Kotkins „The City“ empfohlen und, als Inspiration, Italo Calvinos „Unsichtbare Städte“.

5 Siehe http://www.museoscienza.org/english/leonardo/navigli/

6 Fraser, Envisioning Architecture, 1994, S. 131

7 http://d-nb.info/977562662/34

8 Lepik, Architekturmodell in Italien, Worms, 1994, S. 133

9 Friedrich Kittler, Unsterbliche. Nachrufe, Erinnerungen, Geistergespräche, Wilhelm Fink Verlag, Paderborn, 2004

10 Lepik, Architekturmodell in Italien, S. 124

11 In: „IT Architecture – The Usual Suspects“, 2008: http://simonmunro.com/2009/09/08/it-architecture-the-usual-suspects/

12 Model-driven Development

13 J. Binotto, „Descartes, Le Corbusier und der Terror der idealen Stadt“, in: Modulor Nr. 7/2011

14 Architectural Review, March 1947

15 Vgl. z. B. den Einsatz von Simula für Flugbahnberechnungen in „Inside Innovation“ von Jan Rune Holmevik, http://simula.no/about/history/inside_innovation.pdf, S. 16

16 Dijkstra, z. B. Programmierung als „how not to get lost!“, http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD469.html

17 Online zu finden z. B. unter http://simula67.at.ifi.uio.no/Standard-70/common-base.text

18 1992, „Foundations for the study of software architecture“ unter http://dl.acm.org/citation.cfm?id=141884

19 1994, „An Introduction to Software Architecture“ unter http://dl.acm.org/citation.cfm?id=865128

20 Zuletzt wieder von Leslie Lamport geschrieben in http://www.wired.com/opinion/2013/01/code-bugs-programming-why-we-need-specs/

21 Siehe J. Baragry und K. Reed, „Why We Need a Different View of Software Architecture“, 2001

22 http://hbr.org/2003/05/it-doesnt-matter/ar/1

23 http://simonmunro.com/2009/09/08/it-architecture-the-usual-suspects/

24 Siehe R. Tufte, „The Cognitive Style of PowerPoint“, 2006

25 http://www.joelonsoftware.com/articles/LeakyAbstractions.html

26 Zum Thema Macht im System siehe Gilles Deleuze, „Postskriptum über die Kontrollgesellschaften“, 1990

27 http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

28 Zur Diskussion siehe http://c2.com/cgi/wiki?WhatIsArchitectureAnyway