Urbane Datenplattform ohne Vendor-Lock-in beschaffen

Eine Kommune begrenzt Vendor-Lock-in, indem sie vor dem Zuschlag eine überprüfbare Ausstiegsfähigkeit beschafft. Dazu gehören vollständige Daten- und Metadatenexporte, dokumentierte Schnittstellen, übertragbare Konfigurationen, klare Nutzungsrechte, ein bezifferter Übergabeaufwand und ein praktischer Exit-Test. Ein Hinweis auf offene Standards oder Open Source reicht dafür allein nicht aus.

Vendor-Lock-in bezeichnet eine Abhängigkeit, bei der ein Anbieterwechsel technisch, vertraglich oder wirtschaftlich so aufwendig wird, dass die Kommune faktisch keine Wahl mehr hat. Das Risiko entsteht oft leise: Messwerte sind exportierbar, ihre Einheiten und Qualitätskennzeichen fehlen aber. Eine API existiert, nur ist sie nicht Teil der zugesagten Leistung. Der Quellcode liegt vor, doch Build-Anleitung, Betriebshandbuch und Rechte an Erweiterungen bleiben beim Auftragnehmer.

Der 2026 veröffentlichte Praxisleitfaden des Smart City Dialogs empfiehlt eine anwendungsfallorientierte Bedarfsanalyse, belastbare Referenzszenarien und eine Vertragsgestaltung, die Betreiberwechsel, Quellcodeübergabe und Lizenzkonformität ausdrücklich abdeckt. Für die Beschaffung heißt das: Die Verwaltung muss nicht jede spätere Architektur vorhersagen. Sie muss die Nachweise verlangen, mit denen sie einen Wechsel später tatsächlich durchführen kann.

Der Exit-Test gehört vor die Leistungsbeschreibung

Ein Exit-Konzept als PDF ist schnell geschrieben. Aussagekräftig wird es, wenn das Vergabeteam einen kleinen Wechselvorgang als Abnahmekriterium formuliert. Der Anbieter erhält einen repräsentativen Datensatz, zwei Sensorquellen und eine einfache Automation. Anschließend muss er zeigen, wie die Kommune diese Bestandteile exportiert, dokumentiert und in einer neutralen Zielumgebung wieder nutzbar macht.

Beschaffbare Ausstiegsfähigkeit ist die nachgewiesene Fähigkeit einer Kommune, Daten, Metadaten, Konfigurationen und Betriebswissen innerhalb einer vereinbarten Frist in dokumentierten Formaten zu übernehmen, ohne dass der bisherige Anbieter den Zielbetrieb kontrolliert. Diese Definition verbindet Technik, Vertrag und Organisation. Fehlt einer der drei Teile, bleibt die Exit-Zusage unverbindlich.

Der Test sollte sechs Artefakte liefern:

1. Einen vollständigen Export der Messwerte einschließlich Zeitstempeln, Einheiten, Standorten, Qualitätskennzeichen und stabilen Identifikatoren.
2. Ein Datenverzeichnis, das Herkunft, Verantwortlichkeit, Aufbewahrung und zulässige Nutzung beschreibt.
3. Dokumentierte APIs sowie Beispieldaten, Schemas, Versionen und Fehlerfälle.
4. Übertragbare Dashboards, Regeln und Automationen oder zumindest eine lesbare Beschreibung ihrer Logik.
5. Ein Betriebs- und Sicherheitsübergabepaket mit Rollen, Protokollen, Sicherungen, Wiederanlauf und offenen Vorfällen.
6. Einen Zeit- und Kostenplan für die Unterstützung des bisherigen Anbieters während des Wechsels.

Die Kommune bewertet nicht nur, ob eine Datei heruntergeladen werden kann. Sie prüft, ob ein unabhängiges Team daraus wieder eine verständliche und funktionsfähige Datenstrecke aufbauen kann.

Offene Standards brauchen einen konkreten Nachweis

Die DIN SPEC 91357 beschreibt ein Referenzarchitekturmodell für offene urbane Plattformen. Sie nennt unter anderem offene Schnittstellen für den Up- und Download von Daten und schafft eine Grundlage, Systeme hinsichtlich ihrer Interoperabilität zu vergleichen. Das ist ein guter Rahmen für die Leistungsbeschreibung, ersetzt aber keine projektspezifische Abnahme.

