Die richtige Architektur auswählen: Von Hand oder per Simulation

Mit steigender Komplexität von Systemen wird auch die Auswahl der richtigen Architektur immer wichtiger, aber auch schwerer. Daher stelle ich in diesem Artikel sieben Ansätze zur Architekturevaluierung vor. Traditionell ist das Handarbeit, aber MBSE ermöglicht auch Automatisierung. Anhand einer Case Study von Siemens zeige ich die automatische Evaluierung der Architektur über Simulation. In diesem Artikel:

• Definition Systemarchitektur: Einführung in den Begriff der Systemarchitektur: Aufbau, Komponenten, Interaktion und zugrunde liegende Prinzipien.
• Ein Problem, viele Architekturen: Für jede Anforderung sind verschiedene Architekturvarianten möglich, falsche Entscheidungen sind teuer.
• Ansätze zur Architekturauswahl: Vorstellung von sieben Herangehensweisen zur Entwicklung, Bewertung und Auswahl geeigneter Architekturvarianten.
• Systemarchitekturen leichtgewichtig beschreiben: Empfehlungen zur praktikablen Dokumentation, z. B. durch Nutzung von Arc42 oder ISO 42010
• Architekturen mit MBSE & SysML: Möglichkeiten der modellbasierten Entwicklung von Architekturen mithilfe standardisierter Notationen.
• Fallstudie: Simulation zur Auswahl der Architektur: Beispiel aus der Praxis, wie Siemens mithilfe von Simulation und SysML-Modellen die Effizienz der Evaluierung der Architektur gesteigert hat.

Was ist eigentlich eine Systemarchitektur?

Die Systemarchitektur bezeichnet die grundlegende Struktur und das Zusammenspiel der Komponenten eines Systems. Sie beschreibt, wie ein komplexes System aufgebaut ist, welche Teile (Komponenten) es enthält, wie diese miteinander interagieren und welche Prinzipien und Vorgaben ihrer Entwicklung und Integration zugrunde liegen.

Für jedes Problem gibt es viele Lösungen. Im klassischen Systems Engineering sollten, basierend auf den Anforderungen, unterschiedliche Architekturvarianten entwickelt und bewertet werden.

Ein einfaches Beispiel: Wir wollen ein Bild an die Wand hängen. Das ist möglich mit Nagel, Schraube, Klebepads, Galerieschienen und vielen anderen Architekturen. Wer ohne nachzudenken zum Nagel greift, wird ein Problem haben, wenn die Wand aus Rigips besteht und das Bild 10 kg wiegt.

Ein Problem, viele (mögliche) Architekturen

Hier eine( unvollständige) Liste von Ansätzen:

• Anforderungsgetriebene Architekturentwicklung: Bei dieser Vorgehensweise wird die Systemarchitektur direkt aus den funktionalen und nicht-funktionalen Anforderungen abgeleitet. Ziel ist es, eine Architektur zu entwickeln, die die Qualitätsziele wie Skalierbarkeit oder Kosten optimal unterstützt. Dabei werden verschiedene Architekturvarianten entworfen, verglichen und auf Basis der Anforderungen ausgewählt.
• Szenarienbasierte Bewertung (z. B. ATAM): Die Architecture Tradeoff Analysis Method (ATAM) bewertet Architekturentscheidungen mithilfe von konkreten Nutzungsszenarien und fokussiert sich auf Qualitätsattribute wie Performance, Wartbarkeit oder Verfügbarkeit. Dabei werden Stakeholder aktiv einbezogen, um Prioritäten zu setzen und Trade-offs zwischen konkurrierenden Anforderungen sichtbar zu machen.
• Architekturmuster-Ansatz: Warum das Rad neu erfinden? Bei diesem Ansatz werden bewährte Architekturmuster (Design Patterns) verwendet, die für bestimmte Problemstellungen oder Systemtypen besonders geeignet sind. Die Auswahl richtet sich nach Systemkontext, Anforderungen und Entwicklungsumgebung.
• Referenzarchitektur-Nutzung: Hierbei wird auf bestehende Referenzarchitekturen zurückgegriffen, die sich in bestimmten Domänen bewährt haben. Beispiele sind AUTOSAR im Automotive-Bereich oder TOGAF für Unternehmensarchitekturen. Dies ermöglicht Standardisierung, Wiederverwendung und eine bessere Kompatibilität mit bestehenden Systemen.
• Risiko-getriebene Architekturentwicklung: Diese Vorgehensweise stellt potenzielle Risiken (z. B. technische Unsicherheiten, Leistungsengpässe, regulatorische Anforderungen) in den Vordergrund. Die Architektur ermöglicht das frühzeitige Erkennen und Auflösen von Risiken. Dies ist insbesondere bei sicherheitskritischen oder komplexen Systemen wie in der Medizintechnik oder Luftfahrt von Bedeutung.
• Iterativ-inkrementelle Architekturentwicklung: In diesem Ansatz wird die Architektur nicht vollständig im Voraus geplant, sondern schrittweise aufgebaut und regelmäßig angepasst. Dies ist besonders in agilen Projekten vorteilhaft. Für Softwareprodukte ist dies inzwischen üblich, bei Hardware ist es schwieriger, aber möglich.
• Cost-Benefit-Analyse / Entscheidungsmodelle: Diese Vorgehensweise basiert auf einer systematischen Bewertung mehrerer Architekturvarianten mithilfe von Entscheidungsmodellen wie Nutzwertanalyse, Weighted Scoring oder dem Analytic Hierarchy Process (AHP). Ziel ist es, eine wirtschaftlich sinnvolle und technisch tragfähige Entscheidung zu treffen.

