In the Code: API für die öffentliche Hand

Warum die Schweiz eine API-Strategie braucht, beschreibt Lukas Kahwe Smith, Entwickler und Partner bei Liip.
 
Aus Sicht der öffentlichen Hand rennt die Privatwirtschaft einem Hype nach dem anderen hinterher. Andersherum schüttelt man den Kopf, dass moderne Entwicklungen verschlafen werden. Beides stimmt, basierend auf den unterschiedlichen Arten wie Erfolg gemessen wird: In der Privatwirtschaft geht es um den grossen Wurf, darum die Konkurrenz für einige Zeit abzuhängen. Bei staatlichen Projekten steht eher im Vordergrund, dass im Nachhinein keine Verschwendung, Vetternwirtschaft oder sonstiges Versagen unterstellt werden kann. Es wird eher der sichere, kleine Erfolg als der risikoreiche Grosserfolg gesucht. Verschwendung entsteht aber nicht nur dann, wenn ein Projekt aufgrund von noch zu wenig etablierten Technologien scheitert, sondern auch, wenn die Ergebnisse nicht den Anforderungen der Gesellschaft, zum Beispiel beim Thema E-Government, genügen.
 
E-Government in der Schweiz
Die öffentliche Hand gibt viel Geld aus für IT, 2015 allein 1,7 Milliarden. Sie plant und überwacht ihre IT-Projekte minutiös und erarbeitet eifrig Standards, Definitionen und detaillierte Anforderungskataloge. Dennoch macht sie viel öfter mit IT-Skandalen von sich reden als mit Leuchtturmprojekten, erfolgreichen Innovationsschritten und wirklich nachhaltigen IT-Investitionen. Gründe für den oft beklagten Mangel an Fortschritt werden viele angeführt, von mangelnder Strategie im Anziehen und Halten digitaler Talente über das Fehlen einer Innovations- und Fehlerkultur bis hin zu grundsätzlichen Argumenten wie der Bremswirkung des Föderalismus. Das mag alles stimmen, und in der Summe scheint eine Beschleunigung von E-Government in der Schweiz ganz einfach unmöglich: zu viele Player, zu umständliche Koordination, komplexe Regulierung, kein Raum für Experimente. Das kann ja nicht klappen?
 
Vom Internet lernen
Nun gibt es immerhin ein erfolgreiches Beispiel: Das Internet. Kaum Koordination, absoluter Minimalkonsens über Standards, unendlich viele Player, überall andere Regulierung – und dennoch geht es voran, wirken all die Umstände beschleunigend statt lähmend.
 
Google machte es vor, fast alle grossen Player folgten: effizientes Arbeiten mit unstrukturierten Informationen in einem Netzwerk schlanker Softwarekomponenten, die über triviale Standards miteinander kommunizieren. Das Gleiche gilt etwa für Amazon, wo jede Geschäftseinheit, jedes Projekt und jedes Produkt seine Fähigkeiten mittels einfachster Web-Schnittstelle – Application Programming Interfaces, kurz APIs – anbieten muss. Meetings zur Abstimmung sind verpönt und werden als Fehlleistungen rapportiert. Schliesslich hätte eine klare, einfache API Diskussionen ja erübrigt.
 
API-Strategie Schweiz
Hier darf, ja muss der Staat vom Internet lernen. Die Schweiz braucht eine API Strategie und strenge Instrumente bei deren Umsetzung! Es gibt extrem viel Potenzial, denn kaum eine Ausschreibung im öffentlichen Sektor fordert eine API. Selbst wenn ein Anbieter eine API liefert, gibt es keinen Prozess, um diesen Baustein bekannt, zugreif- und einbaubar zu machen. Weder verwaltungsintern noch für die breite Öffentlichkeit. Die Dynamik im Bereich Open Data und opendata.swiss liesse sich wahrscheinlich dafür nutzen. Ein Entwicklerportal mit API-Verzeichnis wäre der logische nächste Schritt. Innovation wird beschleunigt, die Wiederverwendbarkeit erhöht und dank eines guten Sortiments an Bausteinen die durchschnittliche Projektgrösse und damit die Kosten und systemischen Risiken reduziert.
 
Ein Beispiel für das Potenzial einer offenen API ist transport.opendata.ch. Was als Hobby-Projekt entstand, wird mittlerweile von Dutzenden von Webseiten und Applikationen genutzt. Hierbei gibt es Nutzer in der Form von Betreibern im öffentlichen Verkehr – wie die Rhätische Bahn – aber auch private Unternehmen – wie die Jungfrau Bahnen. Alles zusammen führt zu einem Schnitt von fast einer halben Millionen Aufrufe pro Tag! Welches Potenzial für die Gesellschaft hier schlummert, hat auch die SBB erkannt und mit opentransportdata.swiss eine offizielle Plattform geschaffen, die eine Echtzeitdaten-API anbietet.
 
