Warum Soft Skills für Softwarearchitekten wichtig sind

Phillip Ghadir

Matthias Bohlen

Mahbouba Gharbi

Die Vorstellungen über die Aufgaben und Rollen eines Softwarearchitekten gehen auseinander. Je nach Rollenverständnis kommt ihm dabei eine mehr oder weniger zentrale Rolle im Entwicklungsvorhaben zu. Der iSAQB schreibt dem Softwarearchitekten verschiedene Aufgaben zu, die sich nur mithilfe anderer Projektbeteiligter erfüllen lassen. Die Verantwortung ist groß. So steht z. B. im Lehrplan: „Softwarearchitekten tragen die Verantwortung für die Erreichung der geforderten oder notwendigen Qualität und Funktionalität der Lösung. Sie müssen diese Verantwortung, abhängig vom jeweiligen Prozess- oder Vorgehensmodell, mit der Gesamtverantwortung der Projektleitung oder anderen Rollen koordinieren.“

Aufgaben eines Softwarearchitekten

Womit verbringt ein Softwarearchitekt eigentlich den ganzen Tag? „Seine“ zentralen Aktivitäten, die sich immer wiederholen, sind:

• Anforderungen und Randbedingungen klären
• Strukturen und Querschnittkonzepte entwerfen und dokumentieren
• Architektur kommunizieren
• Die Umsetzung begleiten
• Architektur bewerten

Keine von diesen Aufgaben lässt sich allein, in Einsamkeit, erfolgreich erledigen. Vielleicht konnte man früher kleinere Systeme allein entwerfen und dokumentieren, doch heute entstehen Systeme (und Systementwürfe) im Team: Ausprobieren, am Whiteboard notieren, dokumentieren, anderen zeigen, Feedback einholen, den Entwurf weiter verbessern, implementieren, testen und wiederholen. Das sind sehr kommunikative, interaktive Tätigkeiten.

Der Architekt braucht dafür Menschen, mit denen er gut arbeiten kann. Und er selbst sollte auch solch ein Mensch sein. Er ist eine Führungskraft, ohne die formale Macht dafür zu haben. Entweder er schafft es, Menschen zur Mitarbeit zu bewegen, oder er wird es schwer haben im Projekt.

Softwarearchitekt = Ansprechpartner

Wird er seinen Aufgaben gerecht werden, dient er nicht nur als proaktiver Treiber, sondern fungiert als Ansprechpartner für viele Projektbeteiligte – wie z.B. Kunden, Analytiker, Projektleiter, Entwickler, Tester und für den Betrieb. In Zusammenarbeit mit den Analytikern prüft er die Machbarkeit der Anforderungen, erkennt Widersprüche, fördert einen klaren Aufbau des Analyseergebnisses und gibt Rückmeldungen über Konsequenzen.

Als Anwalt der Kunden stellt er sicher, dass die Anforderungen umsetzbar sind und sorgt dafür, dass diese auch wirklich umgesetzt werden.

Er ist Ratgeber der Projektleitung für die Themen Projektplanung, Iterationsplanung, Risikoanalyse und -vermeidung und er hilft bei der Definition der Arbeitspakete.

Er ist Ansprechpartner der Entwickler, wenn es um Systemverständnis, Entwicklungsvorgaben, Erfahrungstransfer oder Codereviews geht, sowie Ansprechpartner der Tester für die Testrahmenbedingungen und die Testfälle. Außerdem unterstützt er die Tester, wenn es um die Reihenfolge und Abhängigkeiten beim Test geht.

Als Ansprechpartner der Sicherheitsverantwortlichen liefert er relevante Informationen und berücksichtigt deren Vorgaben.

Darüber hinaus ist er Ansprechpartner des Betriebs, wenn es um betriebliche Rahmenbedingungen, Anforderungen des Systems an die Hardware oder um Deployment-Struktur und Konfigurationsmöglichkeiten geht.

Der „Faktor Mensch“

Erfolgreiche Softwarearchitekten brauchen also nicht nur die erforderlichen Fachkenntnisse, damit alles gut wird. Sie brauchen Vertrauen der Projektbeteiligten. Dabei helfen persönliche Eigenschaften, Konflikte zu erkennen und aufzulösen, sowie die Fähigkeit, andere zum Handeln zu bewegen.

