Spoiler-Alarm: Die eine, perfekte, Software Architektur gibt es nicht.
Beim Start eines neuen Projektes stellt sich ein Entwicklungsteam immer die Frage: „Wenn ich von 0 weg beginne, welche Architektur nehme ich am besten?“ Diese Frage wird leider oft aus dem Bauch heraus beantwortet, anstatt strategisch geplant und analysiert.
Wenn man sich einen virtuellen Marktplatz vorstellt, der verschiedenste Architektur-Patterns anbietet, dann wird man nahezu erschlagen von Angeboten, wie zum Beispiel: Monolithische Architektur, Microservices, CQRS, Event-Driven, und vieles mehr. Zum großen Bedauern muss man festhalten, dass es keine Architektur, die über allen anderen steht, gibt.
In diesem Beitrag haben wir aber 3 hilfreiche Schritte zur Wahl der richtigen Software Architektur zusammengefasst.
Was ist Software Architektur?
Software Architektur bezieht sich auf die grundlegende Struktur eines Softwaresystems und ist die Basis für ein erfolgreiches Produkt. Sie beschreibt, wie die verschiedenen Komponenten und Module einer Software organisiert und miteinander verbunden sind. Das heißt, die Software Architektur legt fest, wie die einzelnen Teile einer Softwarelösung zusammenarbeiten, um die funktionalen und nicht-funktionalen Anforderungen zu erfüllen.
Was ist das Ziel der richtigen Software Architektur?
Das Hauptziel der richtigen Software Architektur ist es, eine stabile Grundlage zu schaffen, die es ermöglicht, ein System zu entwickeln, das zuverlässig, effizient und anpassungsfähig ist. Eine von Beginn an gut überlegte Architektur erleichtert die Weiterentwicklung, Wartung und den Betrieb der Software über ihren gesamten Lebenszyklus hinweg.
Die 3 Schritte zur Wahl der richtigen Software Architektur
Wir haben die Wahl der richtigen Software Architektur in 3 hilfreichen Schritten heruntergebrochen.
Schritt 1: Problem verstehen
Der erste und vielleicht wichtigste Schritt ist, das Problem, das die Software lösen soll, vollständig zu verstehen. Oftmals erscheinen Probleme zu Beginn trivial, aber durch tiefgehende Gespräche mit Stakeholdern und NutzerInnen offenbaren sich Komplexitäten, die zuvor nicht sichtbar waren.
Fragen, die vorab geklärt werden sollten:
- Welches Problem soll die Software lösen?
- Ist es ein komplexes oder einfaches Problem?
- Wie viele Benutzer werden die Software verwenden?
- Wie oft und unter welchen Bedingungen wird sie genutzt?
Darüber hinaus sollten auch Fragen zum technologischen und organisatorischen Kontext auf Kundenseite sowie intern geklärt werden. Ein wichtiger Aspekt, der berücksichtigt werden soll, ist welchen geschäftlichen Wert die neue Software für das Unternehmen spielt.
Um all diese relevanten Fragen zur Wahl der richtigen Software Architektur zu beantworten, können verschiedene Tools und Methoden eingesetzt werden wie das Business Model Canvas, Event Storming, Domain Story Telling oder User Story Mapping.
Aus den Antworten und Ergebnissen ergeben sich Qualitätsattribute wie Skalierbarkeit, Verfügbarkeit und Wartbarkeit, die die Wahl der Architektur stark beeinflussen.
Schritt 2: Planung
Nachdem das Problem verstanden wurde, geht es in die Planung. In diesem Schritt wird die Architektur modelliert und die Anforderungen an die Software weiter konkretisiert. Ein hilfreiches Tool hierfür ist die C4-Notation, die sowohl eine High-Level-Übersicht bietet, als auch detaillierte UML Sequenzdiagramme, die später die Abläufe im Code beschreiben.
Ein wichtiger Aspekt beim Planen ist die Dokumentation. Sehr bewährt hat sich hier Arc42, ein Template, um niederzuschreiben, welche Erkenntnisse man hinsichtlich der Software Architektur und dem Systemdesign gewonnen hat. Eine ergänzende Methode zur Unterstützung des Architektur-Lebenszyklus sind Architectural Decision Records (ADR). Diese helfen dabei, die getroffenen Entscheidungen zu erklären, wenn es darum geht, ein Problem zu lösen. Die dokumentierten Entscheidungen reflektieren den aktuellen Kenntnisstand und stellen die beste Einschätzung dar. Sie sind jedoch nicht in Stein gemeißelt und können, falls notwendig, später durch eine neue ADR angepasst oder überschrieben werden.
Zusammenfassung der wichtigsten Planungsaspekte:
- Qualitätskriterien: Wie kann die Architektur so gestaltet werden, dass sie mit wachsenden Anforderungen Schritt hält?
- Dokumentation: Verwenden Sie bewährte Methoden wie Arc42 und Architectural Decision Records (ADR), um die Architektur zu erläutern, sowie Entscheidungen zu dokumentieren und diese nachvollziehbar zu machen.
- Systemfragen: Stellen Sie hypothetische und kritische Fragen wie „Was passiert, wenn …?“, um das System auf mögliche zukünftige Anforderungen vorzubereiten.
Schritt 3: Programmierung
Erst nach umfassender Problemklärung und Planung beginnt die eigentliche Programmierung. Auch hier sollte man sich nochmal Gedanken machen: Was wird wirklich gebraucht? Die Whirlpool-Methode verfolgt einen explorativen Problemlösungsansatz. Dabei wird zunächst ein Proof of Concept mit dem aktuellen Systemverständnis erstellt, indem eine erste Modellstruktur sowie grundlegende Dummy-Implementierungen entwickelt werden. Anschließend wird überprüft, ob diese Ergebnisse die Anforderungen erfüllen. Ist dies der Fall, folgt die Implementierung konkreter Funktionalitäten.
Ein dazu begleitender, iterativer Ansatz, wie zum Beispiel Behavior-Driven Development (BDD) mit Test-Driven-Development (TDD) hilft, die Anforderungen Schritt für Schritt umzusetzen und die Architektur zu testen.
Tipps für die Programmierung:
- Explorative Ansätze: Beginnen Sie mit einem Proof-of-Concept, um die geplante Architektur in der Praxis zu validieren.
- Good Enough-Prinzip: Implementieren Sie zu Beginn nur das, was für den aktuellen Stand ausreichend ist, und erweitern Sie das System iterativ.
- Laufende Iteration: Überprüfen und adaptieren Sie die Architektur kontinuierlich, um auf neue Anforderungen reagieren zu können.
Fazit
Es gibt keine perfekte oder richtige Software Architektur. Entscheidend ist, wie der Weg zur richtigen Architektur für das entsprechende Softwareprojekt gewählt wird. Gehen Sie methodisch vor: Verstehen Sie das Problem, planen Sie sorgfältig und programmieren Sie iterativ. Diese Schritte helfen Ihnen, eine Architektur zu wählen, die nicht nur für den Moment, sondern auch für zukünftige Anforderungen geeignet ist.