Inhalte
Ein systematischer Ansatz für die Erstellung von Software- und Systemarchitekturen.
Architektur erstellen – eine Frage der Erfahrung?
Auf die Frage, wie man eine Software Architektur erstellen soll, antworten viele Software- und Systementwickler, dass das eine Frage der Erfahrung sei. Meist bestimmen die erfahrensten Entwickler die Architektur eines Systems. Vielfach werden Grundmuster einer Architektur, basierend auf bestehenden Strukturen und vorhandenen Elementen, erstellt.
Für eine umfassende Definition und Erklärung des Software Architektur Themas und der Einordnung dieser Thematik siehe hier: Software Architektur ist nicht komplex – Software Architektur einfach und klar.
Das ist sicher nicht falsch. Vielfach sind in einem Unternehmen die Problemstellungen der zu entwickelnden Systeme auch sehr ähnlich und es macht deshalb Sinn sich aus dem Erfahrungsschatz zu bedienen.
Wie ist aber sichergestellt, dass die Architektur, welche ausgewählt wurde auch wirklich die richtige für das zu bauende System ist? Diese Frage ist nicht ganz einfach zu beantworten. Denn man kann ein System mit vielen verschiedenen Architekturen bauen und mit jeder die geforderten funktionellen Anforderungen erfüllen. In meinen Schulungen und Workshops verwende ich immer ein gut vorstellbares Beispiel um diese Thematik zu veranschaulichen:
Gleiche Anforderungen – unterschiedliche Architekturen
Stellen Sie sich vor, Sie hätten die Anforderungen bekommen eine Rechensoftware zu erstellen, welche die Grundoperationen für ganze Zahlen beherrscht – also Addition, Subtraktion, Multiplikation und Division. Wie bauen Sie nun ein solches Softwaresystem?
Welche Grundstruktur (=Architektur) hat diese Software? Man könnte beispielsweise ein Kommandozeilen basiertes Programm erstellen, welche die 2 Zahlen einliest und das Resultat nach Angabe der Rechenoperation ausgibt. Oder aber man erstellt eine Windows DLL, welche die Grundoperationen einem User Interface Programm als Library zur Verfügung stellt. Damit lässt sich ein Taschenrechner mit grafischer Benutzeroberfläche unter Windows erstellen.
Beide Varianten erfüllen die gestellten Anforderungen zu 100%, obwohl die Grundstrukturen der beiden Systeme d.h. die Architekturen sehr unterschiedlich sind.
Woher kommt der Unterschied?
Der Unterschied ist, dass verschiedene Ziele für die beiden Systeme verwendet wurden. Häufig ist es so, dass diese Ziele nicht explizit als Input verwendet werden, sondern die verschiedenen Stakeholder dies implizit erwarten. Wenn diese Ziele beim erstellten System nicht erreicht werden, dann sind die Stakeholder mit dem System nicht zufrieden – obwohl die funktionellen Anforderungen erfüllt wurden.
Die Erkenntnis:
Man kann ein System bauen, bei dem alle funktionellen Anforderungen erfüllt sind und doch die Erwartungen der Stakeholder nicht erreicht werden.
Wie schaffe ich es die Erwartungen der Stakeholder zu erfüllen?
Nebst den funktionellen Anforderungen müssen weitere Inputs bei der Architekturerstellung herbeigezogen werden. Es sind dies die Qualitätsanforderungen sowie Rahmenbedingungen.
Beispiele für Qualitätsanforderungen sind:
- Das System muss in verschiedenen User Interface Umgebungen eingesetzt werden können (Graphisch, Kommandozeilenbasiert, Webbasiert)
- Das System muss um weitere Rechenoperationen per Konfiguration erweitert werden können.
Beispiele für Rahmenbedingungen sind:
- Das System basiert auf einer Windows Umgebung
- Das System wird mit dem .NET Framework aufgebaut
Man sieht hier, dass sich die Rahmenbedingungen auf den Lösungsraum beziehen. D.h. sie bestimmen bereits Teile der Lösung. Die Qualitätsanforderungen hingegen definieren neben den funktionellen Anforderungen oft die längerfristigen Ziele.
Attribute Driven Design – ein systematischer Architektur-Prozess
Wir haben mit der Frage gestartet, wie eine Architektur erstellt werden soll. Basierend auf diesen Erkenntnissen ist es essentiell, dass eine Architekturerstellung systematisch anhand aller vorhandenen Inputs erfolgt. Ein solches systematische Vorgehen wird durch die Anwendung des „Attribute Driven Design“ Prozesses sichergestellt.
In folgender Sketchnote habe ich das Wesentliche dieser Methodik in einem Bild zusammengefasst:
Übrigens: Auch in dieser Methodik steckt die Verwendung von Erfahrungen und existierenden Strukturen drin. Diese sind explizit im Schritt 4 zu finden.
Viel Erfolg bei der systematischen Erstellung Ihrer zukünftigen Architekturen. Unterstützungsmöglichkeiten hierzu finden Sie hier: Consulting Pakete.
Matthias Künzi
Hallo Matthias,
wenn man dein Architekturbeispiel einmal in eine andere Branche verlangert, wird klar, warum es nicht funktionieren kann:
Man nehme mal den erfahrensten Maurer auf einer Baustelle und mache ihn zum Architekten für die nächste Baustelle. Während sich der Maurer gut mit der Mischung von Mörtel und dem Vermessen und Ausrichten von Steinen auskennt, benötigt der Architekt einen Überblick über das ganze Gebäude, Ausrichtung zur Himmelrichtung, Türen, Fenster, Treppen, Statik. Es sind also gänzlich unterschiedliche Qualifikationen, denn der Maurer wird vielleicht aus Erfahrung den Fenstersturz richtig dimensionieren und herstellen, bei für ihn neuen Problemstellungen wird er allerdings mit großer Chance versagen.
Der Hauptfehler liegt also in der Annahme, dass diejenigen, die ein System bauen, es auch konstruieren können, obwohl dafür ein ganz anderer Werkzeugkasten notwendig ist. Statt Hammer und Kelle sind beim Architekten eher CAD und Statikberechnung gefordert.
Bei der Erstellung einer Software-Architektur sollte immer auch die Qualitätsanforderung Testbarkeit mit einfließen, sie ist Grundvoraussetzung für eine nachfolgende agile Software Entwicklung. Nur Systeme mit einer sauberen hirarchischen Systemstruktur lassen auch eine saubere Requirements- und Teststufendefinition zu und sind auch längerfristig wartbar.
Viele Grüße von der Ostsee
Markus