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 [2] und [3].

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 („Anti-Patterns“) 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.

Links und Literatur

1. Wikipedia zu „Umgangsformen“: http://de.wikipedia.org/wiki/Umgangsformen, abgerufen 28. Februar 2010
2. Coplien, J.; Harrison, N.: „Organizational Patterns of Agile Software Development“. Prentice-Hall 2004
3. DeMarco, T.; Hruschka, P.; The Atlantic Systems Guild: „Adrenalin-Junkies und Formular-Zombies“. Hanser 2007

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 diesem Buchprojekt.

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 Softskills 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 Bug­track­ing-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 Projektbeteiligten, 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 (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 Innbegriff 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 sich 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)!

Risiko: Architekten bauen Frameworks

Risiko: Realitätsverzerrung

Wie wär’s mit weiteren Beispielen, in denen realitätsferne Elfenbeintürmler gravierende Probleme verursachten (Ähnlichkeit mit Projekten Ihrer persönlichen Vergangenheit oder Gegenwart wären zufällig, aber erwartet). Nennen wir die verschiedenen Varianten hier mal Elfen[0] ... Elfen[3]1:

• Elfen[0] schicken dem Entwicklungsteam eine umfangreiche, standardkonforme2 Dokumentation. In die Niederungen mündlicher Erklärungen lassen sich die Elfen[0]-er nicht herab, sondern vertrauen auf die semantische Klarheit ihrer umfangreichen, detaillierten Modelle. Beispielcode oder Unit Tests fehlen – die vermeintliche Klarheit ihrer schriftlichen Dokumentation benötigt solche niederen Artefakte nicht.
• Elfen[1] arbeiten etwas anders: Zwar dokumentieren auch sie ziemlich umfangreich, ergänzen ihre Modelle jedoch um jede Menge Code, der feine Details der technischen Konzepte klar und ohne Missverständnisse erläutert. Sogar ausführbare Unit Tests produzieren die Elfen[1]. Darüber freut sich das Java-erprobte Entwicklungsteam zuerst – doch angesichts von Hunderten Zeilen Common-Lisp3 bricht bald Entsetzen aus: Architektur und Entwicklungsteam müssen zueinander passen.
• Elfen[2] arbeiteten Hand in Hand mit einem Team motivierter Entwickler. Gegenseitig diskutierte man offen und konstruktiv die Ideen der jeweils anderen, verbesserte die Entwürfe und Konzepte immer weiter. Prototypen und Pilot-Implementierungen untermauerten die Machbarkeit der Architektur. Leider vergaß das gesamte Team im Eifer von Entwurf und Umsetzung, dass die Software später in einer komplett anderen Umgebung ablaufen muss: Leider den wichtigen Stakeholder „Betrieb“ oder „Deployment“ vergessen – zurück zum Start.
• Oh, die Elfen[3] hatten wirklich ein seltenes Problem. Ihre Lösung war gut implementier- und testbar und ließ sich im Rechenzentrum kosteneffizient betreiben. Leider verstießen einige Konzepte und Lösungsansätze gegen geltendes Recht4.

Wir möchten Sie ermutigen, auf jegliche Praxisferne frühzeitig hinzuweisen. Nutzen Sie die Zusammenarbeit zwischen Theorie und Praxis, um Innovation und Verbesserung entstehen zu lassen.

Verwandte Muster

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