System-Architekturen erstellen (Part 1)
Um was geht es hier?
Jeder, der schon einmal in einer Situation war, eine Systemarchitektur definieren zu müssen, ist auf folgende Herausforderungen gestoßen.
- Wie komme ich zu einer System Architektur?
- Wie kann ich meine System-Architektur dokumentieren?
Auf die erste Frage möchte ich in diesem Beitrag eingehen und einen Leitfaden vorstellen, der den Einstieg in die Welt der System-Architekturen erleichtern soll. Auf die zweite Fragen werde ich in einem nachfolgenden Beitrag eingehen.
Big Architecture – Front up
Dies ist der klassische Ansatz.
- Sammeln aller Anforderungen
- Definiere anschliessend eine System Architektur, die alle Anforderungen erfüllt.

In der Praxis stellen sich hierbei folgende Nachteile heraus:
- Das Sammeln der Anforderungen erfordert zum Teil viel Zeitaufwand
- Feedback und Beurteilung der gewählten System-Architektur erst möglich, nachdem alles umgesetzt ist.
Bessere und schnellere Erfolge erziehlt man daher mit einem agilen Ansatz.
Der agile Ansatz
Beim agilen Ansatz lautet das Prinzip:
YAGNI -> You aren’t gonna need it
Vergleiche: Dzone yagni-a-quick-introduction
Dies bedeutet, dass in der Architektur nur dann Komponenten und Subsystem eingeführt werden, wenn diese auch wirklich benötigt werden.
Abb.: Agiler Ansatz
Das Vorgehen ist hierbei wie folgt:
Schritt | Tätigkeit |
---|---|
1 | Bestimme die minimalste Menge von Features, die im ersten Schritt umgesetzt werden müssen |
2 | Definiere eine dazugehörige System-Architektur |
3 | Implementiere die System-Architektur |
4 | Prüfen, ob die System-Architektur die gewünschten Funktionen und Eigenschaften besitzt (Erfahrung sammeln) |
5 | ggf. Re-Factoring der System-Architektur |
6 | Definiere und bestimme die Menge der Features, die im nächsten Schritt unterstützt werden sollen/müssen. |
7 | Wiederhole Schritt 2 bis Schritt 6 so lange, bis alle Anforderungen/Features umgesetzt sind. |
In der Praxis bedeutet dies, dass in Schritt 2 die System-Architektur ggf. erweitert oder geändert werden muss (Re-Factoring) um die jeweiligen Features zu implementieren.
Aus dem Vorgehen wird ersichtlich, dass
- man sehr schnell zu einem lauffähigen System kommt
- frühzeitig Erfahrung machen kann um das System-Model zu verifizieren
- Das System-Modell wächst mit der Zeit und deckt genau die Anforderungen ab, die benötigt werden.
- Ein Over-Engineering wird vermieden