Im Bereich des Systems Engineering gibt es eine Vielzahl von Normen und Standards, die verschiedene Aspekte des Systementwurfs und -managements abdecken. Diese Normen dienen als Referenz und Leitfaden für Ingenieure, um effektive und zuverlässige Systeme zu entwickeln. Aus unserer Perspektive ist die ISO/IEC/IEEE 42010 die wichtigste: Sie ist von Ihrer Denkweise und Art die ungewöhnlichste und gleichzeitig der größten Hebelwirkung auf die Verbesserung der digitalisierten Zusammenarbeit. Die ISO/IEC/IEEE 42010 präsentiert Best Practices, um eine Systemarchitektur zu beschreiben – egal ob Mechatronik, Software oder von Unternehmen.
Inhalt
Die ISO/IEC/IEEE 42010
Ceci n’est pas une pipe – das bekannte Ölbild des Malers René Magritte zeigt ein (für das Erscheinungsjahr nahezu photorealistisches) Abbild einer Pfeife, untertitelt mit dem französischen Satz „Ceci n’est pas une pipe“, zu Deutsch: Dies ist keine Pfeife. Magritte beschreibt mit seinem Bild die Beziehung zwischen dem tatsächlichen Objekt, seiner Bezeichnung und seiner graphischen Repräsentation – Sie sehen keine Pfeife, sondern nur ihr Bild.
Genauigkeit der Begriffe
Warum dieser kleine Exkurs? Gerade beim Thema „Architektur“ ist Genauigkeit gefragt. Die ISO/IEC/IEEE 42010 Systems and Software Engineering – Architecture Description schafft ein einheitliches Verständnis für die Begriffe im Kontext einer Systemarchitektur. Das Bild der Pfeife deutet da auf ein häufiges Missverständnis hin: Wir sagen meist Architektur – meinen aber die Architekturbeschreibung eines Systems.
Konzept der ISO 42010
ISO 42010, mit dem Titel „Systems and software engineering – Architecture description“, konzentriert sich speziell auf die Beschreibung von Architekturen. Sie legt Prinzipien und Konzepte fest, um sicherzustellen, dass Architekturbeschreibungen klar, konsistent und verständlich sind. Die Norm bietet Anleitungen zur Strukturierung, Dokumentation und Kommunikation von Architekturen und ermöglicht es Ingenieuren, die Architektur eines Systems umfassend zu verstehen und zu analysieren.
Die ISO/IEC/IEEE 42010 liefert also ein Rahmenwerk für die Beschreibung, Organisation und Darstellung von Architekturbeschreibungen. Sie löste 2007 die IEEE 1471 Recommended Practice for Architectural Description of Software-Intensive Systems ab und adressiert seitdem jegliche Systeme – insbesondere natürlich technischer Art.
Die ISO 42010 wird unabhängig von technischen Konzepten, Modellierungssprachen oder Werkzeugen beschrieben. Diese Neutralität ermöglicht die Übertragung auf das eigene Unternehmen und schafft somit eine einheitliche Arbeitsgrundlage.
Unter einer Systemarchitektur versteht die Norm die fundamentalen Konzepte oder Eigenschaften eines Systems, also beispielsweise wie es in seine Umgebung eingebettet ist, was seine konstituierenden Elemente und ihre Interaktionen sind sowie die Prinzipien, nach denen es entwickelt und organisiert wird. Eine Architektur ist etwas Abstraktes, ihre Beschreibung dagegen ein konkretes Arbeitsprodukt in der Produktentwicklung.
Das Modell der Architekturbeschreibung
Kern der ISO ist eine Ontologie. Elementar ist hier das Zusammenspiel zwischen einem Stakeholder, dem betrachteten System (‚System-of-Interest’) und der Architekturbeschreibung: Einer oder viele Stakeholder der Architekturbeschreibung haben unterschiedliche Interessen an einem System. Die daraus abgeleiteten Concerns finden dann Berücksichtigung in der der Architekturbeschreibung. Der Begriff Concern ist etwas ungelenk definiert als ‚any topic of interest’ – beispielsweise die Funktionalität, die Struktur, das Verhalten des Systems (weitere Concerns in der Infobox).
Zur Befriedigung eines Concerns wendet die ISO 42010 das Konzept der ‚Separation of Concerns’ an – jeder Concern wird durch eine einzelne View (Sicht) dargestellt, also einen konkreten Ausschnitt der Architekturbeschreibung in einer hierfür geeigneten Darstellungsweise. Das kann etwa für den Systemingenieur eine Wirkkette sein, für den Elektrotechniker das Blockschaltbild und für den Projektmanager durchaus eine N2-Matrix.
Die in den verschiedenen Views zum Ausdruck gebrachten Inhalte können sich durchaus überschneiden – da sie jeweils ausdrücken, was für den konkreten Stakeholder ‚von Interesse’ ist. Wie die View dargestellt und erarbeitet wird, wird durch den Viewpoint (Standpunkt) bestimmt. Dieser definiert die Konventionen zur Erstellung, Interpretation und Analyse der Views. Das sind etwa Sprachen, Notationen, Modellart, Modellierungsmethoden oder Analysetechniken. Ein Architecture Viewpoint ist somit im Prinzip eine Beschreibung der Methode zur Erstellung einer konkreten View.
Verwendung von Architekturbeschreibungen
Eine konsistente Architekturbeschreibung, über die verschiedenen Views hinweg, ist oberstes Ziel in der Produktentwicklung. Modellbasiertes Systems Engineering (MBSE) bietet hierfür in vielen Fällen die notwendige Herangehensweise. Die Architekturbeschreibung als solches ist kein Selbstzweck und stiftet für sämtliche Stakeholder und zu unterschiedlichen Zeitpunkten im Systemlebenszyklus erheblichen Nutzen. Die ISO nennt hierfür zahlreiche Beispiele. Diese zeigen auch, warum die Architekturbeschreibung ein solch kritischer Punkt in einem Projekt ist. Die Architekturbeschreibung…
- bildet die Basis für die Systementwicklung und sämtliche Entwicklungsaktivitäten
- dient als Grundlage zur Evaluation unterschiedlicher Realisierungsmöglichkeiten eines Systems
- ist eine hervorragende Dokumentation für die Entwicklung, aber auch für den Service
- wird genutzt, um Input für Simulationswerkzeuge abzuleiten oder Analysen während der Produktentwicklung durchzuführen
- ist Kommunikationsmedium zwischen unterschiedlichsten Partnern im Projekt und auch zum Kunden
- ist die Grundlage für ein erfolgreiches Projektmanagement – also beispielsweise die Zeit- und Budgetplanung.
Das Konzept der ISO 42010 erscheint zunächst sehr abstrakt. Wenn man sich allerdings ein wenig mit ihrer Darstellungsform und Intention beschäftigt, erkennt man, dass die ISO wirklich ein hervorragendes Gerüst ist, um die Zusammenarbeit vieler Stakeholder, ihrer Aufgaben und Darstellungsweisen zu organisieren und verständlich zu machen. Im Kern müssen Entwicklungsorganisationen erkennen, dass eine Architekturbeschreibung zentraler Ausgangspunkt der Zusammenarbeit ist und dass es viele gültige Darstellungsformen gibt – nur müssen sie organisiert und klar strukturiert sein. Den richtigen Zugang bietet die ISO 42010.
Weitere Normen im Systems Engineering
Eine weitere Norm im Systems Engineering, die ISO 15288, beschäftigt sich mit dem System-Lebenszyklus-Prozess. Unsere Software iQUAVIS berücksichtigt beide Normen.
Erfahren Sie hier mehr über iQUAVIS.
Systems Engineering ist eine Lebensart – wer sie einmal kennt, kommt nicht von ihr los! Ich brenne dafür, das Engineering zu verändern. Weg von verwirrenden Lasten- und Pflichtenheften hin zu einer modellbasierten Spezifikation. Das hilft mir, viele Aufgaben eines Projekts besser zu bewältigen, mit Kollegen ein gemeinsames eindeutiges Systemverständnis zu bilden und immer die relevanten Aufgaben im Blick zu haben. Und außerdem: Ich bin überzeugt, dass innovative Geschäftsmodelle nur mit einem solchen Ansatz möglich werden: Smarte Services, Things that think, … Let’s go together!
