Der Prozess der Architekturentwicklung
Architekturen entstehen (hochgradig) iterativ
Es gibt keinen linearen Architekturprozess. Architekturen entstehen iterativ.
James Dyson, Erfinder des nach ihm benannten (ungeheuer lukrativen, coolen und innovativen) "beutelfreien" Staubsaugers, hat 15 Jahre lang iteriert, seine Architektur an 5000 Prototypen getestet (so berichtet die Atlantic Systems Guild in ihrem genialen Buch "Adrenalin-Junkies und Formular-Zombies" (Pattern Nr. 84, Schonzeit für Ideen). Sagt eigentlich alles, was Sie über Entwürfe komplexer Systeme wissen sollten: Hervorragende Architekturen brauchen ein paar Iterationen (manche mehr, manche weniger). Während dieser Iterationen ändern sich einige Anforderungen - und schon haben wir die Agilität im Spiel. Also: Sieht in etwa wie folgt aus: Kunde und Umwelt ändern Anforderungen, Architekten reagieren...
Sie sehen: Schleifen. Iterationen. Versuch-Scheitern-Lernen-Verbessern. So funktioniert Architektur.
Wichtige Aktivitäten von Software-Architekten
Je nach der Ausgangssituation (Neusystem, Verbesserung eines bestehenden Systems, gewünschte Einbindung von Fertigteillösungen, ...) müssen Architekten in unterschiedlicher Reihenfolge und mit unterschiedlichem Tiefgang eine Reihe von Aktivitäten durchführen:
- Anforderungen und Einflussfaktoren klären
- Strukturen entwerfen
- Aspekte konzipieren
- Architektur kommunizieren (und dokumentieren)
- Umsetzung der Architektur überwachen
- Architektur bewerten
Die Details zu den Schritten sind im Anschluß an den folgenden grafischen Prozessüberblick näher beschrieben.
1. Anforderungen und Einflussfaktoren klären
1.1 Kontext abgrenzen
Das System in Zusammenhang seiner Nachbarn beschreiben:
- logischen Kontext ermitteln (bzw. aus Requirements- Spezifikation übernehmen)
- physischen Kontext ermitteln (physische Formate von Schnittstellen und Übertragungsmedien)
1.2 Requirements verstehen bzw. vervollständigen
Diese Tätigkeit kann entfallen, wenn gut geschriebene und qualitätsgesicherte Anforderungen vorliegen. Ist dies nicht der Fall, so sollten Software-Architekten insbesondere die nicht-funktionalen Anforderungen nochmals genau hinterfragen, denn sie bilden wesentliche Einflußfaktoren für die Architektur.
1.3 Architekturtreiber und Randbedingungen ermitteln
Inbesondere sollten Sie:
- Ziele für die Architektur festlegen
- vorhandene Stakeholderlisten um architekturrelevante Stakeholder ergänzen, bzw. Stakeholder ermitteln
- Fachliche Aufgabenstellung (aus der Requirements- Spezifikation) abstrahieren oder neu erstellen
2. Strukturen entwerfen
Lesen Sie zu diesem abendfüllenden Thema die Bücher "Documenting Software Architectures - Views and Beyond", "Effektive Software- Architekturen" oder "Domain-Driven Design" (siehe unsere Bibliothek)
Trennen Sie bei dieser Arbeit besonders die fachliche Architektur von technischen Aspekten, wie das anhand der Analogie von Blutgruppen in "Moderne Software- Architektur" besonders gut beschrieben ist. (siehe unsere Bibliothek). Verwenden Sie gezielt Szenarien, um beispielhaft ausgesuchte Qualitätseigenschaften kritisch zu überprüfen.
3. Aspekte konzipieren
Lesen Sie zu diesem Thema das Buch "Effektive Software- Architekturen" oder "Domain-Driven Design" (siehe unsere Bibliothek).
4. Architektur kommunizieren
Mit Sichten und Aspekten versuchen Sie, eine möglichst vollständige Dokumentation der Software- Architekt zu erstellen. Nicht jeder im Projekt will und muss das alles lesen, verstehen und kommentieren. Deshalb gehört zu den Detailaufgaben dieser Aktivität folgende, immer wieder durchzuführenden Schritte:
Die Sichten im Überblick:
4.1 Wünsche und Bedürfnisse der Stakeholder identifizieren.
Prüfen Sie regelmäßig die Stakeholderliste, ob sie vollständig ist, wer davon über welche Teile der Architektur informiert werder muss und in welcher Form dies am besten geschieht.
4.2 Architektur kommunizieren
Zu jedem beliebigen Zeitpunkt sollten Sie die vorliegenden Erkenntnisse und Entscheidungen stakeholdergerecht zusammenfassen und präsentieren.
Extrahieren Sie aus der Gesamtheit der Architekturinformationen die Teile in der Form, wie sie für die jeweiligen Stakeholder wichtig sind in der geeigneten Form (Präsentationen, Dokumente, Übersichtslisten, ....). Achten Sie jedoch darauf, dass diese Extrakte kein Eigenleben entwickeln und aufwendig gepflegt und versioniert werden müssen. Holen Sie das Feedback der Stakeholder ein, um es entweder in die zentralen Sichten und Aspekte einbringen zu können oder die Ziele, die Randbedinungen oder den Kontext anzupassen.
5. Umsetzung der Architektur überwachen
Wenn eine Heerschaar von Designern und Programmierern die Architektur mit detailliertem Leben füllt, Source Code schreibt oder generiert, ist die Arbeit des Architekten noch lange nicht erledigt. Die Rolle des Architekten erfordert die ständige Überwachung der vorgegebenen Strukturen, sowie die zeitgerechte Einarbeitung berechtigter Änderungswünsche - d.h. die Anpassung der Architektur an neue Randbedingungen oder Erkenntnisse im Projekt. Zu diesen Aufgaben gehören regelmäßige Gespräche mit allen Personen im Projekt, die auf der Architektur aufsetzen, also hauptsächlich mit Designern und Programmierern, aber auch mit Qualitätsmanagement, insbesondere den Testern, und vielen anderen. Von diesen Gruppen erhält der Architekt Feedback bezüglich der "Tragfähigkeit" und "Brauchbarkeit" der Architektur. Dieses Wissen fließt in die ständige Weitergestaltung der Architektur ein, d.h. in Änderungen von Strukturen oder Aspekten (siehe oben). Ebenso gehört die frühzeitige Abstimmung mit Migrations- und Inbetriebnahmeteams sowie Produktion und Betrieb zu den Überwachungsaufgaben.
6. Architektur bewerten
Nutzen Sie gezielt ausgewählte Szenarien und Prototypen für die Architekturbewertung.
Lesen Sie zu dieser Aktivität "Evaluating Software Architectures - Methods and Case Studies"
Die Ergebnisse dieser Tätigkeit (offene Punkte, identifizierte Risiken, ....) sagen Ihnen, was sie weiter vorgehen sollen. Oftmals sind nur lokale Änderungen und Anpassungen an den Sichten und Aspekten vorzunehmen, manchmal müssen Sie den Regelkreis jedoch größer gestalten und aufgrund der Bewertungsergebnisse auch Ihre Ausgangssituation, die Ziele, die Randbedingungen, ... korrigieren.