Verhaltensspektrum zwischen Sonne und Finsternis
In unserem Berufsleben durften wir Projekte unterschiedlicher Branchen und bei vielen verschiedenen Kunden begleiten und beobachten, von Embedded Systems, Informationssystemen, der Anlagen- und Produktionssteuerung, Web- und Data-Warehouse-Projekten, über Mainframe-, Client-/Server- und Standalone-Anwendungen. Dabei haben wir Licht und Schatten erlebt, sowohl hervorragend produktive als auch grausig schlechte Projekte. In dieser Kolumne möchten wir uns auf unsere Beobachtungen von SoftwarearchitektInnen beschränken und deren Verhalten in Form von "Mustern" darstellen. Organisationsmuster für andere Bereiche der IT finden Sie bei Coplien und Harrison: "Organizational Patterns of Agile Software Development" (Prentice-Hall 2004) und DeMarco/Hruschka; The Atlantic Systems Guild: "Adrenalin-Junkies und Formular-Zombies". (Hanser 2009).
Der klassische "Knigge", 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 eventuell sogar Eindruck schinden. Zur Berufslaufbahn "Softwarearchitekt" hingegen schweigt die klassische Benimmliteratur.
Wir gehen einen etwas anderen Weg als der alte Freiherr von Knigge, indem wir bewusst sowohl gutes wie auch schlechtes Verhalten von Softwarearchitekten vorstellen. Bei guten, positiven Mustern helfen wir Ihnen, dieses Verhalten zu erreichen. Bei schlechtem Verhalten zeigen wir Abhilfe auf und unterbreiten Verbesserungsvorschläge.
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 entwickeln. Systeme, die verständlich, langlebig, wartbar, funktional, performant und sicher sind. Systeme, die robust auf Fehler reagieren und ihre jeweiligen Benutzer positiv erstaunen, statt zu nerven. Kurz gesagt: Gute Architekten liefern höchstmögliche Qualität.
Gutes Verhalten macht gute Architekten
Wir sind vielmehr der Meinung, dass der Unterschied zwischen guten und hervorragenden Softwarearchitekten hauptsächlich in deren Verhalten begründet liegt, in ihrer Vorgehensweise oder Methodik. Technologie, Frameworks oder Tools beeinflussen unserer Meinung nach die Qualität von Lösungen erheblich weniger, obwohl Softwarearchitekten diese natürlich kennen und können müssen. Daher haben wir technische Themen in unserer Betrachtung ausgespart. Wir gehen (optimistisch, aber durch langjährige Beobachtung gestützt) davon aus, dass Softwarearchitekten ihr IT-technisches Handwerkszeug ausreichend gut beherrschen. Außerdem finden Sie dazu bereits eine umfangreiche Fortbildung in diesem Magazin.
Was Sie erwartet
Um Ihren Appetit auf die weiteren Folgen dieser Kolumne anzuregen, möchten wir Ihnen die weiteren Muster kurz vorstellen.
| Muster | Erklärung |
|---|---|
| Der Proaktive | Niemand kommt zu Ihnen, um Ihnen Ihre Arbeit zu erleichtern. Niemand schenkt Ihnen etwas – Sie müssen selbst aktiv Ihre Entwürfe (O. K. – Ihr Schicksal auch) in die Hand nehmen – und alles, was dazu gehört. Hier gehen wir selbst mit gutem Beispiel voran – und präsentieren proaktiv dieses Verhaltensmuster. |
| Der Elfenbeinturm | Negativ: Lange Zeit im stillen Kämmerlein ohne Bezug zur Realität nach einer vermeintlich optimalen Lösung suchen. |
| Der Vielsehende | Betrachten Systeme aus unterschiedlichen Perspektiven und stellen dadurch Synergien her. |
| Strukturierte Faulheit | Betreiben Sie extensive Wiederverwendung auf vielen Ebenen, nicht nur bei Code oder Libraries. |
| Der Diktator | Negativ: Der Architekt als alleiniger Bestimmer. |
| Blick in den Rückspiegel | Der Begriff "Retrospektive" hat bisher primär als Floskel in unserer Branche Einzug gehalten. Nur selten nutzen Projekte oder Architekten das verborgene Potenzial des Rückspiegels. |
| Zuviel des Guten | Negativ: Übermaß, beispielsweise an technischer Dokumentation. Kommt selten vor. Wenn es eintritt, dann ganz schrecklich. |
| Der Multilinguist | Architekten sprechen mit unterschiedlichen Projektbeteiligten in jeweils deren eigener Sprache. Mit Fachleuten Fachchinesisch, mit Entwickler Geek-Lingo, mit Betreibern oder Administratoren Operatiösisch (oder wie das dort auch immer heißt). |
| Feedback statt Vermutung | Eine Ursache für viele Probleme liegt in dem nur scheinbar harmlosen Satz "Ich dachte...". Dahinter steckt die implizite Annahme. Das explizite Feedback verspricht deutlich mehr Erfolg. |
| Der Notationskrieger | Oder: Der Pedant. Negativ: Es ist eminent wichtig, dass diese Linie gestrichelt ist. Außerdem muss der Kommentar mindestens vierzeilig sein – das schreibt der Styleguide vor. Zudem würde es mir besser gefallen, wenn Sie bei der Arbeit weiße Hemden mit dezentem Streifenmuster trügen. |
| Der Codeheld | Negativ: Der Codeheld patcht eingesetzte Libraries und ändert an vielen Stellen im System, ohne das mit irgendjemandem abzusprechen. Kuriert Symptome, statt Ursachen zu finden. |
| Die Jongleuse | Sehr positiv: Schafft es, mehrere konkurrierende Ziele zu vernünftigen Kompromissen zu balancieren. |
| Der Perfektionist | Eines unserer liebsten negativen Muster. Verbessern um jeden Preis, jedes Quentchen Optimierung ausnutzen. |
