Prolog

Knigge?

Der klassische Knigge1, Originaltitel „Über den Umgang mit Menschen“ beschreibt Umgangsformen unter Menschen, insbesondere die anzustrebenden „guten Manieren“: Sie sollen nicht mit vollem Mund bei Tisch sprechen, nicht die Finger ablecken, alten Damen über die Straße helfen und so weiter.

Damit machen Sie sich im täglichen Leben beliebt und können Eindruck schinden. Zur Berufslaufbahn „Softwarearchitekt“ hingegen schweigt die klassische Benimmliteratur.

Der Schriftsteller Freiherr Adolph Knigge (1752-1796)

---

Vorwort und Danksagung

In unserem Berufsleben durften wir Systeme in unterschiedlichen Branchen und bei vielen verschiedenen Kunden entwerfen und begleiten. Dazu gehörten Embedded Systems, Informationssysteme, Anlagen- und Produktionssteuerung, Web- und Data-Warehouse-Anwendungen, entwickelt und betrieben auf Mainframes, Client-/Server-Clustern bis zu Standalone-Anwendungen. Dabei haben wir Licht und Schatten erlebt, sowohl hervorragend produktive als auch grausig schlechte Projekte, mit und teilweise auch ohne zugehörige Architekten. In diesem Buch stellen wir unsere Beobachtungen von SoftwarearchitektInnen und deren Verhalten in Form von „Mustern“ dar. Organisationsmuster für andere Bereiche der IT finden Sie in vielen anderen Werken dargestellt.1

Wir gehen einen etwas anderen Weg als der alte Freiherr von Knigge, indem wir bewusst sowohl gutes wie auch schlechtes Verhalten von Softwarearchitekten vorstellen.

Sie lernen, wie man durch Erfolgsmuster bessere Systeme konstruiert und schlechte Architekturmanieren (Antipatterns) vermeidet.

Gute Architekten bauen gute Systeme

Wir sehen als wesentliches Merkmal guter Architekten, dass sie unter den jeweiligen Umständen die bestmöglichen Systeme konstruieren und deren Entwicklung begleiten. Systeme, die verständlich, langlebig, wartbar, funktional, performant und sicher sind. Systeme, die robust auf Fehler reagieren und ihre jeweiligen Stakeholder positiv erstaunen, statt zu nerven. Kurz gesagt: Gute Architekten liefern hohe Qualität.

Gutes Verhalten macht gute Architekten

Wir glauben fest daran, dass der Unterschied zwischen guten und schlechten Softwarearchitekten hauptsächlich in deren Verhalten begründet liegt, in ihrer Vorgehensweise oder Methodik.

Technologie, Frameworks oder Tools beeinflussen die Qualität von Lösungen erheblich weniger, obwohl Softwarearchitekten sie natürlich kennen und können müssen. Daher haben wir technische Themen in diesem Buch komplett ausgespart. Wir gehen (optimistisch, aber durch langjährige Beobachtung gestützt) davon aus, dass Softwarearchitekten ihr IT-technisches Handwerkszeug in der Regel ziemlich gut beherrschen.

Danksagung

Wir bedanken uns bei unseren zahlreichen Kunden, bei denen wir das Verhalten von Softwarearchitekten beobachten durften. Dort, im Dschungel der Projektpraxis, haben wir am eigenen Leib die hier geschilderten Muster und Verhaltensweisen erlebt und erlitten – danke dafür! Dank auch an die vielen Seminarteilnehmer, an denen wir unsere Thesen ausgetestet haben – und oftmals erstauntes, aber kopfnickendes Feedback auf unsere Interpretation der Aufgaben eines Softwarearchitekten bekommen haben.

Viele Mitglieder des iSAQB e. V., insbesondere Prof. Dr. Andreas Rausch und Prof. Dr. Arne Koschel haben uns mit intensiven, inhaltlichen Diskussionen rund um die Rolle von Softwarearchitekten unterstützt.