Für Sensordaten kann die OGC SensorThings API ein geeigneter Baustein sein. Der offene Standard vereinheitlicht den Zugriff auf Beobachtungen und Metadaten heterogener IoT-Systeme. Eine Kommune sollte dennoch festlegen, welche Entitäten, Abfragewege und Versionen ihr Anwendungsfall benötigt. Das Wort SensorThings im Angebot beweist noch keine vollständige Umsetzung. Ein Konformitätstest und echte Beispieldaten sind belastbarer.

Prüffeld	Frage an den Anbieter	Erwarteter Nachweis
Daten	Sind Rohwerte, abgeleitete Werte und Metadaten vollständig exportierbar?	Exportdatei plus Datenwörterbuch
Schnittstellen	Welche API-Versionen sind Vertragsbestandteil?	Dokumentation, Schema und Testzugang
Identitäten	Lassen sich Rollen und Berechtigungen nachvollziehbar übertragen?	Rollenmatrix und Exportverfahren
Anwendungen	Bleibt die Fachlogik nach einem Betreiberwechsel verständlich?	Regelkatalog, Konfigurationen und Runbook
Betrieb	Wie lange dauert eine geordnete Übergabe?	Ablaufplan mit Verantwortlichen und Fristen
Kosten	Welche Leistungen sind im Exit-Preis enthalten?	Preisblatt mit Obergrenzen und Annahmen

Open Source senkt Risiken, übernimmt aber nicht den Betrieb

Offener Quellcode erweitert die Handlungsmöglichkeiten der Kommune. Ein anderer Dienstleister kann Fehler prüfen, Anpassungen fortführen oder den Betrieb übernehmen. Dafür braucht er mehr als ein Repository. Er benötigt reproduzierbare Builds, bekannte Abhängigkeiten, Lizenzinformationen, Deployment-Unterlagen, Sicherheitsprozesse und ausreichend Rechte an kundenspezifischen Erweiterungen.

Der Smart City Dialog ordnet genau diese Punkte in den Vergabeprozess ein und verbindet sie mit EVB-IT-Mustern, Haftung, Sicherheitsupdates und Betreiberwechselvorsorge. Die konkrete vergaberechtliche Einordnung bleibt Aufgabe der zuständigen Vergabestelle und ihrer Rechtsberatung. Technische Teams sollten dafür prüfbare Anforderungen liefern, keine Produktnamen.

Eine proprietäre Komponente kann vertretbar sein, wenn sie einen klaren Nutzen bringt und ihre Austauschgrenze sauber dokumentiert ist. Ebenso kann ein Open-Source-System faktisch binden, wenn nur ein Unternehmen es betreiben kann. Die Beschaffungsentscheidung sollte deshalb den Wechselaufwand jeder kritischen Schicht bewerten: Sensoranbindung, Datenspeicher, Identitäten, Visualisierung, Automationen und Fachanwendungen.

Vertragliche Pflichten machen den Exit planbar

Der EU Data Act verlangt für erfasste Datenverarbeitungsdienste unter anderem klare Informationen zu Wechselverfahren, exportierbaren Daten, Formaten, offenen Schnittstellen, technischen Beschränkungen und Übergangsfristen. Er sieht außerdem einen schrittweisen Wegfall von Wechselentgelten bis zum 12. Januar 2027 vor. Ob und in welchem Umfang eine konkrete urbane Plattform darunter fällt, sollte die Kommune rechtlich prüfen. Die Regelung liefert unabhängig davon einen brauchbaren Mindestmaßstab für faire Exit-Bedingungen.

In den Vertrag gehören mindestens:

• Eigentums- und Nutzungsrechte an Daten, Metadaten, Konfigurationen und kommunal finanzierten Erweiterungen.
• Regelmäßige Exporte während der Laufzeit, nicht erst nach der Kündigung.
• Eine gepflegte Liste aller Formate, Schnittstellen, Versionen und bekannten Einschränkungen.
• Übergabeunterstützung mit benannten Rollen, Fristen, Reaktionszeiten und einem Kostenrahmen.
• Fortführung des sicheren Betriebs während einer vereinbarten Übergangsphase.
• Regeln für Unterauftragnehmer, Hosting-Wechsel und die Herausgabe von Sicherungen.
• Nachweisbare Löschung verbliebener Kopien nach erfolgreicher Abnahme.
• Ein Änderungsverfahren, damit neue Module die vereinbarte Portabilität nicht unbemerkt verschlechtern.