Systemarchitekturen leichtgewichtig beschreiben

Leider gibt es kein (mir bekanntes) Framework, um Systemarchitekturen leichtgewichtig zu beschreiben. Daher würde ich auch hier empfehlen, mit Arc42 zu beginnen und das Framework an das zu lösende Problem anzupassen. Dadurch bekommen wir zumindest eine einheitliche Struktur, die das vergleichen vereinfacht.

Wir Menschen arbeiten visuell. Daher sollte ein passendes Architekturdiagramm Teil der Dokumentation sein. Fortgeschrittene Teams können SysML benutzen. Für Teams, die noch nicht an formale Notation gewöhnt sind, könnte das C4-Modell eine gute Alternative sein. Da dies ebenfalls für Software konzipiert ist müsste es angepasst werden.

Das C4-Modell ist eine gute Alternative für das visuelle Erfassen einer Architektur

Sichten nach ISO 42010 helfen, nichts zu vergessen

Wer Complianceanforderungen nachweisen muss, kann zur Norm ISO/IEC/IEEE 42010 greifen. Diese legt Grundsätze und Anforderungen für die Architekturbeschreibung von Systemen fest. Ziel ist es, die Komplexität eines Systems beherrschbar zu machen, indem die Architektur aus verschiedenen Sichten (Views) beschrieben wird. Diese Sichten adressieren die Anliegen (Concerns) unterschiedlicher Stakeholder.

Die Norm schreibt keine festen Sichten vor, empfiehlt aber die Definition eigener Viewpoints. In der Praxis haben sich folgende Sichten etabliert:

• Logische Sicht: Zeigt die funktionale Struktur und Zerlegung des Systems in logische Komponenten und deren Beziehungen. Beispiel: Funktionsblöcke oder Softwaremodule.
• Technische Sicht (Deployment-/Plattformsicht): Zeigt die Abbildung von logischen Komponenten auf physikalische Einheiten (Hardware, Netzwerke, Plattformen). Beispiel: Ein IoT-Sensor, Edge-Node und Cloud.
• Entwicklungssicht: Zeigt die Organisation des Systems im Quellcode oder in Entwicklungsartefakten. Beispiel: Module, Packages, Versionsverwaltung.
• Laufzeitsicht: Zeigt das dynamische Verhalten zur Laufzeit – z. B. Kommunikation, Synchronisation, Ereignisflüsse.
• Informationssicht: Stellt dar, wie Daten strukturiert, gespeichert und verarbeitet werden. Beispiel: Datenmodelle, Kommunikationsprotokolle.
• Sicherheitssicht (ergänzend): Zeigt Sicherheitsmechanismen wie Authentifizierung, Zugriffskontrolle, Datenverschlüsselung.

Wer gründlich gelesen hat, dem fällt sicher die Ähnlichkeit zu Arc42 auf.