Weiterhin danken wir Claudia Fröhling, Sebastian Burkart und Theresa Vögle vom Software & Support Media Team für ihren Optimismus und ihre Unterstützung bei den ersten Auflagen, Martina Raschke für den Support bei der dritten.

Gernot: Uli, Lynn und Per: Ihr seid super, die beste Familie im Universum! Zeit mit euch ist immer zu kurz. Danke auch an meine kundigen Kollegen der innoQ (Christian Albrecht, Thomas Bandholtz, Philipp Ghadir, Martin Huber, Arnd Kleinbeck, Andreas Krüger, Till Schulte-Coerne, Christopher Stolle, Stefan Tilkov) für eure gründlichen (und manchmal gnadenlosen...) Reviews.

Peter: Mein besonderer Dank gilt meiner Traumfrau Monika, die ein weiteres Buchprojekt nicht nur toleriert, sondern durch Kommentare aus einer Nicht-IT-Sicht wesentlich bereichert hat.

---

1 Der Proaktive

Verantwortungsbewusste Softwarearchitekten gehen aktiv auf alle Projektbeteiligten zu, um Chancen und Risiken rechtzeitig zu erkennen und geeignete Maßnahmen einleiten zu können. Sie übernehmen die Initiative, starten notwendige Aktivitäten aus eigenem Antrieb und ohne explizite Aufforderung. Anstatt passiv oder reaktiv abzuwarten, bis jemand anderes mit einer ungelösten Aufgabe zu ihnen kommt, gehen Aktive diese Aufgaben selbstständig an.

In diesem Sinne ähnelt proaktives Verhalten dem erfolgreicher Unternehmer: Stets auf der Suche nach passenden, erfolgversprechenden Betätigungen.

Den negativen Gegenpol bezeichnen wir als Unterlasser oder reaktiv: Diese Menschen warten, bis ihnen jemand eine Aufgabe gibt. Reaktive werden frühestens nach Aufforderung tätig.

Sicherlich kommt proaktives Herangehen vielen Menschen und Rollen zugute. Innerhalb von IT-Projekten ist proaktives Herangehen bei Softwarearchitekten besonders wichtig. Sehen wir uns dazu einige Beispiele an.

Verbesserungsmöglichkeiten suchen

Softwarearchitekten suchen ständig aktiv und an allen ihnen zugänglichen Stellen nach Verbesserungsmöglichkeiten – ohne explizite Aufforderung von außen. Sie schauen dabei deutlich über den Tellerrand ihres eigenen Arbeitsbereichs hinaus.

Konkret übernehmen Softwarearchitekten proaktiv Aufgaben in Anforderungsanalyse und -management, im Build- und Testmanagement sowie im Risikomanagement. Manchmal unternehmen sie Ausflüge in die Chefetagen, um den Managern die technische Lösung zu erklären oder Schwächen im Projektmanagement zu kompensieren. Als verantwortungsbewusster Softwarearchitekt müssen Sie (wiederum selbstständig und aus eigener Initiative) entscheiden, wann solche Ausflüge angemessen und notwendig sind, damit sie von Ihren Mitmenschen nicht als Einmischung empfunden werden. Hier tritt die Schwierigkeit bezüglich der Soft Skills zum ersten Mal auf. Die erwähnen wir in diesem Buch noch öfter.

Annahmen und Voraussetzungen klären

Gute Softwarearchitekten klären von sich aus jegliche (ansonsten versteckte oder implizite) Annahmen oder Voraussetzungen auf. Entwurf und Implementierung der technischen Lösung sollten auf Tatsachen beruhen, nicht nur auf Vermutungen, Mutmaßungen und Betriebsblindheit.

Auf andere zugehen

Proaktive Softwarearchitekten suchen von sich aus den regelmäßigen Kontakt zu anderen Stakeholdern im Projekt. Nicht, weil sie gerne grünen Tee trinken, sondern weil sie (richtig, aktiv!) Rückmeldung einholen und geben wollen. Genau das Gegenteil von „Abwarten und Tee trinken“: Initiativ Eindrücke und Meinungen der anderen erfragen, nach Hindernissen, erkannten Problemen oder Risiken suchen.

