Architektur mit System - Ein systematischer Ansatz für die Erstellung von Software- und Systemarchitekturen

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:

 

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 Kommandozeilenbasiertes 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 graphischer 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.

 

Das führt zu folgender wichtiger Erkenntnis:

 

Wie vermeide ich ein solches Risiko?

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.

 

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 Vorgehen ist die Attribute Driven Design Methode (ADD) definiert vom Software Engineering Institute (Siehe: https://www.sei.cmu.edu/architecture/tools/define/add.cfm).

 

In folgender Sketchnote habe ich das Wesentliche dieser Methodik auf einem Bild zusammengefasst:

(Diese Sketchnote wurde mit dem iPad Pro dem Apple Pencil sowie mit der App "Paper" von Fifty Three erstellt)

Ü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.

Matthias Künzi