Studien zeigen, dass Erfolg im Arbeitsleben lediglich zu 50 Prozent auf Fachkompetenz beruht. Die andere Hälfte ist abhängig von persönlichen Eigenschaften und Fähigkeiten, wie zum Beispiel Kommunikations- und Teamfähigkeit. Weil sie sich nicht durch harte Fakten belegen lassen, werden sie gern Soft Skills genannt.Um als Softwarearchitekt mit Menschen zusammenzuarbeiten, hilft die Einsicht, dass es mehrere Wahrheiten geben kann. Ausgehend von der Prämisse können Konflikte häufig durch das Abgleichen der persönlichen Einschätzungen und Erwartungshaltungen aufgelöst werden.Wer kennt nicht Leute, die sich nie provozieren lassen, denen man eigentlich immer zustimmen muss und die immer wieder auf wichtige Punkte zurückkommen können? Welches Potenzial auf der Strecke bleibt, wenn sich der Softwarearchitekt nicht produktiv in das Projektteam einfügen kann, verdeutlichen die folgenden Beispiele: Wer nicht gehört wird, kann niemanden bewegen. Wer seine Ideen nicht überzeugend präsentiert, kann sich im Team kein Gehör verschaffen. Wenn in Meetings zu viele durcheinander oder im Kreis reden, ohne dass jemand moderiert, produzieren sie kein Ergebnis. Geht man unvorbereitet in wichtige Gespräche, kann es sein, dass man mit seinem Anliegen nicht durchkommt. Konfliktscheu oder übertriebene Streitlust können Kommunikation über wichtige Projektrisiken erschweren, so dass diese unentdeckt bleiben und das Projekt später zu einem ungünstigen Zeitpunkt in Schieflage bringen.

Was sind Soft Skills?

Soft Skills werden oft als Schlüsselqualifikationen bezeichnet, die unterschiedlichste persönliche Bereiche charakterisieren, wie z.B.:

• in der Kommunikation mit- und untereinander
• in der effizienten und erfolgreichen Arbeit im Team sowie gerade in der Teamführung
• im ganz eigenen und individuellen Umgang mit dem Kunden, seinen Ideen, Visionen, Wünschen und Vorstellungen

… und in vielen weiteren wichtigen und unverzichtbaren Situationen ihres alltäglichen Lebens. Tabelle 1 zeigt in Anlehnung an Gerrigs und Zimbardos „Psychologie“ [1] eine Gliederung der Soft Skills.

Bei jedem Menschen sind die Soft Skills unterschiedlich stark ausgeprägt. Je nach persönlicher Ausprägung und Präferenzen fällt die Zusammenarbeit mal leichter und mal schwieriger aus. Um im Projekt Erfolg zu haben, können Leitbilder helfen, sich auf die Persönlichkeiten von Beteiligten schneller einzustellen.

Kommunikationstypen

In der Psychologie gibt es verschiedene Modelle, um Persönlichkeiten und Verhaltensmuster zu klassifizieren. Trotz der Gefahr, in Schubladendenken zu verfallen, kann die Kenntnis und Einschätzung der Projektbeteiligten helfen, in hitzigen Situationen Ruhe zu bewahren und stets die Projektziele sowie die eher langfristigen Qualitätsziele zu verfolgen.

Abbildung 1 stellt ein Beispiel für ein solches beschreibendes Klassifizierungsmodell von Menschentypen vor: Das Vier- Quadranten-Modell. [2]

Das Modell ordnet einen Menschen nach dessen dominierenden Denkweisen einem von vier Quadranten zu. Jedem Quadranten ist eine Perspektive und eine zentrale Frage zugeordnet:

• Warum? Skeptische Haltung, philosophische Fragen, Provokation, Unterstellung, Rückzug oder Aggression
• Was? Häufige Rückfragen, prüfende Fragen, emotional eher ruhig, auditive Neigung
• Wie? Kompromissbereit, schnelle Entscheidungen, situativ aufmerksam, schnell, kurz
• Wohin noch? Visuelle, schnelle Sprache, in die ferne führende Sprache, unverbunden zu anderen, ignorant

Das Modell ist leicht verständlich und einfach in der Praxis anwendbar: Der Softwarearchitekt kann (sich und andere) bewusst fragen, welchen Fokus und welche zeitliche Dimension den Beteiligten wichtig ist, und sich darauf einstellen. Ein guter Softwarearchitekt holt die Beteiligten mit deren bzw. allgemeinverständlichen Worten dort ab, wo sie sich befinden. Dadurch kann er anschließend den Fokus gezielt auf anstehende Themen lenken. Er ermöglicht es allen, sich bestmöglich einzubringen, ohne sich unbewusst durch entgegengesetzte Vorprägungen provozieren zu lassen.

Soft-Skills-Ausbildung für Softwarearchitekten

Erfahrene Softwarearchitekten wissen, wie entscheidend Soft Skills für den Projekterfolg sind. Das zeigt auch die Themenwahl in der Java-Magazin-Kolumne „Knigge für Softwarearchitekten“. Die Beiträge liefern Empfehlungen für die eigene Herangehensweise sowie auch Hilfestellungen für Bewertung konkreter Aufgaben.

Das vom iSAQB definierte Ausbildungsprogramm zum Certified Professional for Software Architecture (Advanced Level) erfordert den Kompetenznachweis im Bereich Soft Skills und hat dafür ein Lehrplanmodul definiert.

Das Lehrplanmodul „Soft Skills für Softwarearchitekten“ ist auf drei Tage ausgerichtet und darf nur von erfahrenen Ausbildern mit langjähriger Erfahrung sowohl in Softwareentwicklungsprojekten als auch in der Erwachsenenbildung unterrichtet werden.

Die Hauptbestandteile sind nach Gewichtung geordnet: Einzel- und Gruppengesprächsführung, Moderationstechniken, Kommunikationsmodelle und -typen sowie Konfliktmanagement. Der Soft-Skills-Lehrplan [3] liefert den Überblick über alle Bestandteile.

Wie unterschiedlich die Einbettung des Softwarearchitekten in die Organisation sein kann, stellt Stefan Toth in seinem Buch [4] anschaulich dar. Aus den unterschiedlichen Organisationsformen und Teamstrukturen ergeben sich vollkommen verschiedene Teamdynamiken und damit unterschiedliche Herausforderungen für den Softwarearchitekten. Gute Soft-Skills-Trainings sensibilisieren Softwarearchitekten für solche Konstellationen und können Hilfestellungen geben. Dadurch kann der Softwarearchitekt bessere Rückmeldungen geben und mehr Einfluss auf die Entwicklungsorganisation nehmen.

Soft-Skills-Seminare für Softwarearchitekten können die Besonderheiten des Architektenalltags berücksichtigen und praktische Hilfestellungen geben wie beispielsweise:

• Die besondere Doppelrolle, die man als Architekt und Meetingmoderator hat: Partei ergreifen und gleichzeitig allparteilich moderieren – wie soll das funktionieren?
• Die Stolperfallen in der Kommunikation mit den Menschen in der Softwareentwicklung: Als Techniker meinen wir ja, wir seien ach so sachlich und technisch eingestellt, am liebsten wollen wir doch nur über Inhalte reden und diese „seltsamen menschlichen Dinge“ so schnell wie möglich beiseite bekommen?
• Die empfindlichen Entwicklerseelen, die so leicht in Rage zu versetzen sind, wenn Stellen im eigenen Code durch einen Architekten aus ganz anderer Perspektive kritisiert werden.
• Die Projektleiter, denen man als Architekt gleichzeitig selbstbewusst, unmissverständlich und klar sagen muss, dass das Projekt nächste Woche vorübergehend Gas wegnehmen muss, um bestimmte Stellen im System zu erneuern, weil sie der Weiterentwicklung nicht mehr standhalten.

Gute Soft-Skills-Trainings für Softwarearchitekten gehen auf diese Rolle und Situationen, in die ein Architekt geraten kann, tatsächlich ein. Man übt gemeinsam, mit diesen Situationen umzugehen, denn schon vielen anderen ist es so ergangen. Warum dieses Wissen nicht nutzen und einüben?

Alltagssituationen eines Architekten

Der Softwarearchitekt plant nicht nur Tätigkeiten, er transferiert Wissen, integriert andere Teams und präsentiert die Produkte. Er sollte dazu im Stande sein, seine eigene Meinung, Vorstellungen oder Ideen gegen Widerstand zu verteidigen, um ein bestimmtes Ziel zu erreichen. Das heißt allerdings nicht, dass er seine eigene Meinung mit aller Gewalt durchsetzen sollte. Vielmehr muss er im Alltag den schwierigen, aber wichtigen Ausgleich zwischen Nachgeben und Durchsetzen finden.

