API-Webdienste in der Marktkommunikation: Warum Stadtwerke Schnittstellen als Fachprozesse entkoppeln sollten

Der Releasekalender wird zur Architekturfrage

Die Mitteilung Nr. 55 der Bundesnetzagentur zu den Datenformaten der Marktkommunikation macht sichtbar, wie dicht der Veränderungsrhythmus in der energiewirtschaftlichen Abwicklung geworden ist. Für den Umsetzungstermin 1. Oktober 2026 werden zahlreiche Nachrichtentypversionen, Anwendungshandbücher, Prüfidentifikatoren, Codelisten, Regelungen zum Übertragungsweg und API-Dokumente konsultiert. Die Aufzählung wirkt zunächst wie ein technischer Katalog. Für Stadtwerke ist sie aber vor allem ein Hinweis auf die operative Realität: Marktkommunikation ist längst kein einzelnes Systemthema mehr, sondern ein Zusammenspiel aus Fachprozessen, Marktrollen, Dienstleistern, Datenqualität und Release-Governance.

Besonders relevant ist der Hinweis, dass bestehende API-Webdienste auf GitHub übertragen wurden und dass in der Konsultationsversion der API-Webdienst zur Ermittlung der Marktlokations-ID in mehrere fachlich getrennte API-Webdienste überführt wurde. Der technische Begriff dafür lautet Entkopplung. Fachlich bedeutet er: Anfrage- und Antwortlogik sollen weniger stark miteinander verklebt sein. Genau darin liegt eine wichtige Lernfrage für Stadtwerke. Wenn Schnittstellen fachlich sauberer getrennt werden, dürfen interne Prozesse nicht länger so organisiert sein, als gäbe es nur einen großen technischen Block, der vom Softwarelieferanten zum Stichtag aktualisiert wird.

MaKo ist nicht nur Formatpflege

Viele Häuser führen Marktkommunikationsänderungen noch immer über eine Liste von Formatständen. Welche MIG-Version gilt? Welches AHB ist anzuwenden? Welche Prüfidentifikatoren ändern sich? Welche Testfälle stellt der Dienstleister bereit? Diese Fragen bleiben notwendig, reichen aber nicht aus. Eine fachliche Änderung an Datenformaten kann Lieferantenwechsel, Messstellenbetrieb, Bilanzierung, Stammdatenprozesse, Abrechnung, Kundenservice und Clearing gleichzeitig berühren. Wird sie nur als IT-Termin behandelt, entstehen die Risiken oft erst im Betrieb: unklare Ablehnungsgründe, uneinheitliche Fehlerklassifikation, manuelle Nacharbeit, lange Klärfälle und ein Kundenservice, der fachlich richtige Antworten suchen muss, während Fristen bereits laufen.

Ein robusterer Ansatz beginnt mit einer MaKo-Release-Akte. Sie beschreibt nicht nur, welche Version einzuspielen ist, sondern welche Fachprozesse betroffen sind, welche Marktrollen im eigenen Haus handeln, welche Dienstleister liefern, welche Testnachweise erwartet werden und welche Fehlerklassen nach dem Go-live beobachtet werden. Für API-Webdienste kommt hinzu: Jede API braucht eine fachliche Zuständigkeit. Wer ist Eigentümer des Anwendungsfalls? Welche Daten dürfen angefragt werden? Welche Antwort ist fachlich vollständig? Welche Fehlermeldung löst welchen Clearingpfad aus? Und wie wird verhindert, dass ein technischer Erfolgscode als fachliche Erledigung missverstanden wird?

Entkopplung braucht Verantwortlichkeit

Die in der Konsultation beschriebene fachliche Trennung von API-Webdiensten ist ein guter Anlass, auch intern zu trennen. Ein Stadtwerk kann eine API-Landschaft nicht sinnvoll betreiben, wenn jedes Problem sofort als Schnittstellenstörung behandelt wird. Manche Fehler sind Stammdatenfehler, andere Berechtigungsfragen, wieder andere Prozessabweichungen oder echte technische Ausfälle. Die erste Aufgabe ist deshalb eine Zuordnungsmatrix: Fachprozess, beteiligte Marktrollen, auslösende Nachricht oder API, erwartete Antwort, mögliche Ablehnung, fachlicher Besitzer, technischer Betreiber und Eskalationsweg.

Diese Matrix muss nicht groß beginnen. Wertvoll ist ein pragmatischer Kern für risikoreiche Fälle: Marktlokations-ID, Stammdatenänderung, Messwertübermittlung, Konfiguration, Abrechnung und Klärfall. Für jeden Fall sollte es mindestens einen Normaltest, einen Negativtest und einen Wiederanlauf-Test geben. Normaltest bedeutet: Der Standardfall läuft fachlich korrekt durch. Negativtest bedeutet: Eine erwartbare Ablehnung wird verständlich, fristgerecht und mit richtiger Zuständigkeit behandelt. Wiederanlauf bedeutet: Nach einer Störung kann der Vorgang ohne doppelte oder widersprüchliche Folgeprozesse fortgesetzt werden.

GitHub-Dokumentation ersetzt keine Betriebsfähigkeit

Dass API-Dokumentation öffentlicher, versionierter und technisch besser nachvollziehbar wird, ist ein Fortschritt. Trotzdem entsteht Betriebsfähigkeit nicht allein durch OpenAPI-Dateien, Repositories oder Visualisierungen. Stadtwerke brauchen eine Übersetzung in ihre eigene Prozesssprache. Eine API kann technisch sauber dokumentiert sein und im eigenen Betrieb dennoch unklar bleiben, wenn niemand definiert hat, welche Organisationseinheit sie fachlich verantwortet, wie Änderungen bewertet werden und welche Mindestnachweise vor dem Einsatz erforderlich sind.

Gerade kleinere und mittlere Stadtwerke sollten deshalb nicht versuchen, jedes Detail selbst tief technisch zu beherrschen. Sie sollten aber die Kontrollpunkte besitzen. Dazu gehören ein Releasekalender, ein Überblick über betroffene Fachprozesse, eine Liste der kritischen Schnittstellen, ein Testprotokoll, ein Clearing-Monitoring nach Produktivsetzung und ein monatlicher Review der wichtigsten Fehlerbilder. Damit wird aus Formatpflege eine lernfähige Routine.

Von der Konsultation zur Handlungsfähigkeit

Die laufende Konsultation ist kein Grund für hektische Umsetzung. Sie ist ein Frühwarnsignal. Wer erst kurz vor dem Umsetzungstermin prüft, welche Systeme, Dienstleister und Fachbereiche betroffen sind, verliert Gestaltungsspielraum. Wer jetzt eine schlanke MaKo-Release-Akte vorbereitet, kann Stellungnahmen, Lieferantenkommunikation, Testplanung und interne Schulung besser verbinden.

Die entscheidende Frage lautet nicht, ob ein Stadtwerk jede technische Spezifikation selbst schreibt. Die Frage lautet, ob es seine Marktkommunikation fachlich führen kann. API-Webdienste, EDIFACT-Versionen und Prüfidentifikatoren sind Bausteine. Aus ihnen wird erst dann ein belastbarer Betrieb, wenn Verantwortlichkeiten, Testfälle, Datenqualität und Clearingroutinen zusammengedacht werden. Genau hier liegt der eigentliche Wert der Konsultation: Sie erinnert daran, dass moderne Marktkommunikation weniger an einzelnen Dateien scheitert als an fehlender Prozessarchitektur.