Ein system of systems ist kein einzelnes Großsystem, sondern ein Verbund aus autonomen Systemen, die gemeinsam eine übergeordnete Fähigkeit liefern. Genau darin liegt die eigentliche Herausforderung in der Informatik: Jede Komponente hat ihren eigenen Lebenszyklus, ihre eigenen Teams und oft sogar ihre eigene Eigentümerschaft. In diesem Artikel ordne ich das Konzept technisch ein, zeige die wichtigsten Typen und erkläre, worauf Architektur, Datenflüsse, Governance und Betrieb in der Praxis achten müssen.
Die wichtigsten Punkte auf einen Blick
- Ein Systemverbund lohnt sich dort, wo unabhängige Systeme zusammenarbeiten müssen, ohne ihre Eigenständigkeit zu verlieren.
- Die vier Grundformen helfen dabei, Steuerbarkeit und Realismus korrekt einzuschätzen.
- Entscheidend sind nicht nur Schnittstellen, sondern auch Datenbedeutung, Identitäten, Versionierung und Betriebsregeln.
- Die teuersten Probleme entstehen meist später, wenn Systeme verändert, ersetzt oder erweitert werden.
- In Deutschland ist das besonders relevant für Verwaltung, Industrie, Energie, Mobilität und Gesundheit.
Was ein föderierter Systemverbund wirklich ist
Ich beschreibe das Konzept am liebsten so: Es geht nicht um ein einziges System mit vielen Modulen, sondern um mehrere eigenständige Systeme, die durch gemeinsame Ziele, Schnittstellen und Regeln zusammenwirken. Jedes Teilsystem kann für sich funktionieren, wird aber im Verbund um eine Fähigkeit erweitert, die keines der Systeme allein erreichen würde. Genau daraus entsteht der typische Nutzen, aber auch die Komplexität.
Der wichtige Unterschied zur klassischen Systemintegration ist die Autonomie. In einem normalen Projekt kontrolliert meist ein Team den Kern, die Releases und die Architektur. In einem föderierten Verbund liegen Ownership, Budgets und Weiterentwicklung dagegen verteilt bei mehreren Organisationen, Fachbereichen oder Herstellern. Das Gesamtverhalten entsteht dann nicht nur aus Technik, sondern auch aus Absprachen, Zuständigkeiten und Abhängigkeiten.
In der Praxis zeigt sich das überall dort, wo Fachanwendungen, Plattformen und Infrastrukturen nicht aus einem Guss stammen: zum Beispiel in Behördenlandschaften, Klinikverbünden, Energie- und Verkehrsnetzen oder Industrie-4.0-Umgebungen. Die Systeme müssen zusammenarbeiten, obwohl sie unterschiedliche Lebenszyklen, Prioritäten und Release-Zyklen haben. Wer das ignoriert, plant schnell an der Realität vorbei.
Damit wird auch klar, warum die Architekturfrage nicht nachrangig ist, sondern den gesamten Betrieb bestimmt. Genau deshalb lohnt sich der Blick auf die Einsatzfelder im nächsten Schritt.
Warum dieses Modell in der IT so häufig auftritt
Der Bedarf entsteht fast immer aus einer Mischung von Wachstum, Heterogenität und organisatorischer Trennung. Ein einzelnes monolithisches Zielsystem wäre theoretisch sauber, praktisch aber oft zu träge, zu teuer oder politisch nicht durchsetzbar. Stattdessen wachsen Landschaften über Jahre, werden von mehreren Anbietern getragen und müssen trotzdem einen gemeinsamen Nutzen liefern.
| Merkmal | Klassische Integration | Föderierter Systemverbund |
|---|---|---|
| Steuerung | Eine zentrale Instanz bestimmt Architektur und Release-Rhythmus. | Mehrere Eigentümer koordinieren sich über Standards und Regeln. |
| Änderungen | Oft synchron und stark gekoppelt. | Idealerweise unabhängig, mit klaren Verträgen zwischen den Systemen. |
| Ausfallverhalten | Ein Fehler kann den gesamten Kern betreffen. | Teilausfälle sind möglich, wenn Entkopplung und Fallbacks sauber sind. |
| Stärke | Einfachere Steuerung und klarere Verantwortung. | Höhere Anpassungsfähigkeit und bessere Skalierbarkeit über Organisationsgrenzen hinweg. |
| Schwäche | Weniger flexibel bei Vielfalt und Wachstum. | Mehr Governance-Aufwand, mehr Koordinationsbedarf, mehr Semantik-Probleme. |
Gerade in Deutschland sehe ich diesen Bedarf oft dort, wo Behörden, Kommunen, Versorger, Krankenhäuser oder industrielle Partner ihre Eigenständigkeit behalten müssen und trotzdem gemeinsame Prozesse brauchen. Dazu kommen regulatorische Anforderungen, Datenschutz, Bestandssoftware und lange Nutzungszeiträume. Das macht den Verbund nicht zum Ausnahmefall, sondern fast zum Normalfall moderner IT.
Genau deshalb lohnt es sich, die unterschiedlichen Grundformen zu unterscheiden, statt alles unter einem Etikett zu verstecken. Aus dieser Einordnung ergibt sich unmittelbar die technische und organisatorische Klammer.
Die vier Grundformen und was sie in Projekten bedeuten
Die gängige Typologie unterscheidet vier Grundformen. In der Praxis sind diese Kategorien selten absolut, aber sie helfen sehr gut dabei, Erwartung und Steuerbarkeit realistisch zu machen.
| Typ | Steuerung | Praktische Bedeutung | Typisches Risiko |
|---|---|---|---|
| Directed | Stark zentral | Der Verbund verfolgt einen klar vorgegebenen Zweck, die Teilsysteme ordnen sich diesem Ziel unter. | Zu viel Zentralisierung bremst Innovation und Akzeptanz. |
| Acknowledged | Koordiniert, aber verteilt | Es gibt eine gemeinsame Absicht und eine zentrale Koordination, die Systeme bleiben jedoch eigenständig. | Änderungen brauchen Abstimmung und sind langsamer als in einem Einzelsystem. |
| Collaborative | Gemeinsame Vereinbarung | Mehrere Parteien kooperieren freiwillig über Standards und gemeinsame Ziele. | Der Verbund ist nur so stabil wie die Kooperation seiner Beteiligten. |
| Virtual | Kaum zentrale Kontrolle | Ein übergeordnetes Verhalten entsteht eher aus der Interaktion als aus zentraler Steuerung. | Schwer vorhersagbar, schwer zu regeln und oft nur begrenzt beherrschbar. |
Wichtig ist ein Detail, das in Projekten gern übersehen wird: Ein realer Verbund bleibt nicht zwangsläufig dauerhaft in derselben Form. Aus einem kooperativen Modell kann sich später ein stärker koordinierter Betrieb entwickeln, oder umgekehrt. Ich halte deshalb wenig von starren Etiketten und viel von einer ehrlichen Analyse der Macht-, Eigentums- und Veränderungsbeziehungen.
Emergenz ist hier das Schlüsselwort: Das Gesamtverhalten entsteht aus den Wechselwirkungen der Einzelteile und ist nicht vollständig aus einem Teilsystem ableitbar. Aus dieser Typologie ergibt sich unmittelbar, wie sorgfältig die technische Klammer gebaut werden muss.
Wie die Architektur im Alltag zusammenhält
Wenn ich solche Landschaften bewerte, schaue ich zuerst nicht auf Tools, sondern auf drei Dinge: Schnittstellen, Daten und Betrieb. Diese drei Ebenen entscheiden fast immer darüber, ob ein Verbund robust wächst oder in Einzelabstimmungen erstickt.
Schnittstellen zuerst entwerfen
Ein sauberer Verbund lebt von klaren Verträgen. Das können APIs, Ereignisströme oder andere standardisierte Austauschformate sein. Entscheidend ist nicht die Technikmode, sondern dass jedes Teilsystem seinen Innenraum behalten darf und nur über stabile, dokumentierte Übergaben mit dem Rest spricht. Punkt-zu-Punkt-Sonderwege wirken kurzfristig schnell, machen den Verbund aber langfristig fragil.
Daten ohne gemeinsame Semantik bringen wenig
Interoperabilität bedeutet mehr als Datentransport. Identitäten, Fachbegriffe, Metadaten und Herkunftsinformationen müssen eindeutig sein, sonst tauschen Systeme zwar Bits aus, verstehen sich aber fachlich nicht. Ich nenne das gern den Unterschied zwischen Transport und Bedeutung. Wer hier spart, bezahlt später mit Abstimmungsaufwand, Fehlinterpretationen und teuren Migrationsprojekten.
Lesen Sie auch: Data Modeling Tools - Welches passt wirklich zu Ihrem Projekt?
Betrieb, Sicherheit und Beobachtbarkeit gehören dazu
Ein Verbund aus unabhängigen Systemen braucht mehr als eine schöne Architekturskizze. Logging, Metriken, Tracing, Zugriffssteuerung, Fallback-Mechanismen und ein sauberes Änderungsmanagement sind Teil der Lösung, nicht nur Betriebsglanz. Gerade bei langen Lebenszyklen hilft mir oft MBSE, also modellbasiertes Systems Engineering, weil Abhängigkeiten und Folgen von Änderungen sichtbar werden, bevor sie im Produktivbetrieb schmerzen.
Die Prozesssprache aus dem Umfeld von ISO/IEC/IEEE 15288 passt hier gut, weil sie den Lebenszyklus mitdenkt und nicht nur den Go-live. Wenn diese Grundlagen fehlen, wird jede spätere Änderung teurer, als sie auf dem Papier aussieht.
Die teuersten Fehler in solchen Projekten
Die meisten Probleme entstehen nicht bei der ersten Integration, sondern beim nächsten Umbau. Genau dort zeigt sich, ob ein Verbund wirklich tragfähig ist oder nur durch viel Handarbeit funktioniert.
- Zu früh zentralisieren. Wer alle Entscheidungen an einen Kern bindet, erzeugt kurzfristig Ordnung, aber langfristig Abhängigkeit und Flaschenhälse.
- Semantik mit Transport verwechseln. Eine funktionierende Schnittstelle ist noch kein gemeinsames Fachverständnis.
- Unklare Ownership akzeptieren. Wenn niemand für Daten, Schnittstellen oder Deprecation verantwortlich ist, bleibt jede Änderung ein Konfliktfall.
- Versionierung aufschieben. Ohne klare Regeln für Schema-Änderungen, Kompatibilität und Übergangsphasen wird jede Erweiterung riskant.
- Sicherheit und Resilienz zu spät betrachten. In einem Verbund potenzieren sich nicht nur Chancen, sondern auch Ausfälle, Fehlkonfigurationen und Zugriffsprobleme.
Wer solche Fehler früh erkennt, kann den Verbund auch fair bewerten statt nur auf Intuition zu vertrauen. Genau dafür lohnt sich ein Blick auf messbare Kriterien.
Woran ich Nutzen und Reife messe
Ich frage in Reviews meist fünf sehr einfache, aber aufschlussreiche Dinge:
- Kann ein neues Teilsystem angebunden werden, ohne den Rest der Landschaft umzubauen?
- Lassen sich Schnittstellen unabhängig versionieren und sauber deprecaten?
- Ist klar, wer welche Daten verantwortet und nach welchen Regeln sie verwendet werden?
- Kann der Verbund einen Teilausfall überstehen, ohne den gesamten Prozess zu stoppen?
- Verstehen Fachseite, Architektur und Betrieb dieselbe Terminologie oder reden sie aneinander vorbei?
Wenn diese Fragen sauber beantwortet sind, ist der Verbund meist reif genug für Wachstum. Wenn nicht, hilft auch die beste Technologie nicht viel. Dann fehlt nicht ein weiteres Tool, sondern eine belastbare Koordinations- und Architekturentscheidung.
Ich bewerte den Nutzen außerdem daran, wie teuer Veränderung ist. Ein gutes Zielbild ist nicht, dass alles möglichst zentral ist, sondern dass ein System ersetzt, modernisiert oder skaliert werden kann, ohne den gesamten Verbund neu zu bauen. Am Ende ist der Zielzustand erstaunlich schlicht: Autonomie dort, wo sie nötig ist, und Verlässlichkeit dort, wo sie gemeinsam erzeugt werden muss.
Worauf ich 2026 den größten Wert lege
Für mich ist die wichtigste Lehre aus diesem Thema: Ein föderierter Systemverbund ist keine Notlösung, sondern eine passende Antwort auf reale organisatorische und technische Vielfalt. Er funktioniert dann gut, wenn man Autonomie nicht bekämpft, sondern bewusst gestaltet.
- Standardisiere Schnittstellen, nicht unnötig das Innenleben der Systeme.
- Dokumentiere Datenbedeutung ebenso streng wie technische Formate.
- Plane Änderungen, Migrationen und Abschaltungen von Anfang an mit.
- Halte Governance schlank, aber verbindlich.
- Miss Erfolg nicht nur am Go-live, sondern an der Fähigkeit zur Weiterentwicklung.
Wer so denkt, baut keine fragile Sammelstelle vieler Einzellösungen, sondern einen belastbaren Verbund mit klarer Mission. Genau dort liegt der eigentliche Wert dieses Architekturmodells.