Teamfähigkeit ist unbestreitbar eine wichtige Fähigkeit für einen Softwarearchitekt, denn ein Team besteht nun einmal aus mehreren Charakteren, die sich nicht nur in ihrer Art, sondern auch in ihren Fähigkeiten perfekt ausgleichen sollten.

Schauen wir einem Architekten (nennen wir ihn Andreas) in typischen Alltagssituationen einmal gemeinsam über die Schulter, um zu sehen, wie er seine Soft Skills einsetzt. Ähnlichkeiten zu realen Personen und Situationen sind rein zufällig, aber nicht ausgeschlossen.

Der Projektleiter und der Termin

Zu Beginn eines Projekts rief der Projektleiter den Architekten und alle anderen Stakeholder zu einem Kick-off-Meeting zusammen. Es ging wie üblich um das Ziel, die Teamorganisation, die Termine, die Meetingrhythmen, die auszutauschenden Ergebnisse, den Projektplan und vieles mehr, was alle Beteiligten zu Beginn eines Projekts wissen mussten.

Der Projektleiter (nennen wir ihn Paul) war ein Alphatier: Er herrschte und regierte ganz gern. Der Termin und das Budget waren ihm das Allerwichtigste, sein Plan musste gefälligst von allen eingehalten werden. Das machte er im Kick-off auch ganz klar.

Als Andreas, der Architekt, Pauls Kick-off erlebte, war ihm klar, was auf ihn zukommen würde. Der klassische Konflikt zwischen Projektleiter und Architekt musste ausbrechen: Paul war für den Erfolg des Projekts zuständig, Andreas musste jedoch über das Projekt hinaus denken und die Wartbarkeit und Erweiterbarkeit des Systems über mehrere Projekte hinweg sicherstellen. Das würde dem, was Paul wollte und wie Paul dachte, widersprechen.

Andreas wollte Paul nicht im Kick-off vor allen Leuten mit diesem Konflikt konfrontieren. Er lud ihn am nächsten Morgen in die Kantine zum Kaffee ein. Im Zweiergespräch machte er seine Position klar und versuchte, von Anfang an eine Abgrenzung der Kompetenzen zwischen Paul und ihm selbst hinzubekommen: „Du fürs Projekt, ich fürs System.“

Paul war überhaupt nicht begeistert. Kurz bevor das Gespräch wirklich laut zu werden drohte, konnte Andreas die Interessen hinter Pauls Position erkennen. Paul erzählte nämlich, er werde von seinem Vorgesetzten belohnt, wenn er den Eindruck mache, das Projekt „im Griff“ zu haben und „schnell vorwärts“ zu kommen.

Andreas sah eine Chance: Er hatte ebenfalls ein Interesse an schnellem Vorwärtskommen, nur nicht auf Kosten der Qualität. Andreas konnte Paul erklären, wie er die Entwicklungsgeschwindigkeit im Projekt günstig beeinflussen konnte: einerseits die Schnittstellen so gut und praktisch zu entwerfen, dass die Teams vorwärtskommen, ohne aufeinander warten zu müssen. Andererseits die innere Qualität des Systems hochzuhalten und Abhängigkeiten der Komponenten zu minimieren, sodass die Entwickler sich nicht darin verstricken und langsam werden.

Paul konnte jetzt sehen, dass Andreas durch seine Maßnahmen auch zu Pauls eigenen Zielen beitrug und beide konnten eine Basis für die Zusammenarbeit finden. Andreas hatte mit diesem mutig und sofort angesetzten Meeting ein Vertrauen geschaffen, auf das er später in kritischen Projektsituationen immer wieder zurückkommen konnte. Das vereinfachte vieles für ihn.

Das endlose Designmeeting

Andreas arbeitete mit mehreren Entwicklungsteams zusammen. Zwei davon konnten sich nicht auf sinnvolle Schnittstellen einigen. Es gab mehrere gleich gute Aufteilungen dieser Schnittstellen und die Diskussion zwischen den Seniorentwicklern der beiden Teams wollte nicht enden. Sie baten Andreas darum, das nächste Designmeeting mitzumachen und mitzuhelfen, bis zum Abend zu einem Beschluss zu kommen.

