Interoperabilität entsteht nicht in der Integration, sondern in der Anforderungsarbeit, Jahre vorher – durch Menschen, die sich über Systemkontext, Randbedingungen und Schnittstellen verständigt haben. Wer diese drei Dinge früh klärt, bekommt Systeme, die sich nicht nur verbinden, sondern verstehen. Wer sie offen lässt, entdeckt die Lücken erst, wenn die Systeme zum ersten Mal miteinander reden sollen.
Im letzten Teil der Reihe zieht Stefan Wellhausen, Branchenaccount Manager für Defense und Aerospace bei der SOPHIST GmbH, die Quintessenz und beantwortet die Frage, die nach so einer Reihe immer kommt: Womit fangen wir an?
Video: Interoperabilität entsteht nicht in der Integration · SOPHIST GmbH
Das Wichtigste aus dem Video
- Der Systemkontext klärt mit zwei Grenzen, was zum eigenen System gehört: Die Systemgrenze umfasst, was ihr baut, die Kontextgrenze, was euer System beeinflusst. Dazwischen liegt alles, was ihr kennen müsst, aber nicht baut.
- Im Verbund gibt es immer eine graue Zone, in der noch nicht klar ist, wo etwas hingehört. Sie ist kein Fehler, sondern eine Liste offener Entscheidungen – und sie muss aufgeschrieben werden, damit jemand sie trifft.
- Randbedingungen kommen von außen und sind nicht verhandelbar, etwa Freigaberegeln, vereinbarte Austauschstandards, Normen, Bandbreite oder die Lebensdauer des Systems. Sie gehören als eigene Kategorie mit Quelle ganz an den Anfang.
- Jede Schnittstelle im Verbund braucht einen Verantwortlichen, eine gemeinsame Definition, die beide Seiten referenzieren, und einen Änderungsprozess, den beide Seiten akzeptieren.
- „Interoperabilität wird nicht in der Integration hergestellt, sondern in der Anforderungsarbeit.“
Häufige Fragen
Die Abgrenzung, was zum eigenen System gehört, was zur Umgebung und was noch unklar ist. Dafür zieht man zwei Grenzen: die Systemgrenze für das, was man baut, und die Kontextgrenze für das, was das System beeinflusst.
Anforderungen, über die nicht verhandelt werden kann, weil sie von außen kommen, zum Beispiel Freigaberegeln, vereinbarte Austauschstandards, Normen für Sicherheit und Zulassung, Bandbreite im Einsatz oder die geplante Lebensdauer.
Das muss ausdrücklich vereinbart werden. Jede Schnittstelle im Verbund braucht einen Verantwortlichen, eine gemeinsame Definition, die beide Seiten referenzieren, und einen Änderungsprozess, den beide akzeptieren.
Die Broschüre Systems Engineering kostenlos nutzen
Wie Requirements Engineering und Architektur bei komplexen Systemen zusammenspielen und wie ihr Systemkontext und Schnittstellen früh sauber klärt, steht in unserer kostenlosen Broschüre:
- Systems Engineering – mit RE und Architektur zum Erfolg: https://sophist.de/ylwu
- Alle kostenlosen Broschüren aus WISSEN-for-free: https://sophist.de/wissen/#WISSEN4free
Ihr steckt in einem Vorhaben mit mehreren Systemen, Partnern oder Nationen und wollt eure Anforderungen dafür fit machen? Sprecht uns an – wir unterstützen Organisationen seit 30 Jahren dabei, Anforderungen so zu formulieren, dass sie auf beiden Seiten einer Schnittstelle gleich verstanden werden.
Mit diesem Video endet unsere vierteilige Reihe zu Interoperabilität in Multi-Domain Operations. Auf dem SOPHIST YouTube-Kanal erklären wir regelmäßig Requirements Engineering und Systems Engineering aus der Praxis. Abonniere den Kanal, dann verpasst du kein Video.
Die ganze Reihe: Teil 1: Interoperabilität ist kein Technikproblem · Teil 2: Requirements Engineering ist kein Papierkram · Teil 3: MBSE ist kein Tool-Projekt
Grundlage: SOPHIST-Broschüre „Systems Engineering – mit RE und Architektur zum Erfolg“ aus SOPHIST WISSEN-for-free und das Buch „Requirements-Engineering und -Management“ (7. Auflage, Chris Rupp und die SOPHISTen, Hanser).