Interoperabilität bedeutet: Systeme können zusammenarbeiten, ohne dass jede Verbindung ein Sonderprojekt ist. Offene Komponenten und Standards sind das Mittel dafür — kein Selbstzweck.

Open Source als Architekturentscheidung

Open Source reduziert Lizenzkäfige — aber nicht Komplexität. Integration, Schulung und Betrieb kosten Geld. Die Verteilung der Kosten ändert sich, nicht ihre Existenz.

FIWARE ist ein Open-Source-Ökosystem für Kontextdaten und Stadtintegration. Deutsche Städte wie Herne und Hamburg nutzen es produktiv. Hintergrund, Bausteine und Community finden sich auf fiware.org. Wichtig: Prüfen Sie, welche generischen Komponenten wirklich zu Ihren Fachverfahren passen — nicht alles übernehmen.

Ohne klare API-Politik driftet jede Komponente zur Sonderlösung. Drei Mindeststandards, die schriftlich verbindlich sein müssen:

• Authentifizierungsstandard (z. B. OAuth2)
• Fehlercodes und Versionierungskonvention
• Dokumentationspflicht für jede produktive API

Sicherheit: SBOM, Patch-Zeitfenster und Dependency-Scanning sind keine Extras. Open Source ohne diese Routinen ist riskanter als ein gepflegter Closed-Stack.

Governance für Standards: Wer entscheidet was?

Standards leben von Pflege. Ohne feste Verantwortung haben Kommunen nach zwei Jahren fünf konkurrierende PDF-Dokumente — und null verbindliche Wahrheit.

Ein Architekturgremium muss nicht groß sein. Drei bis fünf Personen aus IT, Fachbereich und Beschaffung reichen. Ihre Aufgabe:

• Verbindliche Standards beschließen — mit Versionsdatum und geplanter Review
• Empfohlene Standards kennzeichnen — mit Zeitbudget für Experimente
• Wildwuchs im Datenmodell stoppen — neue Felder brauchen schriftliches OK

Beschaffung muss eingebunden sein. Ausschreibungen, die keine Standards referenzieren, legalisieren proprietäre Insellösungen. Das kostet beim nächsten Systemwechsel doppelt.

Exit-Szenario einmal pro Jahr üben: Export, Restore, Weiterbetrieb mit einem anderen Integrator. Nicht weil Sie wechseln wollen — sondern weil Verhandlungsmacht durch Optionalität entsteht.

Lieferanten herausfordern: Integration statt Alleingang

Forderung an Lieferanten: offene Schnittstellen, keine Insellösungen. Das ist verhandelbar — wenn es früh im Prozess klar gemacht wird. Nicht nach Vertragsabschluss.

Verträge brauchen konkrete API- und Datenformat-Pflichten mit Sanktion bei Verstoß. Moderate Sanktionen, die vorhanden sind, sind wirksamer als strenge Klauseln, die niemand durchsetzt.

Testumgebungen mit anonymisierten Realdaten reduzieren Integrationsrisiko. Probleme entstehen oft aus zu sauberen Labors, die Produktionsbedingungen nicht abbilden.

Monitoring über Systemgrenzen hinweg: Eine Störung darf nicht zwischen drei Ticketsystemen zerfasern. Wessen Problem ist es? Das muss vorher geklärt sein.

Pilot: Einen Fachprozess end-to-end, nicht alles auf einmal

Der häufige Fehler: „Wir verbinden erst alles, dann schauen wir.“ Stattdessen: einen Fachprozess vollständig abbilden. Beispiel: Umweltdaten vom Sensor ins Lagebild der Verwaltung.

Messpunkte für den Pilot:

• Wie lange dauert die Anbindung eines neuen Partners?
• Wie hoch ist die mittlere Fehlerbehebungszeit?
• Welcher Anteil der Nachrichten wird automatisch validiert?

Nach dem Pilot: Budget für Laufkosten und Schulung einplanen. Interoperabilität ist kein einmaliges Projekt. Kooperation mit Nachbarkommunen spart Duplikate — aber nur mit dokumentierten Schnittstellen und benannten Verantwortlichen.

Kommunizieren Sie ehrlich: Standards helfen, garantieren aber keine Wunder. Wer internationale Referenzen wie FIWARE oder X-Road nutzt, zeigt Ernsthaftigkeit — nicht Größenwahn.

Weiterführende Quellen

• FIWARE.org — Ökosystem, Bausteine und Referenzprojekte
• X-Road Global — Sicherer Datenaustausch zwischen Verwaltungssystemen
• Interoperable Europe — EU-Standards für Verwaltungsinteroperabilität