Andreas bereitete das Meeting vor. Er sorgte für den Raum und die Zeit, forderte Getränke und Knabbersachen an und stellte sicher, dass genug Whiteboards, Flipchartpapier, Moderationskarten und Stifte vorhanden waren. Er versuchte, im Vorfeld etwas über die Persönlichkeiten der Teilnehmer zu erfahren, um sich darauf einstellen zu können. Andreas glaubte, er hätte an alles gedacht.

Kaum begann jedoch das Meeting, war alles anders. Andreas hatte sich vorgenommen, zu moderieren und die Ergebnisse auf Flipcharts festzuhalten. Doch plötzlich wurde er voll in die Diskussion hineingezogen, denn er hatte als Architekt natürlich seine eigene Meinung zu den Schnittstellen, um die es ging. Er verlor eine Stunde durch heftiges Mitdiskutieren, vergaß die Visualisierung der Ergebnisse und stellte dann frustriert fest: Wenn das so weiterging, würde das heute nichts mehr werden mit der Entscheidung.

Andreas trennte dann seine Moderatorenrolle von seiner Architektenrolle. Er moderierte zu 80 Prozent seiner Zeit, mischte sich, wenn überhaupt, nur ganz explizit als Architekt ein und kehrte aber sofort in die Moderatorenrolle zurück. Die Teams machte er auf jeden seiner Rollenwechsel aufmerksam. Mithilfe von Konsensverfahren half Andreas der Gruppe am Abend zu einem einheitlichen Beschluss. Er bedankte sich bei den Teilnehmern, sammelte die Flipcharts ein, fotografierte die Whiteboards und ging nach Hause. Gerade noch einmal Glück gehabt, es wäre sonst ein teures, nutzloses Meeting geworden.

Dokumentieren, bis es dunkel wird

Andreas verbrachte so manchen ganzen Tag in Meetings. Abends nach 18 Uhr, wenn Ruhe einkehrte, widmete er sich wie viele Architekten der Dokumentation. Seine Freundin war wenig begeistert, wenn er abends oft erst nach 20 Uhr nach Hause kam. Das konnte auf die Dauer nicht gut gehen.

Andreas erstellte einen Zeitplan, den er „auf ewig“ würde einhalten können, ohne dabei verrückt zu werden. Er hatte gemerkt, dass er morgens frisch und ausgeruht war, nach dem Mittagessen müde wurde und nachmittags nach 16 Uhr noch einmal ein Aufmerksamkeitshoch hatte, bis der Hunger ihn gegen 19 Uhr einholte. Er beschloss also, sich seinen Tag wie in Tabelle 2 einzuteilen.

Andreas nahm diese Tagesaufteilung als Grundlage, wenn er Termine vereinbarte. Er hielt sich nicht sklavisch daran, sondern nutzte sie als Gedankengerüst. Damit ging es ihm deutlich besser, und seine Freundin konnte beobachten, dass er neuerdings abends besser ansprechbar war.

Soft Skills praktisch einsetzen

Soft Skills hat und beherrscht jeder Mensch. Ist sich der Softwarearchitekt bewusst, dass es unterschiedliche Zielsetzungen, Werte- und Bezugssysteme geben kann, die alle gleichberechtigt sein können, erleichtert das die Zusammenarbeit mit anderen Beteiligten. Durch praktisches Training kann er seine Fähigkeiten zu visualisieren, zu kommunizieren und zu reflektieren auf unterschiedliche Szenarien ausdehnen und verbessern.

Dem Österreicher Ernst Ferstl wird der Sinnspruch zugeschrieben: „Der Unterschied zwischen Theorie und Praxis ist in der Praxis weit größer als in der Theorie.“ So ist es tatsächlich. Im Training werden Denk- und Fühlprozesse in Gang gesetzt, die in der Praxis weiterlaufen. Auch erhält jeder Rückmeldungen über die Fremdwahrnehmung der eigenen Äußerungen und Reaktionen.

Durch die bewusste Reflexion der Rückmeldungen von Kunden, Projektbeteiligten, Kollegen und Freunden wird es im Laufe der Zeit immer einfacher, mit kritischen Situationen umzugehen, eine gute Arbeitsatmosphäre herzustellen und sich gelassen auf den Projekterfolg zu konzentrieren. Die Arbeit in der Softwareentwicklung macht wieder Freude.

Referenzen