Eines der zentralen Konzepte der digitalen Trans­formation ist der Aufbau von digital vernetzten, kundenorientierten Geschäftsökosystemen. Dazu gibt es verschiedene Möglichkeiten. Ein besonders profitabler Ansatz ist der Bau einer Plattform, auf der andere Dienstleistungen oder Produkte anbieten zu können, die man aber selbst kontrolliert. Dabei kann die Plattform sowohl ein virtueller Marktplatz als auch ein virtueller Service oder ein physisches Gerät sein, dessen Funktionalitäten durch Software-Applikationen Dritter erweitert werden. Beispiele sind Amazon, Apples App Store und Google Play.  

Open APIs sind ein weniger offensichtliches, zunehmend aber wichtiges, alternatives oder ergänzendes Element für den digitalen Ausbau von Geschäftsökosystemen. Sie ermöglichen ebenfalls innovative Dienstleistungen durch Dritte, die aber von der Gewährung des Zugriffs auf eigene Programme und Daten abhängen. Strategisches Ziel dabei ist, den Wert der eigenen Dienstleistungen für die Kundschaft zu erhöhen.

Was logisch klingt, ist jedoch nicht einfach umzusetzen. Die Probleme sind weniger technischer als organisatorischer Natur. Technisch realisiert man Open APIs häufig über eine zusätzliche Schicht von Microservices, die den Zugriff auf die eigentlich interessanten Microservices steuern. Meist werden zwei solche Zugänge angeboten, der aktuelle und sein Vorgänger, damit externe User Zeit haben, ihre Applikationen an das neue API anzupassen. Organisatorisch muss aber praktisch jeder Service und sogar jedes Datenelement intern lange verhandelt werden, bevor seiner Veröffentlichung zugestimmt wird.

Wie auch bei anderen Themen gibt es also einen globalen Trend mit lokalen Gegenkräften – und die Auswirkungen des Trends sind noch ziemlich unklar. Einfach ist die Situation jedoch im Fall der öffentlichen Verwaltung. Sie steht nicht in einem Konkurrenzverhältnis – zumindest im Grossen und Ganzen –, sondern soll maximalen Gemeinwohlnutzen (Public Value) für das eingesetzte Steuergeld liefern. Deshalb sind alle Verwaltungsleistungen sinnvoll, die nur marginale Kosten für die Verwaltung verursachen, aber konkreten wirtschaftlichen oder gesellschaftlichen Nutzen schaffen. 

Dieser Denklogik folgend hat sich die Schweizer Bundesverwaltung dem Trend zu Open APIs nach mehreren Jahren des Zuwartens nun angeschlossen. Das umfasst nicht nur das Zur-Verfügung-Stellen von Daten für die Sekundärnutzung (Open Government Data), sondern auch den Zugriff auf Fachanwendungen durch Dritte (Open Government Services) – und geht damit sehr weit!

2014 formulierte Jean-François Junger beim Schweizer E-Government-Symposium die Vision des Triple-Open-Government: «Open Data, Open Processes and Open Services». Junger kam von der EU-Kommission und man hörte in Bern eventuell nicht wirklich zu. Stattdessen konzen­trierte man sich auf die «schönen» Aspekte des E-Government. 2017, beim bislang letzten deutschsprachigen Schweizer E-Government-Symposium, zitierte beispielsweise der Luzerner Regierungsrat Marcel Schwerzmann den romantischen Komponisten Anton Bruckner: «Wer hohe Türme bauen will, muss lange beim Fundament verweilen.» Und der Direktor der Eidgenössischen Zollverwaltung, Christian Bock, versprach, man werde im Projekt DazIT «Elefanten tanzen lassen». Beides kam sehr gut an, warf aber die grosse Frage auf: Was ist der konkrete Plan?

Als die EU-Kommission das «Once Only»-Prinzip zusammen mit anderen E-Government-Prinzipien in der Tallinn Declaration festschrieb, handelte Bundesrat Ueli Maurer. Obwohl oder weil damit konkrete Ziele verbunden waren, reiste er 2017 persönlich nach Tallinn zur Unterzeichnung der Deklaration. Das war ein unmissverständliches Zeichen, denn die Schweizer Verwaltung war damals nicht einmal in Sichtweite des «Once Only»-Prinzips. Dieses besagt nämlich, dass Daten maximal einmal von Unternehmen oder den Einwohnerinnen und Einwohnern der öffentlichen Verwaltung geliefert werden müssen. Dabei wird nicht zwischen unterschiedlichen Verwaltungsebenen unterschieden – nicht einmal zwischen landesinterner und ausländischer Verwaltung! Entsprechend kann das «Once Only»-Prinzip nur durch Zusammenarbeit von Ämtern erzielt werden, wobei sowohl innerhalb einer Verwaltungsebene als auch ebenenübergreifend zusammengearbeitet werden muss. Theoretisch müsste sogar international kooperiert werden, damit das «Once Only»-Prinzip realisiert werden kann. Alles Dinge, die 2017 ausserhalb jeder Wahrscheinlichkeit für die Schweizer Verwaltung schienen. Heute kann man sich die Umsetzung dagegen immerhin vorstellen. «Once Only» bleibt fern, aber ist immerhin schon in Sichtweite gerückt.    