Wundermittel API?
Das Spannende an APIs ist im Kern zweierlei: erstens können APIs mit anderen APIs verknüpft werden, um ganz neue Anwendungsmöglichkeiten zu realisieren. Zweitens können APIs zusammengeführt werden, um Meta-APIs zu erstellen.
 
Ein Beispiel für ersteres wäre eine Applikation, welche Daten aus einer Karten- und einer Niederschlagsdaten-API überlagert. Ein Exempel für zweiteres eine Meta-API die diverse regionale APIs für die Meldung von Schlaglöchern zusammenfasst.
 
Während ersteres neue Möglichkeiten bringt, ermöglicht das zweite Szenario die Steigerung von Effizienz. Dabei können Regionen sich von APIs aus anderen Regionen inspirieren lassen. Als Anbieter von IT-Lösungen wird eine API eventuell überregional wahrgenommen, was wiederum die Chance erhöht, durch ein erfolgreiches Projekt ein weiteres in einer anderen Region zu gewinnen. Somit besteht die Chance, dass auch IT Anbieter von APIs profitieren können.
 
Des Weiteren können in der Beschaffung nicht nur die Projektvolumen kleiner werden, Aufträge können auch endlich besser aufgeteilt werden, da die API und das passende Frontend separat ausgeschrieben werden können. Somit haben kleinere, spezialisierte Firmen mehr Chancen und die Herstellerabhängigkeiten nehmen ab. Jede Wette, dass dies zu mehr Innovation führt, schliesslich lässt sich mehr Wagnis eingehen – zum Beispiel bei der Benutzeroberfläche – ohne gleich das ganze Projektbudget zu riskieren.
 
APIs und Standards
Wichtig ist, dass diese APIs wiederverwendbar sind. Dafür muss eine API gut dokumentiert sein. Hier gibt es diverse Standards, die helfen aus einer vorhandenen Codebase eine aktuelle Dokumentation mit minimalem Aufwand zu generieren. Allen voran sind Swagger, RAML und Blueprint zu nennen. Ohne eine Dokumentation sind viele der oben genannten Vorteile nicht erreichbar, daher sollten automatisch generierbare API-Dokumentationen in jedem Anforderungskatalog stehen.
 
Bezüglich Dokumentation sind die gängigsten Formate wie XML und JSON, sowie die darauf basierenden Struktur-Standards HAL, JSON-API und JSON-LD zu nennen. Für Authentifikation sind wohl die relevantesten Standards Oauth und JSON Web Token.
 
Zu einer API Strategie gehört zwingend auch das Thema Devops, welches diverse Subthemen wie Product Management, Development, Continuous Integration, Continuous Deployment und Monitoring zusammenfasst. Neue Nutzer einer API können einen Einfluss auf die Performance haben oder Fehler in der Implementierung aufdecken. Daher ist ein Monitoring unabdingbar, um in einer dezentralen Infrastruktur entsprechende Indikatoren zu erkennen. Des Weiteren bringen neue API-Nutzer, wenn auch nur kleine, Anpassungswünsche. Durch Continuous Integration und Continuous Delivery können entsprechende Anpassungen mit minimalem Aufwand und Risiko schnell in die Produktion übernommen werden.
 
Die Zukunft ist nah
Wie kann das Thema API bei Aufträgen für die öffentliche Hand endlich eine tragende Rolle spielen? Zum einen sollten IT-Anbieter das Thema bei jeder Gelegenheit aufbringen: Bei Vorträgen, in Blogs oder als Frage auf Ausschreibungen. Des Weiteren sollten IT-Anbieter bei der Implementierung von Projekten – sofern möglich – selbstständig ein Auge darauf haben, ob eine API für die Realisierung Sinn macht. Auch wenn dies nicht explizit gefordert ist. Wer weiss, vielleicht generiert sich daraus der nächste Auftrag von alleine, um mit einer kleinen Anpassung noch eine weitere Behörde auf dasselbe System zu bringen? Als letzte Massnahme sollten IT-Anbieter sich dafür einsetzen, eine API-Strategie und als deren Kernkomponente ein API-Verzeichnis der gesamten öffentlichen Hand zu etablieren, damit ein Marktplatz für Schnittstellen zur Schweiz entstehen kann. Nennen wir diese Plattform api.swiss. Machen wir "Government as a platform" zu mehr als einem Schlagwort. Machen wir es einfach. (Lukas Kahwe Smith)