Architekturen mit MBSE & SysML

Architekturen können auch hervorragend modelliert werden. Insbesondere dokumentiert eigentlich jede MBSE-Methode auch die Architektur. Dazu gehören Arcadia, MagicGrid, Harmony, FAS oder SYSMOD.

Um erfolgreich mit SysML Architekturen zu definieren und auszuwählen hängt unter anderem von der Reife des Unternehmens ab. Insbesondere kann es schwer sein, alle Stakeholder erfolgreich in den Entscheidungsprozess einzubinden, wenn die Architekturen nicht zugänglich sind.

Fallstudie Architekturauswahl eines Thermalen Subsytems mit Simulation

Kürzlich hatte ich einen spannenden Austausch mit Mitarbeitern von Siemens Digital Industries Software. Insbesondere Mike Nicolai, Head of Simcenter MBSE, teilte mit mir eine Case Study die zeigte, wie das Team die Effizienz der Auswahl der Architektur mit Hilfe von Simulation beschleunigt hat.

Konkret ging es darum das Untersystem zum Heizen/Kühlen eines Fahrzeugs zu entwickeln. Das informell dargestellte „System of Interest“ ist im folgenden Bild zu sehen:

Basierend auf den Anforderungen erstellte das Team ein SysML Block Definition Diagram, welches die (möglichen) Teile des Systems aufführt. Dies ist allerdings noch keine (fertige) Architektur: Schließlich fehlt die Information, wie diese Teile ausgelegt sind, wie viele es gibt und wie diese zusammenspielen.

Permutationen generieren

Mit einem solchen Modell können wir nun Permutationen von Topologien und Konfigurationen erstellen. Genau das hat das SimCenter-Team gemacht.

Das Team hat automatisiert 1092 Simulationen durchgeführt, basierend auf 26 Topologien und 182 Konfigurationen.

Siemens Digital Industries Software

Evaluierung der Architektur per Simulation

Natürlich muss noch einiges an Information hinter jedem Block stecken, um auf dieser Ebene Simulationen durchführen zu können. Ob sich dieser nicht geringe Aufwand lohnt, hängt von vielen Faktoren ab. Das folgende Bild zeigt die Ergebnisse für insgesamt vier Simulationen:

Der hier gezeigte Aufwand würde sich wahrscheinlich nicht lohnen, wenn er nur für die Architekturauswahl betrieben werden würde. Für erfolgreiches MBSE könnte ein Modell mit diesem Level an Granularität auch anderen Anwendungsfälle unterstützen, zum Beispiel:

• Bestimmte Anforderungen automatisiert kontinuierlich testen, wie beim Unit Testen.
• Über Simulationen Stakeholder stärker einbinden
• Für bestimmte Aspekte des Systems einen digitalen Zwilling pflegen

ZF verkürzt Entwicklungszeiten von 12 auf 2 Monate

Rene Honcak stellte auf der ReConf 2025 ebenfalls eine spannende Case Study vor, in der er zeigte, wie MBSE und Digital Twins die virtuelle Verifikation und Validierung in der Automobilentwicklung beschleunigen können. Durch die Kopplung von Produktanforderungen mit Simulationsmodellen entsteht ein digitaler Zwilling, der das physische Produkt bereits im Entwicklungsprozess präzise abbildet. So wird eine fundierte Freigabe auf Basis virtueller Tests möglich – reproduzierbar, nachvollziehbar und schneller als klassische Testmethoden. Dazu werde ich bei Gelegenheit einen eigenen Beitrag erstellen.

Fazit

Die Auswahl der richtigen Systemarchitektur ist eine komplexe, aber wichtige Aufgabe im Systems Engineering, denn es ist unwahrscheinlich, dass wir beim ersten Versuch die richtige Architektur erwischen. Es gibt verschiedene Ansätze für die Auswahl einer Architektur, doch der Prozess ist in der Regel arbeitsintensiv. Zum Glück gibt es genug Hilfestellung, wie Arc42 oderISO 42010.

Spannend ist, wie Modellierung die Automatisierung ermöglicht. Dass dies in der Praxis funktionieren kann zeigt die Siemens-Fallstudie. Damit eröffnen sich neue Möglichkeiten, wie etwa automatisierte Validierung.