Gerne dürfen sie auch loben und sich loben lassen. Hierdurch können Softwarearchitekten eine Menge über ihre Lösungsansätze und deren Auswirkung auf die Projektrealität lernen. Gleichzeitig erhalten sie damit die Möglichkeit, ihre eigene Meinung zu Arbeitsergebnissen, Entscheidungen oder sonstigen Dingen im Projekt zu kommunizieren.

Sie sollten als Softwarearchitekt keinesfalls als Nörgler auftreten und jede Kleinigkeit bemäkeln. Rückmeldungen zum umständlichen Bugtracking-Prozess mit Excel können Sie beispielsweise erst einmal für sich behalten, wenn Sie mit Ihren Auftraggebern und dem Team gerade an fundamentalen Architekturentscheidungen arbeiten.

Aufgaben selbst bestimmen

Softwarearchitekten suchen aus eigener Initiative nach dem jeweils effektivsten (d. h. im Sinne der Zielerreichung optimalen) Einsatz der eigenen Zeit: Ob sie gerade Code schreiben, refaktorisieren oder testen sollen, ob sie Schnittstellen definieren oder Anforderungen klären sollen, ob sie Mitarbeiter coachen sollen oder ob die Dokumentation ein Update vertragen kann – das entscheiden sie proaktiv, ohne dass Projektleiter das erst vorgeben müssen.

Proaktiv ist die Ausnahme

Falls Sie glauben, diese aktive Einstellung sei eine Selbstverständlichkeit, dann willkommen in Phantasia: Proaktives Handeln, ja selbst proaktives Denken, erleben wir in unserer Praxis eher als die Ausnahme denn als Regel. Es bedarf nämlich einer gehörigen Portion Mut und Courage, um sich über etablierte Konventionen hinwegzusetzen und sich um Dinge zu kümmern, die einen angeblich nichts angehen, die aber für den Erfolg von Projekten immens wichtig sind. Im schlimmsten Fall kann es passieren, dass Ihre Vorgesetzten Proaktivität als Einmischung verstehen und Ihr Verhalten als vorwitzig oder übertrieben ablehnen.

Wir möchten Sie zumindest verbal bei diesem Mut zur Aktion unterstützen: Langfristig wird sich für Sie aktives Herangehen an andere Projektbeteiligte, aktives Suchen nach Verbesserung und aktives Infragestellen zweifelhafter Konventionen lohnen – in Form höherer Zufriedenheit, besserer Projektergebnisse und dankbarer KollegInnen. Und dafür lohnt sich der Einsatz!

Manchmal stecken hinter Zögern, Zaudern und Ängsten Ihrer Stakeholder auch Erfahrungen, die diese Menschen haben, Sie selbst aber noch nicht.

Verwandte Muster

Der Proaktive nutzt den „Blick in den Rückspiegel“ (Kapitel 6): Als proaktiver, vorausschauender Softwarearchitekt suchen Sie Risiken, bevor sie eintreten können. Bereits in frühen Entwurfs- oder Entwicklungsphasen begeben Sie sich auf die Suche nach Verbesserungsmöglichkeiten. Sie bewerten, bevor Sie jemand anders auf Probleme (= eingetretene Risiken) hingewiesen hat!

2 Der Elfenbeinturm

In der Abgeschiedenheit, fernab der Praxis, brütet ein verschrobenes Grüppchen Lösungsvorschläge aus, die niemand umsetzen möchte, denen es an Alltagstauglichkeit mangelt und deren „Genialität“ nur wenige zu würdigen wissen. Wo wir Ihnen im vorigen Kapitel die aktiven Softwarearchitekten als klassisches Erfolgsmuster vorgestellt haben, soll nun ein krasses Gegenstück folgen: Der Elfenbeinturm gilt in vielen Disziplinen als der Inbegriff der Praxisferne, das Eldorado derjenigen, die forschen, ohne anzuwenden.

Als Kontrapunkt dazu lautet der Spruch der Praktiker „Eat your own Dogfood“: Wende die Dinge gefälligst selbst an, die du uns beizubringen versuchst. Dabei hilft es Organisationen und Projekten ja durchaus, einen gewissen Aufwand in Erforschung und Prototyping neuer Technologien oder Methoden zu investieren, um überhaupt Innovation in Systeme oder Projekte einbringen zu können.

Risiko steigt mit Team- oder Projektgröße

Wir finden den Elfenbeinturmarchitekten häufig in größeren Projekten – ab 20 Personen aufwärts. Diese Projektgröße rechtfertigt eine volle Architektenstelle für die vielseitigen Entwurfsaufgaben und Kommunikation über technische Fragestellungen.

Softwarearchitekten sollten den Überblick über die gesamte Lösung und deren technische Entscheidungen besitzen. Gerade in großen Teams sollten Softwarearchitekten als technische Berater und Ansprechpartner für alle Entwickler bereitstehen. Wer als Architekt diese technische Führung den Projektleitern überlässt, landet schnell im Elfenbeinturm. Bei kleineren Teams passiert das weniger oft, weil der Architekt oft selbst kritische Teile programmiert und daher mitten im Tagesgeschehen der Entwicklung steckt.

Risiko: Streben nach Perfektion

Manchmal erleben wir, dass die Bewohner des Elfenbeinturms nach Perfektion streben, und deswegen (uns) Praktikern mit Unverständnis begegnen: Praktiker akzeptieren nämlich Fehler und Wandel als Normalfall, bemühen sich in iterativen Prozessen um schrittweise Verbesserung. Praktiker wissen schon lange, dass Perfektion unerreichbar und unbezahlbar ist. Elfenbeintürmler sehen das anders: Sie verachten Fehler und schätzen langfristige Planung. Kurze Iterationen lehnen sie als unprofessionell ab und behaupten, mit langem Nachdenken alle Probleme auch ohne diesen Feedbackfirlefanz lösen zu können. Wir, bekennende Agilisten, halten das in den meisten Fällen für unrealistisch. Ausnahmen gelten für sicherheitskritische Bereiche, etwa Medizin-, Luft- oder Raumfahrttechnik. Dort kann Streben nach Perfektion helfen, Leben zu retten. Allerdings sind dort oftmals die Projektbudgets etwas größer als im Rest der Welt.

Risiko: Überlastung

Gute Architekten sind eine seltene Spezies. Manche Organisationen setzen ihre seltenen Exemplare daher in mehreren Projekten gleichzeitig ein. Diese Überlastung führt manchmal dazu, dass diese Architekten Lösungen vorschlagen, ohne dem Team deren Hintergründe, Risiken oder Feinheiten erklären zu können. Aus Sicht der Teams arbeiten die Architekten im Elfenbeinturm, obwohl ihre Ideen brauchbar wären – aber die Entwickler nicht wirklich erreichen.

Falls Sie als Architekt ständig unter Überlast und im „Parallel Processing Mode“ arbeiten müssen, dann achten Sie ganz besonders auf gute Kommunikation mit Ihren Teams (oder lernen Sie, Nein zu Ihren Vorgesetzten zu sagen – aber das haben Sie sicherlich schon versucht)!

Verwandte Muster

Ein „Blick in den Rückspiegel“ (Kapitel 6) hilft Ihnen, Ihre Praxisnähe zu verbessern und aus dem Elfenbeinturm zu entkommen.

---

3 Der Vielsehende

Erfolgreiche Architekten nutzen verschiedene Sichten auf Systeme, um unterschiedliche Aspekte in den Vordergrund zu rücken. Sie wechseln je nach Bedarf diese Sichten, um ein gegebenes Problem aus mehreren Perspektiven zu beleuchten und so zu einer tragfähigen Lösung zu kommen.

