Selecting the right architecture: By hand or by simulation

As systems become more complex, choosing the right architecture is becoming increasingly important, but also more difficult. In this article, I therefore present seven approaches to architecture evaluation. Traditionally, this is manual work, but MBSE also enables automation. Using a case study from Siemens, I show the automatic evaluation of the architecture via simulation. In this article:

• Definition of system architectureIntroduction to the concept of system architecture: structure, components, interaction and underlying principles.
• One problem, many architecturesDifferent architecture variants are possible for every requirement, wrong decisions are expensive.
• Approaches to architecture selectionPresentation of seven approaches for the development, evaluation and selection of suitable architecture variants.
• Describe system architectures in a lightweight wayRecommendations for practicable documentation, e.g. through the use of Arc42 or ISO 42010
• Architectures with MBSE & SysML: Possibilities of model-based development of architectures using standardized notations.
• Case study: Simulation for selecting the architecture: Practical example of how Siemens has increased the efficiency of architecture evaluation with the help of simulation and SysML models.

What is a system architecture?

The system architecture describes the basic structure and interaction of the components of a system. It describes how a complex system is structured, which parts (components) it contains, how they interact with each other and which principles and specifications underlie their development and integration.

There are many solutions for every problem. In classic systems engineering, different architecture variants should be developed and evaluated based on the requirements.

A simple example: We want to hang a picture on the wall. This is possible with nails, screws, adhesive pads, gallery rails and many other types of architecture. If you reach for a nail without thinking, you will have a problem if the wall is made of plasterboard and the picture weighs 10 kg.

One problem, many (possible) architectures

Here is an (incomplete) list of approaches:

• Requirements-driven architecture developmentIn this approach, the system architecture is derived directly from the functional and non-functional requirements. The aim is to develop an architecture that optimally supports quality objectives such as scalability or costs. Different architecture variants are designed, compared and selected on the basis of the requirements.
• Scenario-based assessment (e.g. ATAM)The Architecture Tradeoff Analysis Method (ATAM) evaluates architectural decisions with the help of specific usage scenarios and focuses on quality attributes such as performance, maintainability and availability. Stakeholders are actively involved in order to set priorities and make trade-offs between competing requirements visible.
• Architectural pattern approachWhy reinvent the wheel? With this approach, tried and tested Architectural patterns (Design Patterns) which are particularly suitable for certain problems or system types. The selection depends on the system context, requirements and development environment.
• Reference architecture usageThis is based on existing reference architectures that have proven themselves in certain domains. Examples are AUTOSAR in the automotive sector or TOGAF for enterprise architectures. This enables standardization, reuse and better compatibility with existing systems.
• Risk-driven architecture developmentThis approach focuses on potential risks (e.g. technical uncertainties, performance bottlenecks, regulatory requirements). The architecture enables risks to be identified and resolved at an early stage. This is particularly important for safety-critical or complex systems such as in medical technology or aviation.
• Iterative-incremental architecture developmentIn this approach, the architecture is not planned completely in advance, but built up step by step and adapted regularly. This is particularly advantageous in agile projects. This is now common practice for software products. Hardware is more difficult, but possible.
• Cost-benefit analysis / decision modelsThis approach is based on a systematic evaluation of several architecture variants using decision models such as utility value analysis, weighted scoring or the Analytic Hierarchy Process (AHP). The aim is to make an economically sensible and technically viable decision.

Describe system architectures in a lightweight way

Unfortunately, there is no framework (that I know of) for describing system architectures in a lightweight way. I would therefore recommend starting with Arc42 and adapting the framework to the problem to be solved. This at least gives us a standardized structure that simplifies the comparison.

We humans work visually. Therefore, a suitable architecture diagram should be part of the documentation. Advanced teams can use SysML. For teams that are not yet used to formal notation, the C4 model could be a good alternative. As this is also designed for software, it would have to be adapted.

The C4 model is a good alternative for visually capturing an architecture

ISO 42010 views help to ensure nothing is forgotten

Those who have to prove compliance requirements can become the norm ISO/IEC/IEEE 42010 apply. This defines principles and requirements for the architectural description of systems. The aim is to make the complexity of a system manageable by describing the architecture from different views. These views address the concerns of different stakeholders.

The standard does not prescribe any fixed views, but recommends defining your own viewpoints. The following views have become established in practice:

• Logical viewShows the functional structure and decomposition of the system into logical components and their relationships. Example: Function blocks or software modules.
• Technical view (deployment/platform view): Shows the mapping of logical components to physical units (hardware, networks, platforms). Example: An IoT sensor, edge node and cloud.
• Development viewShows the organization of the system in the source code or in development artifacts. Example: Modules, packages, version management.
• Runtime viewShows the dynamic behaviour at runtime - e.g. communication, synchronization, event flows.
• Information view: Represents how data is structured, stored and processed. Example: data models, communication protocols.
• Security view (supplementary)Shows security mechanisms such as authentication, access control, data encryption.

Anyone who has read carefully will certainly notice the similarity to Arc42.

Architectures with MBSE & SysML

Architectures can also be modeled excellently. In particular, every MBSE method also documents the architecture. This includes Arcadia, MagicGridHarmony, FAS or SYSMOD.

To successfully define and select architectures with SysML depends, among other things, on the maturity of the organization. In particular, it can be difficult to successfully involve all stakeholders in the decision-making process if the architectures are not accessible.

Case study architecture selection of a thermal subsystem with simulation

I recently had an exciting exchange with employees from Siemens Digital Industries Software. In particular Mike Nicolai, Head of Simcenter MBSE, shared a case study with me that showed how the team accelerated the efficiency of architecture selection using simulation.

Specifically, the aim was to develop the subsystem for heating/cooling a vehicle. The informally presented "system of interest" can be seen in the following image:

Based on the requirements, the team created a SysML Block Definition Diagram, which lists the (possible) parts of the system. However, this is not yet a (finished) architecture: after all, there is no information on how these parts are designed, how many there are and how they interact.

Generate permutations

With such a model, we can now create permutations of topologies and configurations. This is exactly what the SimCenter team has done.

The team carried out 1092 automated simulations based on 26 topologies and 182 configurations.

Siemens Digital Industries Software

Evaluation of the architecture via simulation

Of course, there has to be a lot more information behind each block in order to be able to carry out simulations at this level. Whether this considerable effort is worthwhile depends on many factors. The following image shows the results for a total of four simulations:

The effort shown here would probably not be worthwhile if it were only used for architecture selection. For successful MBSE, a model with this level of granularity could also support other use cases, for example:

• Continuous automated testing of certain requirements, as with the Unit testing.
• Using simulations to involve stakeholders more closely
• For certain aspects of the system a digital twin Maintain

ZF shortens development times from 12 to 2 months

Rene Honcak also presented an exciting case study at ReConf 2025in which he showed how MBSE and digital twins can accelerate virtual verification and validation in automotive development. By linking product requirements with simulation models, a digital twin is created that precisely maps the physical product during the development process. This enables a well-founded release based on virtual tests - reproducible, traceable and faster than classic test methods. I will write a separate article about this when the opportunity arises.

Conclusion

Selecting the right system architecture is a complex but important task in systems engineering because it is unlikely that we will get the right architecture on the first try. There are different approaches to selecting an architecture, but the process is usually labor intensive. Fortunately, there is plenty of help available, such as Arc42 orISO 42010.

It is exciting to see how modeling enables automation. The Siemens case study shows that this can work in practice. This opens up new possibilities, such as automated validation.