Erfolgsmuster: Der Multilinguist - JAXenter
Knigge für Software-Architekten

Erfolgsmuster: Der Multilinguist

Peter Hruschka und Gernot Starke

Willkommen in der achten Ausgabe unserer Kolumne rund um Verhaltensmuster von Softwarearchitekten.

Achtes Muster: Der Multilinguist

Selbst Menschen derselben Muttersprache können sich bei einer Unterhaltung in nahezu beliebiger Weise missverstehen. Und wenn diese Menschen dann auch noch ganz unterschiedliche Rollen in Projekten einnehmen oder gar unterschiedliche Ziele verfolgen, dann … willkommen in der Realität.

In ihrem ständigen Streben nach der für eine Problemstellung „angemessenen“ Lösung kommen Softwarearchitekten permanent mit unterschiedlichen Rollen im Projekt in Kontakt. In erster Linie natürlich mit dem Entwicklungsteam, mit dem sie gemeinsam die Lösung entwerfen und die Implementierung begleiten. Darüber hinaus sprechen Architekten mit Beteiligten der Anforderungsanalyse oder den Anwendern. Schließlich kommt recht häufig mal ein Administrator, Operator oder sonstiger „Betreiber“ daher, um Betreibbarkeit, Monitoring und administrative Forderungen zu platzieren. Und wenn Softwarearchitekten dann geschickt um die sprachlichen Hürden dieser stark heterogenen Stakeholderschaft herumlaviert haben, betritt Mr. Hard-Case-Project-Manager die Szene und verlangt unverzüglich einen Management-Report – natürlich frei jeglicher störender technischer Details (neudeutsch heißen diese Superabstraktionen Elevator Pitch – Ihre 30 Sekunden mit dem Boss im Aufzug).

Terminus Technicus

Branchen- oder Rollenslang kennen Sie bestimmt. Ihr freundlicher Hausarzt weist Sie nach kurzer Diagnose auf jede Menge Dinge hin, zu deren detailliertem Verständnis ein jahrelanges Medizinstudium die Voraussetzung bildet. So wie die Mediziner verfügen viele Branchen über ihre typischen Vokabulare und Redensarten (angeblich treiben die Juristen dieses Spiel zur Perfektion – leider versteht sie niemand anders mehr – sodass wir das niemals würdigen können). In typischen IT-Projekten finden wir eine ganze Schar solcher „Branchen“: die Fach- oder Anwendungsseite, die beispielsweise einen Versicherungs-, Banken- oder Logistikslang ihr Eigen nennt. Wir Techniker, fließend in Geek-Speak, Java und TLAs [1] sind ohnehin außerhalb unseres Clubs schwer zu verstehen. Und viele unserer Manager verstehen primär Euro, Dollar, Abgabetermin, Risiko und höchstens noch Bonuszahlungen.

Hohe Vernetzung erfordert echtes Kommunikationstalent

Wie wir schon in einer früheren Folge erwähnt haben, gehören Architekten zu den kommunikativ am höchsten vernetzten Mitarbeitern in der IT. Die Sprache der Entwickler sprechen sie in der Regel fließend, weil sich meist aus dem Kreis der Programmierer rekrutieren, wenn sie Gesamtverantwortung für eine Lösung übernehmen. Und wenn das noch nicht zu lange her ist und das Team überschaubar klein, dann alles klar.

Mit den Programmierern und Testern zu kommunizieren, reicht aber nicht. Das Kunststück für einen Architekten liegt darin, ein und denselben Sachverhalt (z. B. eine bestimmte Entscheidung über die Architektur) in ganz unterschiedlichen Worten und mit ganz unterschiedlichen Erläuterungen, ganz unterschiedlichen Vor- und Nachteilen und ganz unterschiedlichen Argumenten über Chancen und Risiken an die vielen Projektbeteiligten zu kommunizieren. So muss ein Architekt nicht nur Geek sein, sondern auch ein bisschen Unternehmer, der sich über Kosten und Risikoabwägungen Gedanken macht, nicht nur über den technischen Coolness-Faktor. Denn dem Finanzmanager gegenüber muss er eine technische Entscheidung in Form von erzielbarem Gewinn oder drohendem Verlust erläutern. Und das möglichst so, dass es zum Zeithorizont des Ansprechpartners dazu passt (jemandem, der in Quartalsergebnissen denkt, ist ein Vorteil in drei Jahren ziemlich egal).

Bei der Reflektion, wie man eine technische Entscheidung am besten einem Nutzer der Software erläutert, fallen dem Architekten vielleicht Argumente ein, die diese Entscheidung nochmals beeinflussen. Denn die Anwender wollen Entscheidungen mit Vorteilen für sie erläutert hören – und wenn es davon gar keine gibt, dann muss man vielleicht die Entscheidung doch noch überdenken.

Fazit

Sie sollten das Umschalten zwischen unterschiedlichen „Sprachen“ und Argumentationsketten aktiv üben! Lesen Sie dazu den Klassiker „Six Thinking Hats“ [2], der eine sehr nützliche Technik – der „Wechsel der Perspektive“ – vorstellt. Lernen Sie die Sprachen aller Ihrer Stakeholder. Erwarten Sie niemals, dass alle anderen Geek-Speak verstehen!

Peter Hruschka und Gernot Starke haben vor einigen Jahren http://www.arc42.de ins Leben gerufen, das freie Portal für Softwarearchitekten. Sie sind Gründungsmitglieder des International Software Architecture Qualification Board (http://www.iSAQB.org) sowie Autoren mehrerer Bücher rund um Softwarearchitektur, Softwareentwurf und Entwicklungsprozesse. Mehr finden Sie unter http://www.systemsguild.com (Peter) und http://www.gernotstarke.de (Gernot).
Geschrieben von
Peter Hruschka und Gernot Starke
Kommentare

Schreibe einen Kommentar

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