Verantwortung internalisieren: Als Verwaltung Software verstehen

Unter diesem Tweet sammelten sich einige Antworten, die mir Anlass sein sollen, einmal unsortierte Gedanken der letzten Monate ein wenig zu ordnen. Die meisten Mitlesenden duerften wissen, dass seit ueber 5 Jahren bei Code for Germany (und vielerorts schon viel laenger, und natuerlich nicht nur in Deutschland) ehrenamtliche oertliche Gruppen der oeffentlichen Verwaltung zeigen, was Open Data bringt. Wie man Daten strukturiert. Worin die Vorteile des Ganzen liegen.

Man koennte also sagen: Dass Open Data nuetzlich ist, das daraus tolle Dinge entstehen, dass das ein anstrebenswerter Zielzustand ist und dass 100% Open Data eigentlich spaetestens seit 4 Jahren Status Quo sein sollte, darueber muss man eigentlich nicht mehr diskutieren.

Und dennoch tut sich die oeffentliche Hand offenkundig an sehr vielen Orten immer noch enorm schwer, dies alles in eine Praxis automatisiert bereitgestellter Offener Daten, passender Beschlussgrundlagen und weitsichtiger Beschaffungspolitik zu giessen. Es beschaemt mich, wenn 2020 immer noch Hackathons als neue Massnahme vorgeschlagen werden. Dazu dachte ich sei auch schon das meiste gesagt, aber ergaenzend sei nochmal auf die vielen vielen Beispiele von Jugend hackt verwiesen, die wirklich nun ueber Jahre und hervorragend zeigen, was sich mit Open Data und einer engagierten Zivilgesellschaft machen laesst. Die Frage ist jetzt doch vielmehr, was die naechsten Schritte sind, um die Ideen der Hackathons in der Verwaltung zu verfestigen.

Witzigerweise zeigte gerade ein eher schiefes Beispiel im weiteren Verlauf der Twitterdiskussion worum es eigentlich geht und wo es hakt:

Der Punkt ist natuerlich, dass Kraftfahrzeuge und Vergaser fertig zu kaufende Produkte sind, die selbst fuer den Einsatz im oeffentlichen Dienst passgenau von der Stange gekauft werden koennen. Fuer Spezialanfertigungen – sagen wir mal, Loeschgruppenfahrzeuge – gibt es jahrzehntelang entwickelte Prozesse, Schirrmeistereien und Fachmenschen, die tatsaechlich wissen, welche Ausruestung und Beladung auf das neue Einsatzfahrzeug kommen soll. Und es gibt in der Tat nicht wenige oeffentliche Einrichtungen (ja, ich spreche hier wieder mit der Feuerwehrbrille), die ihre Fahrzeuge selber warten und pflegen. Warum auch nicht.

Auf einer Wardley-Map fuer Datenfluesse, Prozesse und Entwicklungsketten innerhalb der oeffentlichen Verwaltung stuenden aber neben den vielen Bruechen im System jede Menge Komponenten, die entweder aktuell “Custom built” sind oder sich ueberhaupt erst noch in der “Genesis” befinden. Daten werden vielfach noch haendisch per Excel-Export aus Fachverfahren gekratzt und dann mehr oder weniger bereinigt in irgendein Datenportal geschaufelt.

Ueberhaupt: Datenportale. Oder nein, Datenplattformen. Meine Guete. Das ist das Gegenstueck zur Silver Bullet: Wenn man erstmal die Datenplattform hat, dann… ja was dann? Dann ist der Rauskratzprozess der Daten immer noch haendisch. Und was bringt es, wenn das neue Supersystem theoretisch Zeitreihen abbilden kann, wenn innerhalb der Verwaltung niemand da ist, um im Zweifelsfall mittels eines sehr kleinen Shellscripts eine Echtzeit-Datenquelle auch mit der passenden Senke in der Plattform™ zu verbinden? Oder wenn es – noch schlimmer – immer noch keine Ansaetze von Ratsbeschluessen und Grundsaetzen gibt, dass z.B. auf Grundlage von Vergaben entstehende geeignete Daten auch mittels passender Klauseln zu Open Data gemacht werden? Lucy Chambers nennt sowas Upside-Down-Projects: Es soll eine der oberen Schichten im Stack gebaut werden (vielleicht weil das irgendwo in einem Grant Proposal stand), also wird erstmal die Fassade vor dem Fundament gebaut. Oder die uebermaechtige Wasser-Echtzeit-Verbrauchsanzeige, waehrend das metaphorische Wasser noch haendisch im Eimer ins Haus getragen wird. Im schlimmsten Fall hat man nicht mal nen verdammten Eimer.

