Model-Based Systems Engineering and Application Lifecycle Management are meant to complement each other. In theory, integrating MBSE and ALM should create a seamless flow from system architecture through requirements, change management, and verification. In practice, organisations face MBSE-ALM integration challenges that make this connection one of the most fragile parts of their engineering toolchain.

Diese Herausforderungen entstehen selten durch fehlende technische Verbindungen zwischen Werkzeugen. Sie resultieren vielmehr aus tieferliegenden strukturellen und organisatorischen Inkonsistenzen, die durch klassische Integrationsansätze nicht adressiert werden.

Die Illusion einer „einfachen“ MBSE-ALM-Integration

Viele MBSE-ALM-Integrationen basieren auf einer zunächst plausiblen Annahme: Wenn Architekturelemente im MBSE mit Anforderungen und Tests im ALM verknüpft sind, ist die Rückverfolgbarkeit gewährleistet. In realen Projekten erweist sich diese Annahme jedoch schnell als unzureichend.

Reine Verknüpfungen beantworten keine kritischen Fragen wie:

1. Welche Links sind für eine bestimmte Variante oder ein bestimmtes Release gültig?
2. Welche Architekturänderungen wirken sich tatsächlich auf zertifizierte Anforderungen aus?
3. Welche Trace-Beziehungen sind nach einem Modell-Refactoring noch vertrauenswürdig?

Mit zunehmender Systemkomplexität wird deutlich, dass Integration nicht primär eine Frage der Konnektivität ist, sondern von Kontext, Governance und Skalierbarkeit.

Konfigurations- und Variantenkomplexität

Eine der am häufigsten unterschätzten Herausforderungen bei der MBSE-ALM-Integration ist der Konfigurationskontext.

In MBSE-Umgebungen ist Architektur selten statisch. Varianten, Optionen, Baselines und Releases existieren parallel. Dieselbe Anforderung kann je nach Konfiguration durch unterschiedliche Architekturelemente realisiert werden.

Viele ALM-Werkzeuge behandeln Traceability jedoch weiterhin als global:

1) Ein Link existiert – oder eben nicht
2) Konfiguration wird nachgelagert als Filter angewendet
3) Die Gültigkeit von Links wird angenommen, nicht überprüft

Dies führt zu Situationen, in denen Rückverfolgbarkeit vollständig erscheint, für die aktive Konfiguration jedoch faktisch falsch ist.Die Folge sind fehlerhafte Impact-Analysen und eine Gefährdung von Compliance-Nachweisen.

Strukturelle Diskrepanz zwischen MBSE- und ALM-Datenmodellen

MBSE tools manage graphs:

1) hierarchische Strukturen
2) Kompositionen
3) Ports und Schnittstellen
4) Konnektoren und Flüsse

ALM tools manage lists:

1) flache Anforderungen
2) Testfälle
3) Change Requests

Dieser grundlegende Unterschied zeigt sich deutlich in der Art und Weise, wie beide Systeme Engineering-Daten strukturieren und interpretieren.

Die Überbrückung dieser Repräsentationen ist nicht trivial. Das „Flattening“ von Architektur in einzelne Artefakte zerstört architektonische Bedeutung. Der Erhalt der Struktur wiederum kann ALM-Anwender schnell überfordern, wenn keine gezielte Abstraktion erfolgt.

Dieser Datenmodell-Mismatch ist einer der Hauptgründe, warum viele MBSE-ALM-Integrationen im täglichen Engineering-Betrieb als fragil oder kaum nutzbar empfunden werden.

OSLC-Limitationen in Enterprise-Umgebungen

OSLC wird häufig als Standardlösung für die MBSE-ALM-Integration positioniert. Obwohl es Interoperabilität ermöglicht, bringt es in großen Umgebungen eigene Herausforderungen mit sich:

1) Abhängigkeiten durch Consumer-Registrierung und OAuth-Trust
2) Fehleranfällige Delegated-UIs ohne klare Fehlermeldungen
3) Administrativer Overhead, der bis in Engineering-Workflows hineinwirkt

In der Praxis verbringen Teams oft mehr Zeit mit der Wartung der Integrationsinfrastruktur als mit ihrer eigentlichen Nutzung – Ingenieure werden zu Tool-Administratoren.

Traceability ohne Governance

Links zu erstellen ist einfach. Über die Zeit hinweg vertrauenswürdige Rückverfolgbarkeit zu erhalten, ist es nicht.

Ohne Governance:

1) veralten Links nach Refactorings
2) verlieren sie ihre Konfigurationsrelevanz
3) fehlt der Audit-Kontext (wer, wann, warum)

Das Ergebnis sind umfangreiche Traceability-Datenbestände, die für Impact-Analysen oder Audits nicht belastbar sind.

Toolübergreifende Impact-Analyse bleibt manuell

Bei einer losen Kopplung von MBSE und ALM wird Impact-Analyse zum manuellen Prozess:

1) Navigation der Architektur im MBSE-Tool
2) Wechsel zu Anforderungen im ALM
3) Mentale Rekonstruktion der Zusammenhänge

Dieser Ansatz ist langsam, fehleranfällig und nicht skalierbar. Der eigentliche Mehrwert der MBSE-ALM-Integration liegt nicht in der Navigation, sondern in automatisiertem, fachübergreifendem Impact-Verständnis.

Warum diese Herausforderungen bestehen bleiben

Der gemeinsame Nenner dieser Probleme ist, dass MBSE-ALM-Integration häufig verstanden wird als:

1) technischer Konnektor
2) Sammlung von Links
3) Reporting-Mechanismus

Eine wirksame Integration erfordert jedoch:

1) konfigurationsbewusste Traceability
2) einen gesteuerten Lebenszyklus von Verknüpfungen
3) den Erhalt architektonischer Semantik
4) skalierbare Performance für große Modelle

Ohne diese Grundlagen erreichen Integrationsinitiativen schnell ein Plateau.

Vom Integrationsprojekt zur Engineering-Fähigkeit

Organisations that succeed with MBSE-ALM integration stop asking “How do we connect the tools?” and start asking:

1. Wie stellen wir sicher, dass Traceability pro Konfiguration gültig bleibt?
2. Wie erkennen wir beschädigte oder veraltete Beziehungen?
3. Wie führen wir Impact-Analysen über Architektur, Anforderungen und Verifikation hinweg durch?
4. Wie erzeugen wir auditfähige Nachweise ohne manuellen Aufwand?

Die Beantwortung dieser Fragen erfordert einen dedizierten Ansatz für Traceability und Integration – nicht nur Tool-Level-Konnektoren.

---