Offene Standards: Die gemeinsame Sprache digitaler Verwaltung

Über offene Standards wird selten gesprochen, wenn ein digitaler Dienst gut funktioniert. Man sieht die Oberfläche, vielleicht den Antrag, vielleicht die Bestätigung am Ende. Unsichtbar bleibt, was darunter abgestimmt werden musste: Welche Angaben werden erwartet, wie werden sie benannt, in welchem Format werden sie übergeben, und welches System darf sich darauf verlassen?

Ich habe in Projekten oft erlebt, dass diese Fragen am Anfang kleiner wirken, als sie sind. Ein Online-Dienst fragt nach einer Anschrift, das Fachverfahren erwartet eine Anschrift, ein Register führt ebenfalls Anschriften. Auf dem Papier scheint alles klar zu sein. In der Umsetzung merkt man dann: Die Systeme meinen nicht zwingend dasselbe.

Ist der Straßenname ein eigenes Feld oder steckt er in einer Freitextzeile? Wie werden Hausnummernzusätze behandelt? Welche Zeichen sind in Namen erlaubt? Wird eine ausländische Adresse überhaupt sauber abgebildet? Und was passiert, wenn ein Feld im Formular freiwillig ist, im Fachverfahren aber als Pflichtangabe geführt wird?

Solche Fragen wirken klein, fast pedantisch. In realen Projekten entscheiden sie aber darüber, ob digitale Verwaltung wirklich digital bleibt oder am Ende doch wieder jemand Daten abschreibt, nachtelefoniert oder eine PDF-Datei ausdruckt. Offene Standards sind deshalb für mich weniger ein technisches Ideal als eine praktische Voraussetzung: Sie helfen dabei, dass Verwaltungssysteme dieselbe Sprache sprechen.

Ein Feld ist nie nur ein Feld

Wenn über offene Standards gesprochen wird, geht es schnell um Dateiformate, Schnittstellen und Protokolle. Diese Ebene gehört dazu, erklärt aber nur einen Teil des Problems. Ein Standard klärt nicht nur, wie Daten technisch übertragen werden. Er klärt auch, was diese Daten bedeuten.

Das ist in der Verwaltung besonders wichtig, weil sie mit rechtlich geprägten Begriffen arbeitet. Ein „Antragsteller“ ist nicht einfach ein Nutzerkonto. Eine „zuständige Stelle“ ist nicht bloß eine Adresse in einer Datenbank. Ein „Nachweis“ kann ein Dokument, ein Registerabruf oder eine Bescheinigung sein. Und je nach Leistung, Fachrecht und Vollzugsebene kann derselbe Begriff unterschiedliche Folgen haben.

Gute Standards übersetzen diese Fachlichkeit in eine Form, die Systeme verarbeiten können, ohne die Bedeutung plattzubügeln. Genau darin liegt die Schwierigkeit. Man muss nah genug am Recht und an der Verwaltungspraxis bleiben, aber konkret genug werden, damit Entwickler:innen, Fachverfahrenshersteller und Betreiber damit arbeiten können.

Das Föderale Informationsmanagement, kurz FIM, ist ein gutes Beispiel dafür. Es soll Rechtssprache in verständliche Leistungsbeschreibungen, Prozesse und Datenfelder übertragen. Die FITKO, also die Föderale IT-Kooperation von Bund und Ländern, koordiniert und vernetzt zentrale Vorhaben der Verwaltungsdigitalisierung für den IT-Planungsrat. Sie beschreibt FIM als standardisierte Übersetzung der Rechtssprache in eine bürger:innen- und unternehmensfreundliche Sprache und verweist auf die Nachnutzung qualitätsgesicherter Leistungsbeschreibungen und Datenfelder.

Der praktische Nutzen liegt in dieser Nachnutzung. Wenn jede Stelle dieselbe Leistung neu beschreibt, entstehen zwangsläufig Abweichungen. Manche sind fachlich nötig. Viele sind einfach nur teuer.