Und dann sind wir doch relativ schnell wieder bei der Frage, ob die oeffentliche Hand Code anfassen koennen soll. Meine Ueberzeugung: Ja, das sollte sie unbedingt.

Denn, und da sind wir bei einem Knackpunkt fuer mich: Diese Vermittlerrolle, diese Adapterfunktion – Daten aufbereiten, Dinge scrapen, Prozesse bauen – wird bislang viel zu viel vom Digitalen Ehrenamt in Deutschland aufgefangen. Also von all den Menschen, die jetzt immer wieder und immer noch auf Hackathons eingeladen werden, als haetten sie nicht mittlerweile genug damit zu tun, die Proofs-of-Concept aufrechtzuerhalten, was alles moeglich waere, wenn die oeffentliche Hand zumindest in Grundzuegen selber wuesste, wie Code, Datenstandards und IT-Architekturen aussehen.

Paradebeispiele gibt es genug: kleineanfragen.de als Ein-Personen-Projekt, um zu zeigen, wie man solche Dokumente richtig bereitstellt. Einfach nur ein Proof of Concept, seit September 2014(!) bereit zur schluesselfertigen Uebernahme durch die oeffentliche Hand – und nichts dergleichen ist passiert. Im Gegenteil verlassen sich zunehmend JournalistInnen und ParlamentarierInnen auf ein ehrenamtliches Projekt, dem nun seit ueber fuenf Jahren das „offizielle“ Produkt nicht annaehernd gleichziehen konnte (siehe, siehe, siehe). Oder die ganze Geschichte rund um OParl: Ein Datenstandard fuer Parlamentsinformationssysteme, der nur durch massiven persoenlichen Zeitaufwand Ehrenamtlicher entstehen konnte, und fuer den ich bis heute bei keinem Dienstleister eine schicke Auswertung als Ersatz fuer die meist grottigen Ratsinformationssystem-Oberflaechen buchen kann, selbst wenn ich als Kommune Geld darauf werfen wollen wuerde.

Also nein, Software ist kein Auto. (Manche Vergleiche sind aber absurd. Okay.) Aber wenn dieses Digitalisierungszeug endlich mal gelingen soll – und wenn wir die vielen Ehrenamtlichen, die jahrelang gezeigt haben, wo die Reise hingehen kann, endlich aus der nie gewollten Garantenposition herausloesen wollen – gehoert nach dem Pioneer/Settler/Town-Planner-Muster auch passende Kompetenz in der Verwaltung aufgebaut. Muessen zumindest manche VerwaltungsbeamtInnen auch irgendwann mal Cronjobs und Shellscripts einrichten koennen. Muessen dafuer schnell passende VMs fuer die Verwaltung klickbar sein. Muss statt Innovationstheater mit (natuerlich nicht transferierbaren) Leuchttuermen die marode IT-Basisinfrastruktur in einen brauchbaren Zustand versetzt und kontinuierlich weiter gewartet werden koennen. Nicht unbedingt, weil die oeffentliche Hand alles selber machen koennen sollte. Im Gegenteil, moeglichst viel sollte als Commodity klickbar sein. Dafuer muesste man aber wissen, was es alles gibt, und Technikfolgen abschaetzen koennen. Und dafuer hilft es ungemein, mal ellenbogentief in APIs gewuehlt zu haben.

Davon hoere ich auf den ganzen Schlipstraeger-Digitalisierungsgipfeln aber erstaunlicherweise immer noch erstaunlich wenig.

2 Gedanken zu „Verantwortung internalisieren: Als Verwaltung Software verstehen

  1. Pingback: Verantwortung internalisieren, Software verstehen, Nachtrag 1 | stk

  2. Pingback: Kommunalverwaltungen sollten sich nicht fuer IT-Entwicklung missbrauchen lassen | stk

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert