Nicht nur die zu Beginn unserer Blogserie erwähnten Pyramiden von Gizeh oder die römischen Aquädukte sind architektonische Meisterwerke – auch im Systems-Engineering bedarf es Architekten, die ihr Handwerk verstehen. Dabei handelt es sich zwar um zwei völlig unterschiedliche Berufsbilder, jedoch ist der Vergleich gar nicht so weit hergeholt, wie es zunächst scheinen mag.
Systemarchitekten zerbrechen sich zwar (zumindest in der Regel) nicht den Kopf über Statik oder Ornamente, stattdessen aber über interne sowie externe Interfaces, das Zusammenspiel zwischen Komponenten eines Systems als auch die Zuordnung von Funktionen zu diesen.
Nicht selten wird von uns Requirements-Engineers erwartet, auch umfassende Kenntnisse im Bereich der Architektur zu besitzen. Die Herausforderung oder das Problem, welches sich aus dieser Erwartung heraus ergibt, ist, dass Analyse und Architektur eigentlich iterativ, weitestgehend getrennt voneinander erfolgen sollten. Das bedeutet in erster Linie, dass die Systemanalyse zusehends architekturunabhängig bleiben sollte, um dem Architekten mehr Freiheit in der Erstellung der Architektur zu gewähren und so die optimale Lösung generieren zu können.
In vielen Systems-Engineering Projekten, die nach dem V-Model vorgehen…
…beginnt die Entwicklung mit der Systemanalyse. Im Anschluss an diese folgt dann der erste Architekturschritt auf Systemebene, im Zuge dessen das System in Komponenten heruntergebrochen wird und diesen Grobanforderungen sowie Tasks, die aus der Analyse resultieren, zugeordnet werden. Erst dann erfolgt die Analyse der einzelnen Komponenten, in welcher detaillierte Anforderungen an die jeweilige Komponente erhoben werden. Danach folgt das Feindesign auf Komponentenebene. Dieses Vorgehen wiederholt man nun so lange, bis man auf tiefster Ebene angelangt ist. Was dabei die tiefste Ebene bildet, unterscheidet sich von Projekt zu Projekt. In Abhängigkeit von der Komplexität des betrachteten Systems können Komponenten auch noch in Subkomponenten unterteilt werden. Auch die Nomenklatur der Ebenen unterliegt keiner Vorgabe und ist somit in sämtlichen Variationen zu finden. Wir sprechen hier in unserer Serie von Systemen, die in Komponenten, welche wiederum ggf. in Subkomponenten aufgeteilt werden.
Im Projektalltag…
…jedoch werden die Analyse und die Architektur oftmals wie bereits erwähnt in einem Schwung, also parallel zueinander durchgeführt oder die Architektur steht gar (z.B. aus der Historie heraus geboren) schon von Beginn der Entwicklung an fest. Das hat zur Folge, dass sich die Spezifikation an der Architektur orientieren muss und nicht wie im Idealfall umgekehrt.
Leider stellen wir immer wieder fest, dass die Einhaltung der Vorgabe eher utopisch ist und die entsprechenden Prozesse oft nicht oder nur teilweise gelebt werden. In den meisten Projekten werden bereits zu Beginn der Analyse implizit Architekturentscheidungen getroffen. Enthält eine Anforderung auf Systemebene beispielsweise bereits dediziert eine Zuordnung zu einer Komponente, welche zur Realisierung dieser Anforderung beitragen soll, so ist der Systemarchitekt in seiner Arbeit enorm eingeschränkt. Als Konsequenz dieser Verkleinerung des Lösungsraums wird häufig an bereits bestehenden Architekturen festgehalten oder diese sogar zu großen Teilen, z.B. aus der Vorgängerserie, übernommen.
Als erschwerender Faktor kommt hinzu, dass sich die Verantwortlichen häufig nicht darüber im Klaren sind, wie ihr System, Komponente oder Subkomponente (je nachdem, was betrachtet wird) abgesteckt ist. Eine saubere Dokumentation des Kontexts findet man nur selten. Was das zur Folge hat? Es werden Anforderungen formuliert, welche für den Betrachtungsgegenstand irrelevant sind oder laut Architektur einem anderen Teil des Systems zugeordnet wurden. Oftmals entwickeln sich dadurch intransparente, d.h. nicht für jeden einseh- oder lesbare Architekturen. Wie es Ihnen in Ihrem Projekt gelingt und welche Möglichkeiten Sie haben, eine Architektur fachgerecht zu dokumentieren, erfahren Sie im nächsten Teil unserer Blogserie.
Viele Grüße!
Ihre SOPHISTen