Mit XDatenfelder wurde dieser Gedanke in einen Interoperabilitätsstandard überführt. Der IT-Planungsrat hat 2019 die verbindliche Nutzung von XDatenfelder für den standardisierten Austausch von Stamminformationen des FIM-Bausteins „Datenfelder“ zwischen den Redaktionssystemen von Bund und Ländern beschlossen. Solche Beschlüsse klingen unspektakulär, machen aus einer guten Absicht aber eine belastbare Arbeitsgrundlage.

Merkmale offener Standards

Offenheit ist bei Standards kein Etikett, sondern ein Arbeitsversprechen. Eine Spezifikation hilft erst dann, wenn unterschiedliche Verwaltungen, Hersteller und Betreiber sie verstehen, implementieren und überprüfen können. Deshalb reicht es nicht, wenn irgendwo ein Dokument zum Download liegt.

Ich verstehe offene Standards hier als Spezifikationen, die öffentlich zugänglich, nachvollziehbar gepflegt und unabhängig von einzelnen Anbietern implementierbar sind. Sie sind nicht dasselbe wie Open Source: Ein offener Standard kann unabhängig davon umgesetzt werden, ob die Software selbst quelloffen oder proprietär ist. Entscheidend ist die gemeinsame Grundlage, nicht das Lizenzmodell der konkreten Anwendung.

Für die Praxis heißt das: Kann ein Fachverfahrenshersteller den Standard implementieren, ohne Sonderwissen eines Konkurrenten zu brauchen? Gibt es Versionen, Codelisten, Schemata, Beispiele und klare Zuständigkeiten? Ist erkennbar, wer über Änderungen entscheidet und wie lange alte Versionen unterstützt werden? Lässt sich prüfen, ob eine Implementierung wirklich konform ist?

Standardisierung besteht deshalb auch aus Dokumentation, Gremien, Testfällen, Fehlermeldungen und Übergangsfristen. Fehlt diese Arbeit, merkt man es später an jeder Ecke.

Das XÖV-Rahmenwerk zeigt diese Betriebsdimension recht gut. XÖV steht für „XML in der öffentlichen Verwaltung“. Das Rahmenwerk stellt praxiserprobte Methoden und Produkte für die Entwicklung und den Betrieb von IT-Standards für den Datenaustausch zwischen Fachverfahren bereit. Die XÖV-Zertifizierung prüft Standardisierungsvorhaben anhand der Bewertungs- und Qualitätskriterien des XÖV-Handbuchs auf XÖV-Konformität.

Noch greifbarer wird das beim XRepository. Dort werden XÖV-Standards, Codelisten und weitere Artefakte bereitgestellt. Für Menschen außerhalb dieser Welt klingt das vielleicht nach Ablage. In der Praxis ist es aber ein wichtiger Teil der Infrastruktur. Standards müssen gefunden, abonniert, versioniert und im Betrieb genutzt werden können. Ein Standard, den niemand zuverlässig findet oder dessen Codelisten in alten Excel-Dateien herumliegen, kann fachlich noch so gut sein: Operativ bleibt er kaum benutzbar.

Interoperabilität ist mehr als eine Schnittstelle

In Projekten wird „Schnittstelle“ manchmal so verwendet, als sei damit das Problem erledigt. Zwei Systeme können Daten austauschen, also sind sie verbunden. Doch eine sauber dokumentierte API klärt noch nicht, welche Fachlogik hinter einem Statuswert steckt. Selbst ein valider Datensatz kann im falschen Prozessschritt ankommen. Und ein vollständig ausgefülltes Formular kann manuelle Nacharbeit erzeugen, wenn Nachweise nicht eindeutig zugeordnet sind.

Auch auf europäischer Ebene wird Interoperabilität breiter gefasst. Der Interoperable Europe Act, der seit dem 11. April 2024 in Kraft ist, stärkt die grenzüberschreitende Zusammenarbeit im öffentlichen Sektor und die Wiederverwendung gemeinsamer Lösungen. Seit dem 12. Januar 2025 sind außerdem Interoperabilitätsbewertungen vorgeschrieben, bevor neue oder wesentlich geänderte verbindliche Anforderungen an transeuropäische digitale öffentliche Dienste beschlossen werden, sofern diese Anforderungen die grenzüberschreitende Interoperabilität betreffen.