Versetzen Sie sich in die Lage des Regisseurs einer Fernsehshow. Sie sitzen im Kontrollraum, wo die Bilder vieler Kameras zusammenlaufen. Sie haben ständig eine große Auswahl unterschiedlicher Perspektiven und können frei entscheiden, welche dieser Aufnahmen die momentane Situation am besten wiedergibt: mal die Totale, mal die Großaufnahme des Stars von der tragbaren Handkamera neben der Bühne.

Diese Möglichkeiten eines Fernsehregisseurs nutzen auch Softwarearchitekten – nur dass es sich bei ihren Möglichkeiten nicht um Kamerabilder handelt, sondern um verschiedene Darstellungen oder Abstraktionen des Systems, an dem sie gerade arbeiten. Die Grundgedanken hat Philippe Kruchten bereits 1995 in kurzer Form veröffentlicht.1 Weitere, verständliche und praxisnahe Darstellungen finden Sie in aktuelleren Werken.2 Leider aber mangelt es in der Praxis immer noch an Akzeptanz dieser einfachen Idee. Das könnte mit deren düsterer Vergangenheit zu tun haben: Schon 1987 stellte der Amerikaner John Zachman die Idee mehrerer Sichten im IBM Systems Journal unter dem Titel „A Framework For Information Systems Architecture“3 vor. Unserer Ansicht nach eine der praxisfernsten Publikationen unter der Sonne: Zachman empfiehlt sage und schreibe 30 (in Worten: dreißig) verschiedene Sichten auf Architekturen4.

Wir haben die 4+1 Sichten von Philippe Kruchten etwas „pragmatisiert“: Das „+1“ bezieht sich – wie im Original – auf die funktionalen Anforderungen (Geschäftsprozesse, Anwendungsfälle), die Sie im System implementieren müssen.

Verwenden Sie folgende Sichten (Abb. 3.1):

1. Als wichtigste die Bausteinsicht, die Sie unbedingt brauchen.
2. Dazu die Verteilungssicht, hauptsächlich bei verteilten Systemen.
3. Die Laufzeitsicht, zur Beschreibung wichtiger Interaktionen und zum Präzisieren oder Verifizieren der Bausteine.
4. Und ergänzen Sie bei Bedarf die Sichten durch übergreifende, querschnittliche, technische Konzepte.

Abb. 3.1: Sichten auf Systeme

Die Bausteinsicht

Sie zeigt die statische Sicht auf den Quellcode in unterschiedlichen Abstraktionsebenen, also die Bausteine des Systems. Die oberste Ebene – sozusagen die Totale über den ganzen Saal – zeigt unser System als eine Blackbox, eingebettet in seine Nachbarsysteme. Wenn wir näher an den Quellcode heranzoomen, erkennen wir vielleicht die Schichten des Systems oder – bei einer Pipe-und-Filter-Architektur – die wichtigsten Programmteile (die Filter) und die Verbindungen zwischen ihnen (die Pipes). Wie nahe Sie als Architekt dem Code kommen wollen, hängt von Ihren Zielen ab. Wollen Sie aus Abstraktionen oder Diagrammen automatisch Sourcecode generieren, dann werden Sie bis zu Klassen und Operationen verfeinern. Wenn Sie Programmcode hauptsächlich manuell in einer Entwicklungsumgebung pflegen, dann genügt meistens eine abstraktere Stufe.

Die Laufzeitsicht

Die Laufzeitsicht klärt die Dynamik des Systems – das dynamische Zusammenspiel (von Instanzen) der Bausteine. Sie beschreibt, wie eine Komponente eine andere aufruft, was sie dabei übergibt und wie der Ablauf von hier aus weitergeht.

Sie können hierbei ebenfalls auf unterschiedlichen Abstraktionsebenen argumentieren: Zeigen Sie Interaktionen „im Großen“ zwischen Bausteinen hoher Abstraktionsebene, um Überblick zu bieten. Beschreiben Sie Abläufe „nahe am Code“, wenn es Ihnen um Details geht.

Die Verteilungssicht

