Softwarearchitektur

Die grundsätzliche Organisation eines Softwaresystems: seine Bausteine, deren Beziehungen untereinander und zur Umgebung sowie die Prinzipien für Entwurf und Weiterentwicklung. Architekten treffen dafür unter Unsicherheit Strukturentscheidungen, wägen Qualitätsziele gegeneinander ab und vermitteln zwischen Auftraggebern, Entwicklung und Betrieb.

Definition

Gernot Starke übernimmt die Definition des IEEE-Standards 1471: „Die grundsätzliche Organisation eines Systems, verkörpert durch dessen Komponenten, deren Beziehung zueinander und zur Umgebung sowie die Prinzipien, die für seinen Entwurf und seine Evolution gelten“ (Quelle - Effektive Softwarearchitekturen, S. 16). Daraus folgt:

• Architektur besteht aus Strukturen, also Bausteinen, Schnittstellen und Beziehungen, statisch wie dynamisch.
• Sie beschreibt eine Lösung und beruht auf Entwurfsentscheidungen, deren Folgen man oft erst viel später bewerten kann (S. 16–17).
• Sie wird in verschiedenen Sichten gezeigt, wie ein Gebäude in Grundriss, Statik- und Elektroplan (arc42).
• Sie ist nach Tom DeMarco ein „framework for change“ (S. 18).

Warum Architektur? Qualitätsziele erreichen, konzeptionelle Integrität (ähnliche Probleme ähnlich lösen), Verständlichkeit, Fokus auf Langlebigkeit statt kurzfristiger Projektziele, Unterstützung des ganzen Lebenszyklus (S. 20).

Aufgaben von Architekten

Architekten sind „Anwälte der Kunden“: Sie sorgen dafür, dass die Anforderungen umsetzbar sind und auch umgesetzt werden (S. 5). Konkret (S. 21–28):

• konstruieren: Bausteine, Schnittstellen, Strukturen, am besten im kleinen Team;
• entscheiden: Philippe Kruchten nennt das Leben eines Architekten „eine lange und schnelle Abfolge suboptimaler Entwurfsentscheidungen, die meist im Dunkeln getroffen werden“ (S. 21);
• beraten, vereinfachen, explizit machen, also Annahmen offenlegen;
• dokumentieren und kommunizieren;
• bewerten (Architekturbewertung);
• Mut haben: bewusst Risiken eingehen, auch gegen Widerstand, und nicht waghalsig sein (S. 24–25).

Wie Architektur nicht entstehen sollte: im Komitee, im Elfenbeinturm, nur auf Marketingfolien oder als „Wir machen jetzt “. Die Datenbank ist nicht die Architektur (S. 28).

Vorgehen

• Iterativ: Anforderungen und Einflussfaktoren ändern sich, der Entwurf muss folgen (S. 36). Nach Hruschka ändern sich pro Jahr 10–25 % der Anforderungen.
• Erst recherchieren, wie andere ähnliche Probleme gelöst haben. Wer eine angeblich völlig neue Lösung präsentiert, hat meist nur schlecht recherchiert (S. 37).
• Anforderungen klären: Kernaufgabe, Systemkategorie, Qualitätsziele (Softwarequalität), Stakeholder, Kontext sowie organisatorische und technische Einflussfaktoren (Kap. 3).
• Wichtige Entscheidungen dokumentieren: Problem, Auslöser, Annahmen, Risiken, verworfene Alternativen, Begründung (S. 36–37).
• Unter Druck gilt: Druck erhöht die Fehlerquote, und nach Brooks' Gesetz verzögert zusätzliches Personal ein verspätetes Projekt nur weiter (S. 56).

Smoketest für Architekturdokumente

Vier Fragen, die jede gute Architekturbeschreibung beantwortet (S. 20):

1. Welche Grundsätze, Konzepte oder Entscheidungen liegen der Lösung zugrunde?
2. Welche Verantwortung trägt jedes Kästchen und jede Linie im Diagramm?
3. Warum gibt es jede Verbindung, und was fliesst wann darüber?
4. Wie erfüllen die Bausteine die Qualitätsanforderungen?

Das architektonische Manifest

Im Nachwort „Architektonien“ schildert Starke die IT-Welt als Landkarte: Analytistan (Anforderungen), Prograland (Entwickler), La Testa (Tester), Betriebien und Kostenia (Management). Seine Ratschläge daraus (S. 424–427):

• aktiv handeln, iterativ arbeiten, mit allen reden können („Null-Rhesus-negativ-Mentalität“);
• Mut zu suboptimalen Entscheidungen, zur Lücke und zum Widerspruch; 80-%-Lösungen genügen meist;
• Structure follows Constraints: Qualitätsanforderungen und Randbedingungen prägen die Struktur stärker als die Funktionen;
• unvollständige Anforderungen akzeptieren, Anforderungen aber prüfen: „Anforderungen, die Sie sich nicht leisten können, sind keine Anforderungen“ (Suzanne und James Robertson).

Werkzeuge

Starke nennt Kategorien statt Produkte: Anforderungsmanagement, Modellierung, Generierung (auch von Dokumentation, etwa docToolchain aus AsciiDoc), Codemanagement, statische Codeanalyse, Laufzeitanalyse, Build und Konfigurationsmanagement, Test, Dokumentation. Auswahlkriterien sind Versionierbarkeit, Teamfähigkeit, Gesamtkosten, Lizenzbedingungen und vor allem die Akzeptanz im Team (Kap. 13, S. 407–411).

Verwandt

• Softwarequalität – Qualitätsziele als Treiber der Architektur
• Entwurfsprinzip – Maximen und Prinzipien des Entwurfs
• Architekturstil – bewährte Grundstrukturen
• arc42 – wie man Architektur dokumentiert
• Architekturbewertung – wie man prüft, ob sie taugt
• Conway's Law – Organisation und Architektur prägen sich gegenseitig
• Enterprise-IT-Architektur – die Ebene über einzelnen Systemen
• Angular-Architektur – Architektur einer Frontend-Anwendung
• iSAQB – Lehrplan und Zertifikat für Softwarearchitekten
• Heuristiken in BWL und Informatik – Entscheiden ohne vollständige Information