Für die Praxis ist dieses Zusammenspiel entscheidend. Bleibt eine Ebene ungeklärt, landet das Problem meist bei den Menschen im Verfahren: Sachbearbeiter:innen interpretieren, was Systeme nicht sauber ausdrücken. Bürger:innen liefern Informationen erneut.

Der Weg vom Onlinedienst ins Fachverfahren

Gemeinsame Begriffe und Datenmodelle sorgen noch nicht dafür, dass ein digitaler Antrag im richtigen Fachverfahren ankommt. Ein Datenschema kann seinen Inhalt festlegen. Es regelt aber nicht, wie der Antrag sicher zur zuständigen Behörde gelangt, wie der Empfang bestätigt und das Fachverfahren angebunden wird. Dafür braucht es Infrastruktur und klare Schnittstellen.

FIT-Connect setzt an dieser Stelle an. Die FITKO beschreibt FIT-Connect als Möglichkeit, Online-Antragsdienste und Fachverfahren über einheitliche Schnittstellen und Standards zu verbinden. Es geht um maschinenlesbare, verschlüsselte Kommunikation zwischen Antragsteller:innen, Onlinediensten und den zuständigen Fachbehörden.

An diesem Übergang stellen sich in vielen Digitalisierungsprojekten dieselben Fragen: Wie gelangt der Antrag sicher ins richtige Fachverfahren? Wie wird eine zentrale Lösung in vielen Kommunen nutzbar, ohne für jede Stelle eine Sonderintegration zu bauen?

Ohne verlässliche Anbindung landet ein eigentlich digitaler Antrag schnell wieder als PDF in einem Postfach. Er ist dann zwar online gestellt worden, aber im Fachverfahren beginnt die Arbeit fast von vorn.

FIT-Connect beantwortet damit vor allem Fragen des Transports. Die fachliche Standardisierung ersetzt es nicht. Wenn die Fachdaten unklar modelliert sind, transportiert auch die beste Anbindung diese Unklarheit nur zuverlässig weiter. Umgekehrt nützt das beste Datenmodell wenig, wenn jede Integration individuell gebaut werden muss. Nachhaltige Digitalisierung braucht beides: gemeinsame Bedeutung und verlässlichen Transport.

Standards entlasten nur, wenn sie gepflegt werden

In der Theorie klingt Standardisierung manchmal, als müsse man nur einmal sauber definieren, wie etwas funktioniert. Danach halten sich alle daran und die Welt wird einfacher.

So läuft es natürlich nicht. Recht ändert sich. Fachverfahren ändern sich. Neue Nachweise kommen hinzu. Alte Prozessschritte fallen weg. Begriffe werden präziser. Ein Standard ist deshalb kein abgeschlossenes Dokument, sondern ein eigenes Produkt mit Lebenszyklus.

Das wird besonders deutlich, wenn Codelisten im Spiel sind. Über sie möchte niemand sprechen, solange sie funktionieren. Sobald sie es nicht tun, sprechen plötzlich alle darüber. Codelisten legen fest, welche Werte ein Feld annehmen darf: Status, Kategorien, Behördenkennungen, Arten von Nachweisen, Staaten, Rollen, Gründe. Werden sie nicht gepflegt, entstehen Workarounds. Freitextfelder kommen zurück. Systeme akzeptieren „Sonstiges“. Ausnahmen werden per E-Mail geklärt. Und irgendwann ist kaum noch nachvollziehbar, warum der digitale Prozess so viel manuelle Nacharbeit erzeugt.

Auch Migration gehört dazu. Standards entwickeln sich weiter, aber Verwaltungen arbeiten mit bestehenden Systemen, Verträgen und Datenbeständen. Man kann nicht jede neue Version sofort überall ausrollen. Es braucht Übergänge, Kompatibilität und klare Kommunikation. Sonst wird Standardisierung selbst zur Belastung.

