Kolumne: Knigge für Softwarearchitekten

Der Zehnkämpfer

Peter Hruschka und Gernot Starke

In der letzten Folge haben wir Sie mit dem Lehrplan des iSAQB e.V. [1] bekannt gemacht. Einer der wichtigsten Punkte auf Ihrem Weg zum Zertifikat „CPSA-F“ (Certified Professional for Software Architecture, Foundation Level) ist ein solides Verständnis des Berufsbilds eines Softwarearchitekten.

Softwarearchitekten – die Zehnkämpfer der IT

Wir teilen die (verbreitete) Meinung, dass Softwarearchitekten Technologie gut kennen müssen, um die wesentlichen technischen Entscheidungen für ein System treffen und verantworten zu können. Softwarearchitekten müssen darüber hinaus über eine Vielzahl weiterer Fähigkeiten verfügen und entsprechende Aufgaben erledigen können. Die verantwortungsbewussten Über-den-Tellerrand-Gucker bilden in Projekten ein wichtiges Bindeglied zwischen unterschiedlichen Stakeholder-Gruppen wie Managern, Requirements Engineers, Entwicklungsteams, Testern und Administratoren oder Hardwareingenieuren.

Aufgaben von Softwarearchitekten

Unserer Ansicht nach müssen Softwarearchitekten sechs wichtige Aufgaben lösen, um eine angemessene, qualitativ hochwertige Lösung zu gegebenen Anforderungen entwickeln zu können. Das erscheint Ihnen zuviel, weil „System entwerfen“ sich nach nur einer einzigen Aufgabe anhört? Softwarearchitekten müssen aber in der Tat etwas mehr leisten (Abb. 1):

  • Anforderungen klären: Machen Sie sich ein Bild von Qualität und Stabilität der Anforderungen. Bessern Sie nach, was Sie für sinnvoll halten. Fordern Sie insbesondere explizite, konkrete und operationalisierte Qualitätsziele von Ihren Kunden oder Auftraggebern ein. Grenzen Sie Ihr System fachlich und technisch sauber von allen bekannten Nachbarsystemen ab.
  • Strukturen entwerfen: Dies gilt oft als die Hauptaufgabe von Softwarearchitekten. Sie müssen die grundlegenden Bausteine des Systems festlegen und für alle Projektbeteiligten nachvollziehbar dokumentieren. Das Ergebnis dieser Tätigkeit – die Strukturen des Systems – ist vor allem für die Entwickler die maßgebliche Vorgabe, denn sie müssen gemäß dieser Strukturen und den Architektenentscheidungen das System implementieren. Ähnlich wie Sie sich als Hauskäufer wahrscheinlich für mehrere Strukturen interessieren (etwa: Grundriss, Elektro-, Heizungs- und Wasserleitungsplan), stehen Ihnen für die Architektur mehrere relevante Strukturen oder Sichten auf das System zur Verfügung [2].
  • Technische Konzepte entwerfen: Manche Entwurfsentscheidungen gelten über einzelne Bausteine hinweg und schlagen sich an vielen Stellen im Quellcode nieder. Solche übergreifenden Themen sollten Sie zentral und redundanzfrei behandeln. Wir schlagen dafür „technische Konzepte“ vor. Mit denen legen Sie Lösungsansätze fest, die bei der Entwicklung unterschiedlicher Bausteine konsistent angewendet werden. Beispiele solcher Konzepte sind Datenspeicherung, Benutzeroberfläche, Transaktions- oder Sessionbehandlung.
  • Architektur kommunizieren: „Wenn Sie glauben, dass Ihre Architektur gut ist, so haben Sie sie noch niemandem gezeigt“, sagt ein bekanntes Bonmot, dem wir voll zustimmen. Zu Ihren immer wiederkehrenden Tätigkeiten als Architekt gehört es, allen Stakeholdern – nicht nur dem Entwicklungsteam – die Architektur in geeigneter Weise zu vermitteln. Nur so erhalten Sie von den Stakeholdern das für Sie wertvolle Feedback zu Entwurfs- und Technologieentscheidungen.
  • Umsetzung begleiten: Ihre Rolle und Ihre Verantwortung erfordert die kontinuierliche Überprüfung und Überwachung der vorgegebenen Strukturen sowie die zeitgerechte Einarbeitung berechtigter Änderungswünsche. Sie passen regelmäßig die Architektur (oder Teile davon!) an neue Anforderungen, Randbedingungen oder Erkenntnisse im Projekt an. Zu diesen Aufgaben gehört die regelmäßige Kommunikation mit dem Entwicklungsteam.
  • Architektur bewerten: Prüfen Sie systematisch, ob die Architektur die Qualitätsziele überhaupt erreichen kann oder ob Nachbesserung notwendig ist.

