Hallo lieber Ulf, lieber Philip und liebe interessierte Lage-Hörer:innen,
ich kann euren Analysen und Vorschlägen eurer 7-monatigen Recherche nur in allen Punkten zustimmen. Ein zentraler Aspekt, an dem es aktuell noch scheitert, ist ja wie ihr sehr eindrücklich demonstriert habt das Fehlen von Standards oder eine fehlende Verpflichtung, sie einzuhalten.
Zu dem Thema hatte ich schon nach Hören der ersten Folge eine praktische Idee für ein Produkt, das zur Lösung des Problems einen hohen praktischen Nutzen haben könnte: Eine flexible Software, die das Mapping (= „Zuordnen“) von Daten einer Software zu einer anderen Software für Hersteller und Nutzer so einfach und elegant wie möglich macht. Da eine solche Idee auch im zweiten Teil nicht vorkam, wo es mitunter um Lösungen ging, möchte ich sie hier im Folgenden im Detail erläutern, in der Hoffnung, dass die Idee ggf. die richtigen Leute erreicht und in Betracht gezogen wird.
Motivation
Während ich im Grunde ein sehr großer Fan von offenen Standards bin und euch völlig zustimme, dass wir sie in Deutschland weiter fördern müssen, sehe ich auch die Seite der praktischen Probleme, die Standards gerade im IT-Bereich mit sich bringen. Anforderungen und Wünsche entwickeln sich im Softwarebereich ständig weiter und es ist somit schwierig einen Standard zu definieren, der länger als 1 oder 2 Jahre aktuell ist und alle wichtigen Funktionen abdeckt. Das Weiterentwickeln eines Standards ist zwar möglich, aber geschieht dies zu häufig, ist ein Zoo von miteinander inkompatibler Software die Folge. Gerade das Beispiel mit den E-Mail-Standards SMTP und IMAP, die ihr in der Folge genannt habt, zeigen etwa die Probleme gut auf: Bis heute ist es nicht gelungen, E-Mails flächendeckend abzusichern mit Erweiterungen der E-Mail Standards (Versuche gab es genug: STARTTLS, GPG, PGP, S/MIME, etc.). Und auch modernere Mail-Funktionen wie „Mail morgen früh versenden“ haben es nicht ansatzweise in die Standards hinein geschafft und werden es wohl auch lange nicht tun.
In anderen Worten: Standards sind ein wichtiges Element, um Software unterschiedlicher Hersteller miteinander kompatibel zu machen und eine Basis für Datenaustausch zu haben. Auch ihre ständige Weiterentwicklung ist wichtig (wie etwa im Web mit HTML), damit man mit der Zeit mitgeht. Aber Standards müssen gerade wegen dieser Schwierigkeiten von Natur aus langsam entwickelt und evaluiert werden.
Für eine schnelle Digitalisierung unserer Behörden werden sie alleine also nicht reichen. Es fehlt eine Brückentechnologie, zu deren Nutzung alle Hersteller von Behörden-Software verpflichtet werden, die den Austausch auch ohne spezifische Normen und Standards schon kurzfristig digital ermöglicht. Langfristig wäre eine solche Software auch für schnelle Anpassungen an neue Anforderungen sehr nützlich, ohne den langen Weg von langfristigen Standards zu erfordern, bis diese die schnellen Änderungen dann langfristig ersetzen können.
Lösungsvorschlag
Wir entwickeln eine quelloffene Software, die eine lange Liste von gängigen Datenformaten importieren, intern in eine „normalisierte Form“ überführen und wieder in eine lange List von gängigen Datenformaten exportieren kann. Nennen wir diese Software mal „Data Connector“, oder kurz „DaCon“.
Jede bestehende Behörden-Software bekommt verpflichtend die Anforderung, alle Daten in ein einziges beliebiges der unterstützen langen Liste von Formaten von DaCon exportieren und ein einziges beliebiges der unterstützten Formate importieren zu können. Zusätzlich müssen die Hersteller dokumentieren, welches Format sie unterstützen, die Formate erhalten also alle eine eindeutige DaCon-Kennung. Ziel ist es, die Formate so vielfältig zu unterstützen, dass die Unterstützung für die Hersteller möglichst einfach umzusetzen ist. Das spart Kosten und Zeit.
Nur als winzig kleines Beispiel dafür, was mit „unterstützte Formate“ gemeint ist (hiervon würde es in DaCon natürlich hunderte weitere geben): Ein Datumsformat etwa für ein Geburtsdatum könnte von jeder Software anders gespeichert sein und deshalb in unterschiedlichem Format ohne großen Aufwand exportiert werden können. Etwa: 1999/05/17, oder 1999-05-17, oder 1999/17/05, oder 99-5-17, oder 17.05.1999, oder 17.5.1999, oder 1999-05-17T00:00:00+00:00 (ISO 8601), oder 926899200 (Unix time) und so weiter. Auch könnte jede Software in einer anderen technischen Umgebung umgesetzt sein, die das Format der exportierten Datei selbst je nach Wahl einfacher oder komplexer gestaltet. Einige der gängigen zu unterstützenden Formate wären daher: JSON, XML, CSV, YAML. Wohlgemerkt: Sowohl im Import als auch im Export.
(Fortsetzung folgt … [wg. Zeichenbeschränkung])