Das Berufsbild „Softwarearchitektur“
Ein Artikel von Dr. Gernot Starke
Vorsicht: Artikel enthält Meinungen. Dem Autor macht Softwarearchitektur auch nach über 20 Jahren Berufserfahrung immer noch Spaß.
Bevor wir die „Rolle“ von Softwarearchitekt:innen in IT-Projekten klären können, müssen wir den Begriff „Softwarearchitektur“ verstehen: Das Wort „Architektur“ haben wir aus dem Bauwesen entlehnt und es lohnt sich, Analogien aus diesem Gebiet zu betrachten:
- Bestimmung der wesentlichen Anforderungen, etwa mit den zukünftigen Bewohner:innen, Auftraggebern und Behörden
- Grundriss: welche Räume gibt es und wie hängen sie strukturell zusammen
- Baumaterial: aus welchen Materialien werden welche Elemente des Gebäudes geschaffen?
- Entwurf der äußeren Form, Fassade, Ästhetik, städtebauliche Vorgaben
- Anbindung an benachbarte Infrastruktur, Straßen, Wasser, Strom, Internet
- Berücksichtigung von Anforderungen an Statik, Bodenbeschaffenheit, Brandschutz o.ä.
- Begleitung des Baus: Klärung offener Fragen im Prozess
In [1] finden Sie noch viel mehr Details zu diesen Grundlagen.
Abbildung 1: Beispiel Grundriss
„Softwarearchitektur“ – Was bedeutet das?
Wie bei Gebäuden auch, müssen wir verstehen: Was sind die genauen Anforderungen an die Funktionen des Systems, dessen Qualitäten (z.B. Durchsatz, Verfügbarkeit, Performance, Sicherheit) und an das gewünschte Verhalten im produktiven Betrieb. Können und dürfen wir das System im Betrieb updaten?
Mit dem Grundriss entscheiden wir über den strukturellen Aufbau von Systemen aus Komponenten, wie Packages, Namespaces, Module und Services mitsamt den jeweiligen Schnittstellen. Das sind die typischen „Kästchen-und-Pfeile“-Diagramme, denen noch wichtige Informationen über unser „Baumaterial“ fehlen: Programmiersprachen, Bibliotheken und alles, was lapidar „Tech-Stack“ genannt wird.
Die Anbindung an Nachbarsysteme – externe Schnittstellen genannt (Kontextabgrenzung) – hat ebenfalls große Bedeutung. Häufig lauern genau darin große Risiken, die erst im Produktivbetrieb zu Problemen auswachsen. [2]
Mit diesen Grundlagen können wir nun die Rolle und das Berufsbild besser einordnen.
Was muss ich tun?
Berufsbilder oder Rollen lassen sich sehr gut über die dafür notwendigen Aufgaben oder Tätigkeiten beschreiben. Für Softwarearchitektur finden Sie in Abbildung 2 einen verbreiteten Vorschlag – kompatibel mit den Vorstellungen von iSAQB® [3] und arc42 [4]. Ständiges Feedback bildet eine wichtige Grundlage für diese Aufgaben. Verbessern Sie die Architektur auf Basis der Rückmeldungen relevanter Stakeholder und hinterfragen Sie ständig, sowohl strukturelle („Grundriss“) wie auch technische Entscheidungen!
Abbildung 2: Aufgaben in der Softwarearchitektur
In Abbildung 2 finden Sie die wesentlichen Entwurfs- oder Entscheidungsaufgaben. Diese basieren auf den (hoffentlich) geklärten Anforderungen (oben links). Die Entscheidungen kommunizieren Sie den relevanten Stakeholdern (unten links), indem Sie erklären, begründen, motivieren, dokumentieren.
Die Aufgabe „Umsetzung begleiten“ führen Sie kontinuierlich und gemeinsam mit dem Entwicklungsteam durch: Beide sollten sicherstellen, dass die Implementierung auch der gewünschten Architektur entspricht. Mehr zu diesen Aufgaben finden Sie in [7].
Auf die schwierige Frage, ob und wie wir diese Aufgaben im Team verteilen, oder ob eine einzelne Person dafür zuständig sein soll, möchte ich an dieser Stelle nicht eingehen. Als Trostpflaster schauen Sie bitte in Abbildung 3 finden Sie ein Spektrum von Möglichkeiten (ursprünglich mal von Gregor Hohpe in [6] beschrieben).
Abbildung 3: Wer übernimmt die Aufgaben?
Wie geht das?
Beginnen Sie damit, die wesentlichen Aspekte und Entscheidungen Ihrer eigenen Architektur als One-Pager zu dokumentieren (siehe [5] und Abbildung 2). Damit haben Sie einen ordentlichen Teil der relevanten Grundlagen und Entscheidungen explizit gemacht, und können Feedback Ihrer Stakeholder einholen.
Abbildung 4: Architecture Communication Canvas
Auf welche Weise Sie einen für die jeweiligen Anforderungen angemessenen „Grundriss“ sowie Implementierungs- und Betriebstechnologien auswählen oder entscheiden, würde den Umfang dieses Artikels sprengen. Zum Grundriss finden Sie einige Hinweise im Artikel zum Modul Domain-Driven Design (DDD). Daneben existieren viele grundlegende Prinzipien (etwa: lose Kopplung, hohe Kohäsion, Information-Hiding, Modularität etc.) und jede Menge Patterns als Hilfsmittel. Letztlich treffen Sie Architekturentscheidungen situativ also an der jeweiligen Ausgangslage orientiert. Das klingt schwierig, und meiner Erfahrung nach IST es das auch. Genau das führt uns zur letzten Frage: Wie können Sie das lernen und
Wie komme ich dahin?
Meiner Erfahrung nach sollten Sie einige Jahre lang programmieren und damit aktiv in der Entwicklung von Software arbeiten. Das gibt Ihnen den notwendigen „Riecher“ um Unwägbarkeiten und Risiken in den Bereichen Entwurf und Architektur zu erkennen und zu umschiffen. Daneben braucht es ein großes Maß an Kommunikationsfähigkeit, und zwar mit vielen verschiedenen Stakeholdern: Je besser Sie in der Lage sind, auf die Sprachen und Ziele dieser Menschen einzugehen, desto besser werden Ihre Architekturentscheidungen. Also: üben, üben, üben – und immer schön Feedback einholen.
Fazit
Die Rolle Softwarearchitekt:in trägt meiner Ansicht nach die Verantwortung für die erfolgreiche Umsetzung von Anforderungen. Dabei treffen Sie eine Reihe grundlegender Entscheidungen, entweder allein oder mit Ihrem Team.
Eigene Erfahrungen können Sie dabei kreativ einbringen und damit positiv auf IT-Projekte und ‑Produkte einwirken. Sie müssen kommunizieren und Entscheidungen manchmal auch gegen Widerstände argumentieren. Für motivierte Entwickler:innen bedeutet Softwarearchitektur in vielen Fällen mehr Verantwortung und größere Einflussmöglichkeiten.
Möge die Macht guter Entscheidungen und wohl formulierter Begründungen mit Ihnen sein!
Links und Referenzen
- [1] Gernot Starke, Grundlagen Softwarearchitektur https://www.innoq.com/de/articles/2023/07/architektur-teil‑1/
- [2] Gernot Starke, Was ist Softwarearchitektur: https://www.innoq.com/de/articles/2023/09/grundlagen-der-softwarearchitektur-teil‑2/
- [3] iSAQB, Lehrplan zu den Grundlagen der Softwarearchitektur, https://public.isaqb.org
- [4] arc42, das Open-Source Template zur Kommunikation von Softwarearchitekturen: https://arc42.org
- [5] Architecture Communication Canvas, Open-Source: https://canvas.arc42.org
- [6] Gregor Hohpe: Architecture Elevator: Would you like architects with your architecture: https://architectelevator.com/architecture/organizing-architecture/
- [7] Gernot Starke: Aufgaben in der Softwarearchitektur: https://www.innoq.com/de/articles/2023/10/grundlagen-der-softwarearchitektur-teil‑3/
Über den Autor:
Dr. Gernot Starke, INNOQ-Fellow, Mitgründer von arc42, aim42 und iSAQB®, Speaker, Coach und Consultant. Mehr als 20 Jahre praktische Erfahrung in Softwarearchitektur in unterschiedlichen Domänen (u.a. Logistik, Telko, Finance, Engineering, Automotive, Handel).
Teilen Sie diesen Artikel:
Zum Thema passende Artikel
