Softwarearchitekt wird man nicht von heute auf morgen. In aller Regel erhält man den Titel, nachdem man viele Jahre Quellcode geschrieben und sich mit technischem Klein-Kram beschäftigt hat. Dies hat gegebenenfalls zur Folge, dass wir Architekten nicht so recht vorbereitet sind, wenn es dann darum geht, unsere Belange gegenüber Personen zu erläutern, die keinen technischen Hintergrund besitzen. Schnell läuft man also Gefahr, notwendige Maßnahmen an der falschen Stelle zu adressieren, wichtige Stakeholder zu vergessen oder – dank zu technischen Begründungen – jene gänzlich zu verschrecken.

Aus diesem Grund wollen wir uns zunächst einige allgemeine Hilfsmittel ansehen, die nicht zwangsläufig etwas mit Softwarearchitekturen zu tun haben, uns aber bspw. helfen, Gespräche besser zu planen und vorzubereiten. Es geht aber auch um konkrete Werkzeuge wie zum Beispiel Stakeholder-Maps, mit denen wir unsere Zielgruppen im Blick behalten, Issue-Maps, mit denen wir die Problemstellen überblicken können oder auch Risikomatrizen, durch die es uns leichter fällt, Maßnahmen zu priorisieren.

Ziel des Vortrags ist es, den Teilnehmern neben den Werkzeugen auch ein Gefühl dafür zu geben, welche Stolpersteine außerhalb des Softwaredesigns und der Implementierung liegen, damit diese zukünftig leichter umschifft werden können.