Eine dritte Sicht hilft Architekten oft noch: die Darstellung, welche Teile der Software auf welcher Hardware oder Infrastruktur ablaufen. Wir nennen das Verteilungs- oder Deployment-Sicht. Oftmals sind Architektur- und Entwurfsentscheidungen schon durch die beteiligten Rechner, Chips oder durch geografische Verteilung vorgegeben. Dann hilft es, diese Infrastruktur grafisch darzustellen (Abb. 3.2) und zu überlegen, welche Auswirkungen sie auf die Bausteinsicht oder die Laufzeitsicht hat.

Abb. 3.2: Drei wichtige Perspektiven: Baustein-, Laufzeit- und Verteilungssicht

Technische Konzepte

Auch technische Konzepte wie das Logging-Konzept oder die technischen Grundlagen der Implementierung der grafischen Oberfläche bilden eine (weitere!) Perspektive eines Systems. Diese Konzepte sind oft übergreifender Natur, wirken teilweise auf mehrere Bausteine eines Systems.

Spezielle Perspektiven nach Bedarf

In vielen unserer Projekte konnten wir mit nur drei Sichten (Bausteine, Laufzeitszenarien, Deployment/Verteilung) sowie den technischen Konzepten alle Beteiligten versorgen.

Manchmal jedoch benötigen Stakeholder weitere Sichten auf ein System. Gehen Sie in solchen Fällen pragmatisch vor: Erfragen Sie die Wünsche dieser Menschen und suchen Sie nach passenden Darstellungen. Sorgen Sie primär für Verständlichkeit, Akzeptanz und leichte Pflegbarkeit („Wartbarkeit“) in Ihren Modellen und Dokumenten. Einige Beispiele sollen Ihnen diese abstrakten Vorschläge konkretisieren:

• In stark datenorientierten Systemen können Datenmodelle eine weitere Perspektive auf das Gesamtsystem zeigen. Diese können fachlich oder technisch sein – in der historischen Kunst der Datenmodellierung hieß das „logisches“ respektive „physisches“ Datenmodell.
• Einen Sonderfall der Datensicht bilden sogenannte Fachklassen-, Business- oder Domänenmodelle. Diese konzentrieren sich auf rein fachliche „Dinge“, wobei sie manchmal Daten und Aufgaben (Services, Controller, Prozesse, Anwendungsfälle) enthalten.
• In interaktiven Systemen können grafische Entwürfe (Bildschirmmasken, Screens, Klickprototypen oder ähnliche Mittel) eine sehr anwenderorientierte Sicht zeigen. Sie funktionieren gut als Ergänzung von Laufzeitszenarien.
• Entwickler- oder Implementierungssichten können Teile der Bausteinsicht stark verfeinern. Geben Sie beispielsweise in einer solchen Sicht Implementierungsmuster oder Nutzungshinweise Ihrer favorisierten Frameworks an.
• Schließlich gibt es noch die plakative, von Technik stark abstrahierende Marketing- oder Verkaufssicht: Hiermit können Sie die nicht technischen Stakeholder durch Reduktion auf sehr wenige Elemente und Konzepte abholen.

In der Mischung liegt die Kraft

Die Bausteinsicht ist unserer Erfahrung nach die wichtigste Perspektive, so wie für den Regisseur diejenige Kamera, mit der er von der Totalen bis hin zum kleinsten Detail zoomen kann. Oftmals unterstützen die anderen Sichten Architekten dabei, Durchblick im Dickicht komplexer Strukturen zu gewinnen. Wechseln von Perspektiven macht Architekturen schneller stabil, weil verschiedene Einflussfaktoren besser ans Tageslicht kommen.

Lernen Sie als „Ablaufdenker“ einmal mehr in statischen Strukturen zu denken, aber als „Bausteinmensch“ mehr in Abläufen und Verteilung.

Verwandte Muster

Sie nutzen „strukturierte Faulheit“ (Kapitel 4) mit Augenmaß: Verwenden Sie nur die Sichten oder Perspektiven, die für Ihre Stakeholder bzw. zur Erreichung Ihrer Ziele wirklich angemessen sind – mit dem dringenden Ziel der Sparsamkeit in allen Belangen.

---