Veröffentlicht am

Vom Entwickler zum Architekten: Teil 1

Einem erfahrenen Softwareentwickler kann es passieren, dass er im Lauf der Zeit immer mehr in die Arbeit eines Softwarearchitekten rutscht und den Übergang vom Schreiben von Code zum Design von Systemen vollzieht – zuerst für Offerten, bald aber auch in der Umsetzungsphase. So ist es auch mir ergangen. Trotz eines Informatikstudiums im Rücken fühlte ich mich in der Vergangenheit bei kniffligen Architekturaufgaben aber manchmal etwas unsicher: Mache ich das richtig? Gibt es vielleicht einen besseren Weg Architekturfragen anzupacken als den von mir eingeschlagenen? Um meine Methodik der Erstellung von Softwarearchitekturen auf eine solidere Basis zu stellen, habe ich beschlossen, mich im Rahmen eines Kurses intensiver damit auseinanderzusetzen. Meine Erfahrungen auf diesem Weg möchte ich in drei Blogposts schildern – willkommen bei Teil 1!

Folgende Fragen haben mich in den letzten Jahren als Softwarearchitekt beschäftigt:

  • Was genau umfasst eine Softwarearchitektur?
  • Was genau umfasst die Arbeit eines Softwarearchitekten?
  • Gibt es eine Methodik, der ich folgen kann?
  • Wie kann ich die Softwarearchitektur den diversen Stakeholdern im Projekt gut kommunizieren?
  • Wie kann die Güte einer Architektur gemessen werden?

Der oben angesprochene Kurs, der in meiner Zertifizierung als Softwarearchitekt ISAQB Foundation Level gipfelte, hat mir dabei geholfen, diese Fragen zu klären. Und auch Fragen, die ich mir bisher nicht gestellt hatte (aber besser hätte sollen). Im Vorfeld des Kurses hatte ich mich intensiv mit dem Buch «Effektive Softwarearchitekturen – Ein praktischer Leitfaden» von Dr. Gernot Starke auseinandergesetzt. Da mein Informatikstudium bereits ein paar Jahre zurückliegt, kam das Studium dieses Buches gelegen, um festgefahrene Mechanismen und Meinungen meinerseits zu hinterfragen und aufzubrechen.

Die Gretchenfrage

Beginnen wir mit der Gretchenfrage: Was ist Softwarearchitektur?

In erster Linie unterstützt die Architektur den herausfordernden Übergang von der Problemanalyse zur konkreten technischen Lösung. Schliesslich wird ein zu implementierendes System basierend auf seinen Komponenten und deren Beziehungen untereinander beschrieben. Wichtig ist, dass Architektur weit mehr ist als das Skizzieren einer technischen Lösung! Eine gute Architektur ermöglicht:

  • Herr werden über Einflüsse: Neben den funktionalen Anforderungen wird die Architektur unter anderem auch von Budget, Qualitätsanforderungen (auch «nicht-funktionale Anforderungen» genannt), organisatorischen Randbedingungen, rechtlichen Vorgaben oder gar von Politik beeinflusst. Softwarearchitektur kann diese Einflüsse aufzeigen und behandeln.
  • Herr werden über Komplexität: Architekturen dienen dazu, komplexe Anforderungen explizit zu machen und sie in umsetzbare Strukturen zu übersetzen.
  • Effektive Kommunikation: Architektur kann technische Systeme aus verschiedenen Blickwinkeln («Sichten») zeigen und hilft so allen Beteiligten, verständlich und wirksam miteinander über ein System zu sprechen. Diesem Thema widme ich Teil 2 dieser Blogserie.
  • Iterative Verbesserungen: Eine Softwarearchitektur entsteht iterativ und somit begleitend zur eigentlichen Entwicklung des Systems. Entscheidungen, die zu Beginn des Projektes gefällt wurden, sollen während der Umsetzung kritisch hinterfragt und gegebenenfalls angepasst werden.
  • Ziele im Blick behalten: Die Architektur eines Systems soll langfristige Ziele abbilden und mögliche Zielkonflikte mit (eher kurzfristigen) Projektzielen auflösen.
  • Unterstützung des Lebenszyklus: Richtig angegangen unterstützt Architektur den gesamten Lebenslaufs eines Systems: Von der Anforderungsanalyse über Entwicklung bis zum Betrieb von Systemen.

Nun da wir eine Idee davon bekommen haben, was Softwarearchitektur ist: Was ist denn die Rolle des Architekten? Softwarearchitekt zu sein bedeutet viel mehr, als nur Anforderungen des Kunden in eine geeignete technische Struktur abzubilden und dann den Entwicklern die Umsetzung zu überlassen.

Folgende Grafik zeigt die wesentlichen Aufgaben des Softwarearchitekten.

(Quelle: Arc42)

Von der Wichtigkeit des breiten technischen Portfolios

Der Architekt klärt die Anforderungen und Randbedingungen und giesst diese in ein System, indem er Strukturen (Komponenten und ihre Beziehungen) sowie querschnittliche Konzepte entwirft und festhält. Er kommuniziert die Architektur gegenüber den relevanten Stakeholdern – zum Beispiel dem Product Owner, dem Entwicklungsteam, der Projektleiterin, dem Testteam, dem Betreiber etc.) – und begleitet die Umsetzung. Die Pfeile in der obigen Grafik signalisieren, dass es sich um einen agilen Prozess handelt. Ein Softwarearchitekt ist also nicht «nur» ein «Techie», er ist auch Vermittler zwischen den Stakeholdern. Im Endeffekt verantwortet er das System, das umgesetzt wird. Dieser Umstand setzt mich etwas unter Druck: Kenne ich

genügend gut, um stets zur richtigen Entscheidung zu gelangen? Nützlich ist hier der Aufbau eines eigenen breiten technischen Portfolios, das man im Sinn des persönlichen Wissensmanagements stetig erweitert (was bei EBP angesichts der Fülle unserer Projekte gut gelingt). Meines dokumentiere ich vorzu in Form eines Mindmaps.

Das ewige Balance-Spiel: Ausgleich von Zielkonflikten

Darüber hinaus stellt sich immer die Frage, ob man mit seinen Architekturentscheidungen allen Anforderungen und Rahmenbedingungen gerecht wird. Folgendes Zitat von Philippe Kruchten bringt das bisweilen herrschende Gefühl etwas düster auf den Punkt:

«The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark».

Offenbar bin ich nicht alleine mit meinen Sorgen! Zeit, diese zu teilen: Softwarearchitektur darf nicht im stillen Kämmerlein entstehen. Wenn Sie mit Architekturfragen betraut sind: Beziehen Sie die wesentlichen Stakeholder früh in den Prozess mit ein – etwa die (Senior-)Softwareentwickler und -entwicklerinnen, an die Sie technische Abklärungen delegieren. Holen Sie rechtzeitig Feedback ein von den Security-Profis und den Betriebsspezialisten. Diese und ähnliche Schritte steigern meiner Erfahrung nach die Qualität von Entscheidungen massgeblich. Und sie sorgen gleichzeitig dafür, dass das Wissen im Projekt besser verteilt und somit ein gängiges Projektrisiko eliminiert ist.

Next up: In Teil 2 meiner Blogserie möchte ich gezielt auf ein weiteres Kästchen im obigen Bild eingehen, nämlich auf das Kommunizieren der Architektur.