Warum Schnittstellenspezifikationen zugänglich sein müssen

Gemeinsam mit SodiusWillert habe ich mich in den vergangenen Monaten intensiv mit pragmatischem Interfacemanagement beschäftigt. Unser Ziel war es, einen niederschwelligen Zugang schaffen, damit wirklich alle im Projekt Interfaces versteht und nutzen können.

Ergebnis unserer Zusammenarbeit sind ein Whitepaper, ein begleitendes Video. Außerdem veranstalten wir ein gemeinsames Webinar am 25. September zu dem Thema.

Was ist überhaupt eine Schnittstelle?

Laut ISO/IEC/IEEE 24748-6 ist eine Schnittstelle „der Punkt, an dem zwei oder mehr logische oder physische Systemelemente miteinander in Wechselwirkung treten“. Kurz: Hier werden Daten, Energie oder Signale übergeben, hier entscheidet sich, ob Teile später nahtlos zusammenspielen oder teuer nachgebessert werden müssen.

Durch die Softwarelastigkeit von Systemen hat sich die Relevanz von Schnittstellen erheblich verschärft. Insbesondere erfordern Softwareschnittstellen ein anderes Management als Mechanik- oder Elektronikschnittstellen.

Schnittstellenspezifikationen sind ein entscheidendes Instrument, um zu gewährleisten, dass komplexe Systeme präzise definiert, angemessen ausgeführt und während ihres gesamten Lebenszyklus effektiv gewartet werden.

Ricarda Schüssler, 2023 in “Approaching Smart InterfaceSpecifications in the Systems of Systems Context”

Ohne eine saubere Schnittstellenbeschreibung gibt es Probleme, die oft in der Integrationsphase auftauchen. Und da die Integration in der Regel spät stattfindet, sind die resultierenden Probleme besonders teuer und können zu großen Verzögerungen führen.

Bis zu 70 % der Probleme bei der Produktentwicklung erscheinen während der Integration!

Iryna Deremuk, LITSLINK Startup Laboratory

Schnittstellenbeschreibungen: Von Dokument bis Modell

Traditionell werden Interfaces in Interface-Control-Documents (ICDs) festgehalten. Dies funktioniert gut beim dokumentenbasierten Arbeiten. Doch die Pflege der ICDs (und anderer Dokumente) ist extrem aufwändig.

Richtig eingesetzt funktionieren ICDs allerdings auch für agiles Arbeiten. Das hat Joe Justice in seinem ReConf-Vortrag erklärt. Interessant war hier, dass die ICDs für die Aufteilung der Arbeit benutzt wurden: Joe hatte das gesamte Fahrzeug mit lediglich sieben ICDs zerlegt, jedes ICD war lediglich eine Seite lang.

Die Beschreibung von Softwareschnittstellen funktioniert inzwischen sehr gut. Über BDD werden Spezifikation, Testcode und Quellcode eng gekoppelt und automatisiert getestet. Auch die Versionierung von APIs und Softwarekomponenten ist ein gelöstes Problem.

Schnittstellen in SysML

Beim MBSE ist eine formale Schnittstellenspezifikation ein integraler Bestandteil des Modells. Dadurch haben wir wesentlich mehr Präzision, außerdem sind die Modelle maschinenlesbar.

Wenn wir mit SysML v1 modellieren, setzen wir (Proxy) Ports und Interface Blocks ein. Über Flow Properties können Flüsse von Daten, Kräften oder Medien sauber abgebildet werden. Über Modelchecking können zumindest einige Aspekte der Integrations-Kompatibilität automatisiert geprüft werden.

Ein SysML-Modell ist ein mächtiges Werkzeug: Es erlaubt Konsistenzprüfungen, Variantenmanagement, automatische Testfall­generierung, Traceability zu Anforderungen und vieles mehr. Doch in vielen Unternehmen erzeugt es auch Hürden:

1. Zugänglichkeit: Modellierungswerkzeuge sind in der Regel nicht allen Nutzern zugänglich: Sei es, weil die Lizenzen fehlen oder die Erfahrung im Umgang mit den Werkzeugen. Außerhalb der eigenen Firma ist ein direkter Zugriff auf Werkzeuge in den meisten Fällen nicht praktikabel.
2. Akzeptanz: Manche Stakeholder haben kein Interesse, sich mit mit den Werkzeugen auseinanderzusetzen. Und es macht auch nicht unbedingt Sinn, bspw. dem Einkauf, oder Management ein Rhapsody oder Cameo aufs Auge zu drücken.

Silos mit neuen Read-only-Views aufbrechen

Die Idee, Stakeholdern maßgeschneiderte Read-Only-Views ist nicht neu, aber trotzdem sehr effektiv. Zusammen mit SodiusWillert haben wir uns die Möglichkeiten von IBM Engineering Rhapsody genauer angeschaut. Das Folgende haben wir in einem Whitepaper und einem 9-Minuten-Video festgehalten.

Rhapsody hat, wie die meisten Modellierungswerkzeuge, einen Dokumentengenerator. Die Erweiterung Power Pack von SodiusWillert ermöglicht dabei die schnelle Generierung von ICDs durch vorkonfigurierte Vorlagen. Das an sich ist schon sinnvoll. Dabei ist es auch möglich, die Generierung zu automatisieren (z.B. über Jenkins), damit nicht versehentlich auf einem veralteten Stand des ICD gearbeitet wird.

Spannend ist auch die Möglichkeit, mit Power Pack eine interaktive ICD in HTML zu generieren. An der Realisierung hat übrigens Rhapsody-Experte Andy Lapping maßgeblich mitgewirkt, der auch auf dem SodiusWillert-Youtube-Channel viele Videos zu Power Pack veröffentlicht hat.

Das generierte HTML benötigt kein IBM Rhapsody und kann daher über das Intranet Kollegen oder als ZIP-Datei Partnerunternehmen bereitgestellt werden. Da kein Server benötigt wird, kann ich das Ergebnis auch direkt hier auf der Webseite einbetten:

Natürlich ist das ganze eher low-tech, im Vergleich mit der Modellierung im Werkzeug. Doch gerade diese einfachen Ansätze sind wichtig, da sie Silos aufbrechen, die Modelle (und Schnittstellenbeschreibungen) zugänglich machen und vielleicht sogar Neugier an der Modellierung wecken.

Fazit

Schnittstellen zu modellieren, statt mit Dokumenten zu beschreiben, hilft, die Komplexität im Systems Engineering zu beherrschen. Wenn wir schon nicht das ganze Modell allen Stakeholdern zumuten wollen, so sind die Schnittstellenbeschreibungen eine der ersten Elemente die für andere einen hohen Nutzen haben. Daher sollten wir diese als erstes bereitstellen, und zwar in einer Weise, die eine hohe Akzeptanz hat. Und das sind nun einmal Dokumente.

Das Whitepaper und Video zeigen dies mit IBM Rhapsody, was durch das Power Pack von SodiusWillert noch einmal ein gutes Stück einfacher wird. Doch die Konzepte lassen sich auch auf andere Werkzeuge übertragen.

Wer mehr wissen, und insbesondere Fragen stellen möchte, lade ich zum Webinar am 25.09.2025 ein, das ich zusammen mit SodiusWillert durchführen werde.