Verhaltensmuster zwischen Vorbild und Desaster

Knigge für Softwarearchitekten

Peter Hruschka, Gernot Starke

Willkommen bei unserer neuen Kolumne, dem „Knigge für Softwarearchitekten“. Wir stellen Ihnen typische Umgangsformen dieser Spezies vor, samt- und sonders aus unserer Praxiserfahrung. Hier finden Sie in den nächsten Ausgaben eine Menge Beobachtungen zum Verhalten von Softwarearchitekten.

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.

Abbildung 1

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.

[ header = Seite 2: Was Sie erwartet ]

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.
[ header = Seite 3: Erstes Muster: der Proaktive ]
Erstes Muster: 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 und 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 erst nach Aufforderung tätig.

Sicherlich kommt proaktives Herangehen vielen Menschen und Rollen zugute. Innerhalb von IT-Projekten sehen wir bei Softwarearchitekten dazu jedoch besondere Veranlassung. Sehen wir uns dazu einige Beispiele für proaktives Vorgehen 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 kompensieren sie Schwächen im Projektmanagement oder unternehmen Ausflüge in die Chefetagen, um den Managern die technische Lösung zu erklären. Als verantwortungsbewusster Softwarearchitekt müssen Sie (wiederum selbstständig und proaktiv) entscheiden, wann solche Ausflüge angemessen und notwendig sind, damit sie von Ihren Mitmenschen nicht als Einmischung empfunden werden (ja, die schwierige Sache mit den Softskills. Die erwähnen wir in dieser Kolumne noch öfter.)

Annahmen und Voraussetzungen klären

Softwarearchitekten klären proaktiv jegliche (ansonsten versteckte oder implizite) Annahmen oder Voraussetzungen auf, sodass Entwurf und Implementierung der technischen Lösung auf Tatsachen beruht, nicht nur auf Vermutungen und Mutmaßungen.

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 und mit den anderen die Chanoyuzelebrieren, 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 sich auch 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.

Aufgaben selbst bestimmen

Softwarearchitekten suchen proaktiv 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 Sie als vorwitziges und übertriebenes Verhalten 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!

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.