Kürzlich habe ich mit ein paar Technikfreunden zu Abend gegessen, und im Gespräch kamen wir auf die neue Richtlinie zu Daten als Produktionsfaktor. Einer der Freunde arbeitet als Backend-Entwickler in einem E-Commerce-Unternehmen, und ein Satz von ihm hat sich mir besonders eingeprägt: „Die Schnittstellendaten, die in unseren Systemen laufen, sind wie ein U-Bahnhof zur Hauptverkehrszeit – es sieht so aus, als wäre alles in Bewegung, aber in Wirklichkeit ist es ein einziges Chaos.“
Das klingt rau, ist aber nicht falsch. Nach Inkrafttreten der neuen Richtlinie werden Daten offiziell als Produktionsfaktor verwaltet. Was bedeutet das? Es bedeutet, dass all die Daten, die früher einfach in Datenbanken, Logdateien oder sogar auf dem Desktop eines Kollegen abgelegt wurden, jetzt eine ordentliche Identität brauchen. Besonders bei Schnittstellendaten haben viele Unternehmen nie wirklich den Durchblick gehabt.
Was sind Schnittstellendaten? Einfach gesagt: das, was zwischen Systemen übertragen wird. Wenn du zum Beispiel eine Bestellung aufgibst, muss das Bestellsystem dem Lagersystem sagen, dass Bestand abgezogen werden soll, dem Zahlungssystem, dass Geld eingezogen werden soll, und dem Logistiksystem, dass der Versand vorbereitet werden soll. Bei jeder Übertragung entsteht eine Menge JSON-formatierter Daten. Das sieht recht ordentlich aus: geschweifte Klammern in geschweiften Klammern, Schlüssel-Wert-Paare sauber angeordnet. Das Problem ist aber, dass zu viele Leute Schnittstellen schreiben, jeder einen anderen Stil hat, und mit der Zeit wird alles chaotisch.
Ich habe den absurdesten Fall gesehen: In dem JSON, das eine Benutzerschnittstelle eines Unternehmens zurückgab, hieß die Benutzer-ID manchmal „uid“, manchmal „userId“ und manchmal „user_id“. Die Frontend-Entwickler mussten bei jeder Anbindung erst die Dokumentation durchsuchen, danach ausprobieren, und dann feststellen, dass die Dokumentation nicht mit der tatsächlichen Rückgabe übereinstimmte. Ganz zu schweigen von Strukturen mit sieben oder acht Verschachtelungsebenen – wenn man das öffnet, wird einem ganz schwindelig.
Genau hier kommen JSON-Formatierungswerkzeuge ins Spiel. Unterschätze diese Funktion nicht. Viele denken: „Na und? Man klappt doch nur eine komprimierte einzelne JSON-Zeile in mehrere eingerückte Zeilen auf. Was soll daran technisch anspruchsvoll sein?“ Aber wer wirklich praktisch gearbeitet hat, weiß, wie viel Aufwand ein gutes Formatierungswerkzeug spart. Es kann die wirren Hierarchiebeziehungen klären und dir auf einen Blick zeigen, welches Feld in welchem Objekt liegt und welches Array welche Eigenschaften enthält. Besonders beim Debuggen von Schnittstellen sind die Zustände vor und nach der Formatierung zwei völlig verschiedene Welten.
Die neue Richtlinie verlangt, dass Daten verwaltbar, nachverfolgbar und bewertbar sein müssen. Wenn du nicht einmal erkennen kannst, wie deine Schnittstellendaten aussehen, wie willst du sie dann verwalten? Wie willst du sie nachverfolgen? Deshalb ist der erste Schritt, Daten lesbar zu machen. Genau das macht die JSON-Formatierung: Sie verwandelt Dinge, die Maschinen lesen können, aber für Menschen mühsam zu lesen sind, in eine Form, die auch Menschen leicht verstehen können. Das ist keine besonders tiefgehende Technologie, aber es ist der Ausgangspunkt aller Daten-Governance-Arbeit.
Mein E-Commerce-Freund hat später in seiner Firma eine Regel eingeführt: Jede Schnittstellendokumentation muss ein formatiertes JSON-Beispiel enthalten, und vor dem Commit des Codes muss die Rückgabestruktur mit einem Formatierungswerkzeug geprüft werden. Anfangs fanden alle es lästig, später stellten sie fest, dass sich die Abstimmungszeit halbiert hatte, und niemand beschwerte sich mehr. Siehst du, manchmal ist es gar nicht so kompliziert, Daten gut zu verwalten – es beginnt damit, ein Formatierungswerkzeug richtig einzusetzen.