Diese Aufgaben beeinflussen sich gegenseitig. In der Praxis werden Sie an mehreren dieser Aufgaben parallel arbeiten.

Abb. 1: Die vielfältigen Aufgaben von Softwarearchitekten

Die Pfeile in Abbildung 1 zeigen, wo Aktivitäten sich gegenseitig beeinflussen. Den gesamten Prozess sollten Sie möglichst iterativ organisieren, d. h. die Ergebnisse der einzelnen Aktivitäten in Abhängigkeit von der Rückmeldung Ihrer Stakeholder verfeinern oder überarbeiten.

Warum Zehnkämpfer?

Sechs Aktivitäten, aber Zehnkämpfer im Titel? Doch, wir können zählen … Die Helden der Leichtathletik waren uns ein Vorbild – und in [3] haben wir diesen Vergleich durch zehn Fähigkeiten (als Ergänzung zu den sechs Tätigkeiten) ausführlicher erläutert.

Der iSAQB-Lehrplan

Der iSAQB-Lehrplan gibt zu Grundlagen von Softwarearchitektur sowie Aufgaben von Softwarearchitekten (u. a.) folgende Lernziele vor:

Können

  • Die Gemeinsamkeiten einiger Definitionen von Softwarearchitektur benennen, insbesondere Komponenten, Strukturen, Abhängigkeiten, Entwurfsentscheidungen.
  • Softwarearchitektur als Beschreibung der Lösung sowie Unterstützung zu deren Erstellungsprozess.
  • Zusammenhang von Architekturmodellen und Quellcode.
  • Nutzen und Ziele benennen und erklären, insbesondere den Fokus auf Qualitätsmerkmalen wie Langlebigkeit, Wartbarkeit, Effizienz gegenüber der reinen Funktionalität.
  • Differenzierung zwischen Projektzielen (oft kurzfristig) und Architektur- oder Qualitätszielen (meist langfristig).
  • Rolle von Softwarearchitekten im Zusammenhang mit anderen Stakeholdern erklären. Aufgaben von Softwarearchitekten benennen und erklären können
  • Bedeutung von Architektur-/Qualitätszielen, Randbedingungen und Einflussfaktoren für die Gestaltung von Architekturen aufzeigen. Abgrenzung von (oft langfristigen) Architekturzielen gegenüber (oft kurzfristigen) Projektzielen. Auf Basis bestehender Anforderungen Architekturziele identifizieren und präzisieren.
  • Konsequenz von Architekturentscheidungen erkennen und benennen, gegenüber anderen Stakeholdern argumentieren.
  • Zwischen Strukturen und Konzepten differenzieren.
Verstehen

  • Softwarearchitekturen sind eine Beschreibung einer Lösung, nicht die Lösung selbst
  • Softwarearchitekturen unterstützen die Erreichung nichtfunktionaler Qualitätsmerkmale
  • Softwarearchitekten tragen die Verantwortung für die Erreichung der geforderten Lösungsqualität
Kennen

  • Architekturebenen wie Enterprise-IT-Architekur (Struktur von Anwendungslandschaften), Infrastrukturarchitektur (technische Infrastruktur wie Hardware und Netze) und Softwarearchitektur (Strukturen und Konzepte einzelner Softwaresysteme).
Peter Hruschka und Gernot Starke haben vor einigen Jahren www.arc42.de ins Leben gerufen, das freie Portal für Softwarearchitekten. Sie sind Gründungsmitglieder des International Software Architecture Qualification Board sowie Autoren mehrerer Bücher rund um Softwarearchitektur, Softwareentwurf und Entwicklungsprozesse.
Geschrieben von
Peter Hruschka und Gernot Starke
Kommentare

Schreibe einen Kommentar

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