5 Ansätze, um Komplexität in den Griff zu bekommen

Wer heute Produkte entwickelt, muss die Komplexität moderner Systeme beherrschen. Insbesondere durch den immer größer werdenden Anteil von Software ist dies nicht leicht.

Das hat konkrete Auswirkungen: Insbesondere ergeben sich durch die erhöhte Komplexität immer öfter Probleme Verzögerungen und Qualitätsprobleme. Das kostet Geld und Marktanteile, und sorgt für Unzufriedenheit.

Im folgenden werden fünf Ansätze vorgestellt, alt und neu, mit denen Komplexität unter Kontrolle gebracht werden kann.

Ich sage bewusst „Ansatz“, wobei es sich konkret um Architektur- und Designansätze handelt. Denn Architektur hat maßgeblich einen großen Einfluss auf die Komplexität.

In der Softwareentwicklung werden Layer schon lange benutzt, um verschiedene Ebenen miteinander zu verbinden. Zum Beispiel Stellt ein Grafiktreiber einen Layer dar, der das Betriebssystem mit der Grafikhardware verknüpft.

Eine Schicht kann beliebig einfach oder komplex sein. Zum Beispiel ist ein einfacher Schaltschrank ein Layer, über den einfach nur die Ein- und Ausgänge richtig miteinander verdrahtet werden.

Eine komplexe Schicht wurde bei der Boing 737-MAX eingeführt: Das Maneuvering Characteristics Augmentation System (MCAS) ist eine Schicht, die dem Piloten unter anderem vorgaukelt, unveränderte Flugeigenschaften gegenüber den Vorgängermodellen zu haben.

Bauteile werden seit Jahrzehnten erfolgreich eingesetzt. Dabei ist der Begriff recht weit gegriffen: Ein Bauteil kann ein Zahnrad sein, aber auch ein kompletter Monitor. Mehrere Bauteile werden oft zu einer Baugruppe zusammengefasst.

Der Begriff „Bauteil“ ist recht informell, hat aber insbesondere in der Mechanik gute Dienste geleistet. Die Elektronik hat das Konzept dann verkompliziert, und spätestens seit der weiten Verbreitung von Software funktioniert es nur noch sehr begrenzt. Das liegt unter anderem daran, dass Mechanik, Elektronik und Software zusammen zwar die Funktion realisieren, jedoch nicht in einem Bauteil zusammengefasst sind.

Über modellbasierte Entwicklung schreibe ich viel, denn diese hat sich bewährt, um mit dem Hardware-Software-Verbund umzugehen. Hier geht es primär um die Modellierung auf Systemebene (MBSE), es wird aber auch viel im Design modelliert. Dies ist durch eine wesentlich stärkere Formalisierung der Systembeschreibung möglich. Leider hat Modellierung einen ziemlich großen Overhead, so dass sich MBSE noch nicht in der Breite durchgesetzt hat.

Ein großes Problem in der Modellierung ist die Heterogenität der Systeme. Zum Beispiel kann es im selben System synchrone und asynchrone Kommunikation geben. Auch gibt es verschiedene Domänen, in denen Modelliert wird: Mechanik, Elektrik, Strömung, Signale, etc.

Die Gefahr bei so viel Heterogenität ist Emergenz. Egal, wie sorgfältig wir modellieren: Wir können nicht garantieren, dass es nicht unerwartete Nebeneffekte gibt. Traditionell kann dies mit Prototypen entschärft werden. Doch damit bekommen wir erst relativ spät in der Entwicklung eine Rückmeldung. Besser wäre es, über eine virtuelle Integration frühzeitig ein Verständnis des Gesamtsystems zu bekommen.

Dies ist übrigens der Ansatz, den Daimler unter dem Begriff „Frontloading“ verfolgt.

Eine Plattform stellt die Grundlage einer Entwicklung dar, bei der vieles schon funktioniert, und viele architektonische Entscheidungen bereits gefällt wurden. In der Software sind Plattformen längst weit verbreitet. Bei Produkten investieren Firmen in Plattformen, wenn das Produktportfolio dies hergibt. Es gibt auch offene Plattformen.

Eine Plattform erfordert zunächst eine erhebliche Investition. Denn wir wissen beim Entwickeln der Plattform oft nicht, welche Komponenten an diese in der Zukunft einmal angedockt werden.

Schnittstellen sind der Dreh- und Angelpunkt

Wenn wir uns diese Ansätze anschauen, dann haben alle gemeinsam, dass die Schnittstellen für das funktionieren wichtig sind. Allerdings müssen sie mal mehr, mal weniger sorgfältig definiert werden. Bei Layern geht es nur darum, Schnittstellen miteinander zu verknüpfen. Bei einer Plattform hingegen müssen sie so sorgfältig definiert sein, dass beliebige Komponenten an die Plattform gedockt werden können, ohne dass es Probleme gibt (solange sich die Komponenten an die Schnittstellenbeschreibung halten).

Doch eines ist sicher: Je sorgfältiger wir eine Schnittstelle definieren, desto weniger Probleme werden wir später haben. Da Schnittstellen eine so wichtige Rolle spielen, wird es dazu demnächst noch mehr Artikel geben.

Image by Pete Linforth from Pixabay