Das ist einer der Punkte, an denen ich in Projekten vorsichtig geworden bin. Ein Standard ist nicht automatisch gut, nur weil er offen ist. Er kann zu groß, zu abstrakt, zu langsam oder zu weit weg von der Umsetzung sein. Er kann mehr versprechen, als die beteiligten Organisationen tragen können. Und manchmal ist eine kleine, gut dokumentierte Vereinbarung für einen begrenzten Zweck besser als ein großer Standard, der niemandem wirklich gehört.

Was offene Standards im Alltag verändern

Trotz dieser Einschränkungen verhindern offene Standards, dass jedes Projekt bei null beginnt. Verwaltungen können in Ausschreibungen konkrete Standards, Versionen und Konformitätsanforderungen benennen. Hersteller müssen nicht für jede Kommune eine neue Sonderlogik bauen, sondern können auf einer stabileren Grundlage arbeiten. Das macht Angebote vergleichbarer und kann gerade für kleinere Anbieter Eintrittshürden senken.

Im Arbeitsalltag zeigt sich der Nutzen indirekt: Sachbearbeiter:innen übertragen weniger Daten von Hand und müssen seltener nachfragen, weil Informationen strukturierter ankommen. Bürger:innen und Unternehmen müssen die innere Komplexität der Verwaltung seltener ausbaden. Ein Antrag darf fachlich kompliziert sein, wenn das Recht kompliziert ist. Er sollte aber nicht zusätzlich dadurch kompliziert werden, dass Systeme keine gemeinsame Sprache haben.

Die Registermodernisierung und das Nationale Once-Only-Technical-System, kurz NOOTS, zeigen, wie groß dieser Anspruch wird. Auf der NOOTS-Wissensplattform wird das Once-Only-Prinzip so beschrieben, dass der Verwaltung bereits vorliegende Nachweisdaten auf Wunsch von Bürger:innen und Unternehmen automatisiert abgerufen werden können, statt erneut erhoben zu werden. Dafür müssen Register und Onlinedienste sicher und digital Daten austauschen können. Die Registerübersicht führt die gemäß IDNrG anzuschließenden Registertypen nach Fachdomänen auf und macht sichtbar, welche Zuständigkeiten daran hängen.

Gerade deshalb sollte man Once Only nicht als Zauberwort behandeln. Es funktioniert nur, wenn Daten fachlich verstanden, rechtlich zulässig, technisch sicher und organisatorisch verantwortet ausgetauscht werden. Offene Standards sind dafür keine hinreichende Bedingung. Ohne sie wird es aber sehr schwer.

Die gemeinsame Sprache muss gelernt werden

Standards gehören deshalb früh in ein Projekt, bevor die Oberfläche fertig ist oder der Dienst produktiv gehen soll. Als Anhang in einem technischen Konzept, den am Ende niemand liest, entfalten sie kaum Wirkung.

Ich würde sie wie Architekturentscheidungen behandeln: Welche Begriffe und Datenmodelle übernehmen wir? Wo weichen wir bewusst ab? Welche Schnittstellen sind verbindlich, und wie gehen wir mit neuen Versionen um?

Diese Entscheidungen bestimmen, wie beweglich ein System später ist und wie viel Arbeit sich bei der nächsten Leistung, der nächsten Kommune oder dem nächsten Fachverfahren wiederverwenden lässt.

Offene Standards versprechen keinen schnellen Aha-Moment. Ihr Nutzen zeigt sich eher darin, dass bestimmte Probleme gar nicht erst entstehen. Gute Standardisierung ist im besten Fall unsichtbar. Der Antrag kommt an. Die Daten passen. Das Fachverfahren versteht sie. Die zuständige Stelle kann weiterarbeiten.

Nachhaltige Digitalisierung beginnt lange vor der nächsten Oberfläche: bei Begriffen, Datenmodellen, Schnittstellen und der Frage, ob andere darauf verlässlich aufbauen können.

Offene Standards nehmen diese Arbeit niemandem ab. Sie geben ihr aber eine Form, auf die sich viele einigen können. Darin liegt ihr Wert: Sie schaffen die gemeinsame Grundlage, auf der Verwaltungen Stück für Stück besser zusammenarbeiten können.