Weil die Umsetzung des Prinzips bedeutet, dass wirklich dicke Bretter gebohrt werden müssen, finanzierte die EU-Kommission mehrere Projekte zur Erforschung und Pilotierung möglicher Umsetzungen. Am Large-Scale-Pilot «TOOP» nahm die Schweiz (eigenfinanziert) teil. Das Projekt lieferte Architekturspezifikationen, aber noch keine konkrete Umsetzungsstrategie.

Im Oktober 2020 reichte die Finanzkommission (Berichterstatter Gerhard Andrey, Alex Farinelli und Peter Hegelin) im Nationalrat die Motion «Zukunftsfähige Dateninfrastruktur und Datengovernance in der Bundesverwaltung» ein. Diese schloss an entsprechende Motionen aus dem Jahr 2018 von Beat Vonlanthen im Ständerat und von Franz Grüter im Nationalrat an. Sie wurde auf Vorschlag des Bundesrats angenommen. In der Folge beschloss der Bund eine «API first»-Strategie und die Bundeskanzlei publizierte im Januar 2022 eine API-Architektur-Spezifikation.

Die Motion der Finanzkommission fordert die Schaffung eines Daten-Hubs für einen zentralen, standardisierten Zugang zu den digitalen Daten und Prozessen der gesamten Bundesverwaltung. Damit soll der Datenaustausch zwischen Bund, anderen Verwaltungsebenen, Wirtschaft und Zivilgesellschaft gefördert werden. Es wird dabei explizit auf die Umsetzung des «Once Only»-Prinzips referenziert. Die dafür notwendige Zusammenarbeit soll klar geregelt werden. Zusätzlich soll es einen Um­setzungsplan geben und einmal pro Jahr dem Parlament über die Umsetzungsfortschritte berichtet werden.

Wow! Man staunt, reibt sich die Augen und fragt: Wirklich jetzt? Und die Antwort darauf ist tatsächlich noch nicht klar. Wir haben auf europäischer Ebene wie auf nationaler Schweizer Ebene professionelle Spezifikationen, die sich wie Standards lesen, aber es fehlen konkrete Umsetzungsbeispiele und eine fassbare Beschreibung realistischer Umsetzungen. Anders gesagt: Die Theorie ist geklärt, die Praxis fehlt aber noch. Das heisst auch, die Theorie ist noch nicht validiert. Dies muss jetzt geschehen.

Die Erfahrung im Bereich Standardisierung lehrt uns, dass Standards meist nur dann erfolgreich sind, wenn sie im Entstehungsprozess pilotiert werden. Sun hat es einst exemplarisch mit seinen Java-Micro-Edition-Standards vorgemacht, die EU hat es ebenfalls mit einem Teil ihrer Large-Scale-Pilots demonstriert – beispielsweise mit den STORK-Projekten, die zur eIDAS-Regulierung führten. Doch schon das EU-Beispiel zeigt, dass selbst Pilot­projekte nicht ausreichen, weil erst die praktische Umsetzung im grossen Stil zeigt, was funktioniert und was nicht. Basierend auf einer Evaluation der eIDAS-Regulierung, hat die EU-Kommission mit ihrer «Digital Wallet»-Initiative mittlerweile eine radikale Weiterentwicklung des eIDAS zugrunde liegenden Konzepts eingeleitet.  

Soll der Daten-Hub Wirklichkeit werden, benötigen wir erstens konkrete Nutzungsszenarien (Use Cases) des Daten-Hubs, zweitens Pilotierungen dieser Nutzungsszenarien und drittens eine Umsetzungs-Roadmap mit Evaluationspunkten. Ein Schritt hin zur Erfüllung des ersten Punkts wurde mit der erfolgreichen «Once Only»-Challenge beim Open Legal Lab in Magglingen im März dieses Jahres gemacht. Dabei wurde klar aufgezeigt, wie die Flüsse von Verwaltungsdaten aus Sicht einer Einwohnerin optimiert werden könnten und welche Datenwiederverwendungen dies konkret impliziert. Daraus müssen jetzt genaue Use Cases und spezifische Lösungsdesigns für diese Use Cases abgeleitet werden. Dann kann man zum zweiten Schritt übergehen – der Pilotierung der Use Cases.

Mit den Open APIs würde eine Transformation eingeleitet in Richtung Government as a Platform (GaaP). Die­ses einst von Tim O’Reilly gepushte Konzept hat zahlreiche Dimensionen, doch eine Dimension davon ist eine Plattform, die ein Plug-and-Play-E-Goverment in der Logik von No-Code-Plattformen ermöglicht: Die Verwaltungsämter können ihre Online-Dienstleistung durch Kombination und Konfiguration erstellen, statt sie jeweils selbst zu bauen oder bauen zu lassen – ausgenommen bei eigenen Innovationen, die sie selbst anderen zur Wiederverwendung bereitstellen. Einige digitalen Vorreiter-Unternehmen gehen in diese Richtung – warum also nicht auch die Verwaltung?