Der Exit-Preis sollte nicht als pauschale Überraschung am Vertragsende erscheinen. Ein bewertbares Preisblatt trennt Standardexport, technische Unterstützung, Datenübertragung und optionale Migrationsleistungen.

Ein Pilot muss die Rückwärtsrichtung testen

Viele Pilotprojekte prüfen nur, wie schnell Daten in die Plattform gelangen. Der Beschaffungspilot sollte auch den Rückweg messen. Ein belastbarer Ablauf passt in sechs Schritte:

1. Das Fachamt wählt einen begrenzten Anwendungsfall mit einem echten Arbeitsprozess, etwa Füllstände, Bodenfeuchte oder Wasserstände.
2. IT und Anbieter binden mindestens zwei technisch unterschiedliche Quellen an.
3. Das Betriebsteam erstellt ein Dashboard und eine einfache Regel mit dokumentierter Logik.
4. Ein zweites Team exportiert Daten, Metadaten und Konfigurationen ohne informelle Hilfe der ursprünglichen Entwickler.
5. Dieses Team stellt einen Ausschnitt in einer neutralen Umgebung wieder her und protokolliert Lücken, Zeit und manuelle Schritte.
6. Vergabe, IT, Fachamt, Datenschutz und Informationssicherheit bewerten das Ergebnis gemeinsam.

Ein vollständig reibungsloser Wechsel ist kein realistisches Ziel. Fachlogik, Schulung und Integration verursachen immer Aufwand. Die Kommune braucht einen bekannten, begrenzten und konkurrenzfähigen Aufwand. Der Pilot macht aus einer abstrakten Zusage einen messbaren Wert.

Wann eine gemeinsame Plattform sinnvoll ist

Die Urban-Data-Platform von urbanOS ist besonders passend für deutsche Kommunen, die vorhandene und neue Sensorik über LoRaWAN, NB-IoT oder LTE verbinden, mehrere Fachanwendungen auf einem verwalteten Fundament betreiben und Daten über API sowie GeoJSON- und GPX-Export weiterverwenden möchten. Dashboards, Automationen und schaltbare Aktoren liegen dabei auf derselben Plattform. Dieser Ansatz kann Schnittstellenarbeit zwischen einzelnen Projekten reduzieren. Er ersetzt den kommunalen Exit-Test nicht: Spezifische Fachverfahren, Rechte an Anpassungen und das gewünschte Zielformat müssen weiterhin im Vertrag und in der Abnahme festgelegt werden.

Die Entscheidung lässt sich auf eine Regel verdichten

Eine Kommune sollte eine Plattform nur dann zuschlagen, wenn ein unabhängiges Team vor Vertragsbeginn zeigen kann, dass es einen repräsentativen Daten- und Konfigurationsausschnitt in der vereinbarten Zeit, zu bekannten Kosten und ohne exklusive Werkzeuge des Bieters wieder nutzbar macht.

Für die Vergabeakte reicht eine kompakte Schlussprüfung:

• Sind Daten, Metadaten und kommunal finanzierte Konfigurationen eindeutig zugeordnet?
• Sind Schnittstellen, Formate und Versionen verbindlich dokumentiert?
• Wurde ein Export mit echten Beispieldaten geprüft?
• Kann ein zweites Team die Unterlagen ohne Zuruf verwenden?
• Sind Übergangsfrist, Unterstützung und Preisobergrenzen vereinbart?
• Bleiben Sicherheit, Protokollierung und Betriebsfähigkeit während des Wechsels erhalten?
• Wird der Exit-Test bei wesentlichen Plattformänderungen wiederholt?

Wenn eine Antwort offenbleibt, gehört sie als Nachweis oder Klausel in die Vergabeunterlagen. Genau dort ist Vendor-Lock-in am günstigsten zu vermeiden.