|

5 approaches to getting to grips with complexity

Complexity

Anyone developing products today has to master the complexity of modern systems. This is not easy, especially due to the ever-increasing proportion of software.

This has concrete consequences: In particular, the increased complexity is increasingly causing delays and quality problems. This costs money and market share and leads to dissatisfaction.

In the following, I present five approaches, old and new, with which we can bring complexity under control.

I deliberately say "approach", specifically referring to architectural and design approaches. Because architecture has a major influence on complexity.

1.Layers (Layered Design)

In software development, layers have long been used to connect different levels with each other. For example, a graphics driver is a layer that links the operating system with the graphics hardware.

A layer can be as simple or complex as you like. A simple control cabinet, for example, is a layer that simply wires the inputs and outputs together correctly.

A simple layer (source: Pexels)

A complex layer was created in the Boeing 737-MAX introduced: The Maneuvering Characteristics Augmentation System (MCAS) is a layer which, among other things, deceives the pilot into believing that the flight characteristics are unchanged compared to the previous models.

2.Components (Componend-Based Design)

components have been used successfully for decades. The term is quite broad: A component can be a gear wheel, but also a complete monitor. Several components are often combined to form an assembly.

The term "component" is quite informal, but has served well, especially in mechanics. Electronics then complicated the concept, and since the widespread use of software at the latest, it has only worked to a very limited extent. One of the reasons for this is that although mechanics, electronics and software together realize the function, they are not combined in one component.

3.Model-based development

About Model-based development I write a lot in this area, because it has proven itself in dealing with the hardware-software network. This is primarily about modeling at system level (MBSE), but there is also a lot of modeling in the design. This is made possible by a much stronger formalization of the system description. Unfortunately, modeling has a rather large overhead, so that MBSE has not yet become widely accepted.

4.Virtual integration

A major problem in modeling is the heterogeneity of the systems. For example, there can be synchronous and asynchronous communication in the same system. There are also different domains in which modeling takes place: Mechanics, electrics, flow, signals, etc.

The danger with so much heterogeneity is emergence. No matter how carefully we model: We cannot guarantee that there will not be unexpected side effects. Traditionally, prototypes can mitigate this problem. But this only gives us feedback relatively late in the development process. It would be better to use virtual integration to gain an understanding of the overall system at an early stage.

Incidentally, this is the approach that Daimler under the term "frontloading" tracked.

5.Platform-based design

A platform is the basis of a development that already provides many functions and specifies many architectural decisions. Platforms have long been widely used in software. In the case of products, companies invest in platforms if the product portfolio allows for this. There are also open platforms.

A platform initially requires a considerable investment. When developing the platform, we often do not know which components we want to dock in the future

Interfaces are the linchpin

If we look at these approaches to mastering complexity, what they all have in common is that the Interfaces are important for functioning. However, they sometimes have to be defined more, sometimes less carefully. Layers are only about linking interfaces with each other. With a platform, on the other hand, they must be so carefully defined that any components can be docked to the platform without causing problems (as long as the components adhere to the interface description).

But one thing is certain: the more carefully we define an interface, the fewer problems we will have later on. As interfaces play such an important role, there will be more articles on this subject in the near future.

Image by Pete Linforth from Pixabay

Similar Posts

Leave a Reply