Gute digitale Dienste

Digitale Dienste entstehen selten in einem Zug, sondern in Schleifen aus Beobachtung, Entwurf, Erprobung und Korrektur. Ein erheblicher Teil öffentlicher IT-Vorhaben verfehlt Termine, Kosten oder den beabsichtigten Nutzen.

Die folgenden Praktiken beschreiben ein Vorgehen, das dieses Risiko senkt. Ein Reifegradmodell oder eine Norm sind sie nicht. Sie helfen aber, den eigenen Standort zu bestimmen, Vergaben vorzubereiten und sich zwischen Fachbereich, IT und externen Partnern zu verständigen.

Die Prüflisten nennen Handlungen, die sich überprüfen lassen. Die Leitfragen sind für das Gespräch gedacht, nicht für die Abnahme.

Zwei Hinweise vorab. Erstens hängen die Praktiken zusammen, und mehrere stehen in Spannung zueinander, etwa die Forderung nach kleinen Teams und die nach breiter Fachkompetenz. Diese Spannungen benenne ich dort, wo sie auftreten. Zweitens ersetzt keine Praktik die Prüfung des rechtlichen Rahmens. Vergaberecht, Datenschutzrecht und Fachrecht setzen Bedingungen, über die nicht verhandelt wird.

Beginnen Sie mit der Aufgabe, die Menschen erledigen wollen, und mit der Situation, in der sie das tun. Das gilt für Dienste, die sich an die Öffentlichkeit richten, ebenso wie für solche für die Beschäftigten der eigenen Organisation.

Verwaltungshandeln ist rechtlich gebunden. Das Recht legt fest, was ein Dienst leisten muss und welche Angaben er erhebt. Offen lässt es in der Regel, wie der Dienst zu bedienen ist, in welcher Reihenfolge er fragt und in welcher Sprache er antwortet. In diesem Spielraum findet Gestaltung statt. Organisatorische Zuständigkeiten sind kein Grund, ihn ungenutzt zu lassen.

• Sprechen Sie vor dem ersten Entwurf mit Personen, die den Dienst nutzen werden oder die Aufgabe heute auf anderem Weg erledigen.
• Kombinieren Sie qualitative und quantitative Verfahren. Interviews erklären Ursachen, Kennzahlen zeigen, wie häufig etwas vorkommt.
• Erproben Sie Entwürfe möglichst in der Umgebung, in der der Dienst später genutzt wird.
• Dokumentieren Sie Ziele, Bedarfe, Verhaltensweisen und Hemmnisse so, dass spätere Teammitglieder sie ohne Rückfragen verstehen.
• Legen Sie die Ergebnisse der Leitungsebene vor, auch die unbequemen.
• Führen Sie eine priorisierte Liste der Aufgaben, die Nutzende erledigen wollen.
• Wiederholen Sie die Erprobung während der gesamten Entwicklung, nicht nur zu Beginn.

• Welche Gruppen nutzen den Dienst, und welche Aufgabe erledigen sie damit?
• Welche Gruppen werden die größten Schwierigkeiten haben, und woran liegt das?
• Welche Erhebungsverfahren haben Sie eingesetzt, und warum diese?
• Welche Befunde haben Ihre ursprüngliche Annahme widerlegt?
• Wo liegt die Dokumentation, und wer hat Zugriff darauf?
• In welchen Abständen erproben Sie den Dienst mit Personen außerhalb des Teams?

Ein Dienst reicht über die Grenze der Anwendung hinaus. Menschen wechseln oft innerhalb eines einzigen Vorgangs zwischen Formular, Telefon, Schalter, Brief und Anwendung. Ein technisch gelungener Teilschritt hilft wenig, wenn der vorangehende Schritt eine Wartezeit von sechs Wochen erzeugt.

Betrachten Sie deshalb die ganze Kette der Berührungspunkte und nicht nur die einzelne Oberfläche. Der digitale Teil sollte an die nicht digitalen Teile anschließen, statt sie zu verdoppeln.

• Erfassen Sie alle Punkte, an denen Menschen mit dem Dienst in Kontakt kommen, online und außerhalb.
• Benennen Sie die Stellen, an denen Vorgänge abbrechen oder Rückfragen entstehen, und ordnen Sie sie nach Häufigkeit und Auswirkung.
• Gestalten Sie die digitalen Teile so, dass sie an bestehende Wege anschließen, etwa an Postversand oder Terminvergabe.
• Legen Sie für jeden Abschnitt fest, woran Sie erkennen, dass er funktioniert.
• Klären Sie, wer für die Übergänge zwischen den Abschnitten zuständig ist. Diese Zuständigkeit fällt erfahrungsgemäß zwischen die Organisationseinheiten.

• Auf welchen Wegen erledigen Menschen die Aufgabe heute?
• An welchen Stellen brechen Vorgänge ab, und was passiert dann?
• Wie ordnet sich das Vorhaben in den vollständigen Ablauf ein?
• Welche Messgrößen zeigen, ob der Ablauf als Ganzes funktioniert und nicht nur der digitale Ausschnitt?

Ein Dienst sollte ohne Vorwissen bedienbar sein. Das ist ein Anspruch an die Gestaltung, keine Zusicherung. Auch ein gut gestalteter Dienst braucht Hilfe für Fälle, die vom Regelfall abweichen, und für Menschen, die Unterstützung benötigen.

Einfachheit entsteht durch Ordnung. Sprache, Reihenfolge und Rückmeldungen tragen dazu mehr bei als die visuelle Oberfläche.

• Arbeiten Sie mit einem knappen, verbindlichen Gestaltungsleitfaden und mit etablierten Webstandards.
• Zeigen Sie an jeder Stelle, wo die nutzende Person im Ablauf steht und was noch folgt.
• Halten Sie die anerkannten Anforderungen an Barrierefreiheit ein und prüfen Sie die Umsetzung mit assistiven Technologien, nicht nur mit Testwerkzeugen.
• Ermöglichen Sie, einen Vorgang zu unterbrechen und später an derselben Stelle fortzusetzen.
• Verwenden Sie die Sprache der Nutzenden, nicht die des Fachrechts. Wo ein Rechtsbegriff nötig ist, erklären Sie ihn an Ort und Stelle.
• Halten Sie Sprache und Gestaltung an allen Berührungspunkten einheitlich, auch an den nicht digitalen.
• Bieten Sie einen erreichbaren Hilfeweg an und messen Sie, welche Fragen dort ankommen.

• Welche Aufgaben soll der Dienst tragen, und welche nicht?
• Ist die Sprache so einfach wie möglich, ohne ungenau zu werden?
• In welchen Sprachen und in welchen Fassungen steht der Dienst zur Verfügung?
• Wie erhalten Menschen Hilfe, und wie lange warten sie darauf?
• Welche Fragen erreichen die Hilfestellen am häufigsten, und was sagt das über die Gestaltung aus?

Kurze Entwicklungsschleifen senken das Risiko, weil sie Fehlannahmen früh sichtbar machen. Entscheidend ist, dass sich ausgelieferte Software regelmäßig ändern lässt.

Halten Sie das Team klein. Klein bezieht sich auf die Zahl der Personen, die täglich Entscheidungen treffen, nicht auf die Breite der verfügbaren Fachkompetenz. Welche Kompetenzen erreichbar sein müssen, beschreibt Kapitel 7. Dauerhaft im Team sitzen müssen sie nicht alle.

• Liefern Sie eine erste nutzbare Fassung aus, die den Hauptbedarf abdeckt. Etwa drei Monate sind dafür ein brauchbarer Richtwert, kein Grenzwert.
• Führen Sie Nutzungstests in festen Abständen durch und leiten Sie daraus die nächsten Arbeitsschritte ab.
• Halten Sie die Zahl der Ebenen zwischen Team und Entscheidung gering.
• Geben Sie Änderungen mehrmals im Monat frei.
• Führen Sie priorisierte Listen für Funktionen und für Fehler.
• Verwenden Sie ein Versionsverwaltungssystem und geben Sie dem gesamten Team Zugriff auf Quellcode und Vorgangsverwaltung.
• Lassen Sie Änderungen von einer zweiten Person prüfen, bevor sie zusammengeführt werden.

• Wann wurde die erste nutzbare Fassung ausgeliefert, und was hat sie verzögert?
• Wie lange dauert eine Auslieferung in die Produktivumgebung, von der Freigabe bis zur Verfügbarkeit?
• Wie lang ist eine Iteration?
• Womit verwalten Sie Quellcode, Fehler und Anforderungen?
• Wie oft überprüfen Sie die Priorisierung?
• Wie gelangt Rückmeldung aus der Nutzung in die Entwicklung, und wie lange braucht sie dafür?
• Welche Lücken haben die letzten Nutzungstests gezeigt?

Verträge bestimmen, wie viel Anpassung während der Laufzeit möglich ist. Ein Vertrag, der Funktionen abschließend auflistet, verhindert genau die Korrekturen, die iteratives Vorgehen erst nützlich machen.

Das Vergaberecht verlangt eine Leistungsbeschreibung, die eindeutig und erschöpfend ist. Iteratives Vorgehen ist damit vereinbar. Beschreiben Sie dann statt der einzelnen Funktionen präzise das Verfahren, die Rollen, die Ergebnistypen und die Abnahmekriterien. Ziehen Sie die Vergabestelle früh hinzu, nicht erst zur Bekanntmachung, und prüfen Sie, welche etablierten Vertragsmuster für agile Vorhaben zur Verfügung stehen.

• Sehen Sie Mittel für Recherche, Erkundung und Prototyping vor, getrennt von den Mitteln für die Umsetzung.
• Vereinbaren Sie häufige, überprüfbare Lieferungen statt weniger großer Meilensteine.
• Legen Sie fest, woran Lieferqualität gemessen wird, und knüpfen Sie die Vergütung daran.
• Sichern Sie sich das Recht, die Reihenfolge der Umsetzung innerhalb des beschriebenen Rahmens zu ändern.
• Verlangen Sie, dass quelloffene Software bei der Technologieauswahl geprüft und die Gründe der Entscheidung dokumentiert werden.
• Regeln Sie Rechte an Quellcode, Konfiguration, Daten und Dokumentation so, dass Weitergabe und Weiterverwendung möglich bleiben.
• Vereinbaren Sie Abrechnungsmodelle, die zum Nutzungsverlauf passen, einschließlich verbrauchsabhängiger Modelle.
• Vereinbaren Sie eine Gewährleistungsfrist und einen Übergabeplan mit benannten Artefakten, nicht nur mit einem Termin.

• Was ist Gegenstand des Vertrags, und was sind die Lieferergebnisse?
• Wie oft wird geliefert, und was genau wird abgenommen?
• Welche Leistungskennzahlen sind vereinbart, etwa Reaktionszeit, Verfügbarkeit und Behebungsfristen?
• Was passiert mit Quellcode, Daten und Betriebswissen, wenn der Vertrag endet?
• Wer entscheidet über Änderungen der Reihenfolge, und in welcher Frist?

Es braucht eine Person, die über Funktionen und technische Umsetzung entscheidet und für das Ergebnis einsteht. Diese Person verantwortet, ob der Dienst den ermittelten Bedarf deckt, und daran wird er gemessen.

Geteilte Verantwortung verlangsamt Entscheidungen und verschiebt sie nach oben. Wie die Rolle heißt, ist zweitrangig. Entscheidend ist, ob sie tatsächlich entscheiden darf.

• Benennen Sie eine produktverantwortliche Person schriftlich.
• Bestätigen Sie im Kreis der Beteiligten, dass diese Person über Funktionen und Umsetzungsdetails entscheidet.
• Achten Sie auf ein Profil, das fachliche Steuerung und technisches Urteilsvermögen verbindet. Ohne technisches Urteilsvermögen lassen sich Alternativen nicht abwägen.
• Statten Sie die Rolle mit einem Arbeitsplan aus, der Mittelbedarf und Finanzierungsquellen ausweist.
• Sorgen Sie für einen kurzen Weg zur Vergabestelle und zur Leitungsebene.
• Halten Sie fest, welche Entscheidungen die Rolle allein trifft und für welche sie eine Zustimmung braucht.

• Wer trägt die Produktverantwortung, und seit wann?
• Welche organisatorischen Änderungen waren nötig, um die Rolle handlungsfähig zu machen?
• Welche Schritte sind erforderlich, um eine Funktion aufzunehmen oder zu streichen, und wie lange dauern sie?
• Was geschieht, wenn die Person ausfällt oder wechselt?

Digitale Dienste brauchen Menschen, die vergleichbare Dienste bereits gebaut und betrieben haben. Das gilt für die Steuerung ebenso wie für Entwicklung und Gestaltung.

Nicht jede Kompetenz muss dauerhaft im Team vorhanden sein. Sicherheit, Datenschutz und Recht arbeiten dem Team in der Regel zu. Erreichbar sein müssen sie trotzdem, und zwar von Beginn an, nicht erst zur Abnahme. Wo externe Unterstützung nötig ist, brauchen Sie eine Vergabestelle, die technische Eignung beurteilen kann.

• Achten Sie auf Erfahrung mit Diensten, die tatsächlich in Betrieb gegangen sind und Last getragen haben.
• Stellen Sie sicher, dass Erfahrung mit Web- und mobilen Anwendungen im Team vorhanden ist.
• Stellen Sie sicher, dass automatisierte Testverfahren beherrscht werden.
• Stellen Sie sicher, dass Erfahrung mit fortlaufender Integration und Auslieferung vorhanden ist.
• Binden Sie Sicherheitskompetenz ein, bevor der Entwurf feststeht.
• Binden Sie die zuständigen Personen für Datenschutz und Recht als Partner*innen ein, nicht als Prüfinstanz am Ende.
• Beschreiben Sie, wie Wissen im Team verteilt wird, damit die Arbeit auch bei Abwesenheit weiterläuft.

• Welche vergleichbaren Dienste hat das Team bereits ausgeliefert und betrieben?
• Welche Kompetenzen liegen im Team, welche im Netzwerk, und wie schnell sind Letztere erreichbar?
• Wie lange braucht ein neues Teammitglied bis zum ersten produktiven Beitrag?
• Wie beurteilen Sie die technische Eignung von Anbietern, und wer tut das?

Technologieentscheidungen binden langfristig. Sie bestimmen, wer den Dienst weiterentwickeln kann, wie schnell das geht und was ein Wechsel kostet.

Dass eine Technologie in der Privatwirtschaft verbreitet ist, reicht als Kriterium nicht aus. Es sagt etwas über den Arbeitsmarkt aus, aber wenig über Eignung, Betriebsdauer und Ablösbarkeit. Entscheiden Sie stattdessen anhand von Merkmalen, die sich prüfen lassen: Verfügbarkeit von Kompetenz, Pflegezustand und Erscheinungsrhythmus, Qualität der Dokumentation, offene Schnittstellen, Lizenz und die Frage, wie eine Ablösung aussähe.

• Halten Sie für jede wesentliche Entscheidung fest, welche Alternativen geprüft wurden und woran die Wahl hing.
• Prüfen Sie quelloffene Software auf jeder Ebene des Technologiestapels.
• Bevorzugen Sie Komponenten mit offenen, dokumentierten Schnittstellen und exportierbaren Datenformaten.
• Stellen Sie sicher, dass sich die Software auf gängiger Hardware und bei mehreren Anbietern betreiben lässt.
• Halten Sie eine Anleitung bereit, mit der sich eine lokale Entwicklungsumgebung ohne Rückfragen einrichten lässt.
• Bewerten Sie den Pflegezustand jeder Abhängigkeit, bevor Sie sie aufnehmen, und danach in festen Abständen.
• Beschreiben Sie für jede Bindung an einen Anbieter, wie eine Ablösung ablaufen würde und was sie ungefähr kostet.

• Aus welchen Bestandteilen besteht der Technologiestapel, und warum?
• Welche Datenhaltung nutzen Sie, und welche Anforderungen hat sie erfüllt?
• Welche Abhängigkeiten wären bei einem Anbieterwechsel neu zu bauen?
• Wie lange braucht ein neues Teammitglied bis zur ersten lauffähigen Umgebung?

Dienste sollten auf einer Infrastruktur laufen, die Lastspitzen ohne Vorlauf trägt. Wo Kapazität manuell beschafft und eingebaut wird, entstehen Wartezeiten, die den Entwicklungsrhythmus begrenzen.

Anpassungsfähigkeit und Anbieterunabhängigkeit ziehen in unterschiedliche Richtungen. Verwaltete Dienste nehmen Ihnen Betriebsaufwand ab, binden Sie aber zugleich stärker an den Anbieter. Behandeln Sie das als Abwägung und dokumentieren Sie das Ergebnis. Prüfen Sie dabei den Ort der Verarbeitung, die Rechtsgrundlage der Auftragsverarbeitung, den Zugriff durch Dritte und die Frage, ob sich der Betrieb ohne Neuentwicklung verlagern lässt.

• Stellen Sie Kapazität bedarfsabhängig bereit, ohne manuelle Beschaffungsschritte.
• Richten Sie die Kapazität an der tatsächlichen Nachfrage aus, nach oben wie nach unten.
• Beschaffen und verwalten Sie Ressourcen über eine Schnittstelle, nicht über Formulare.
• Legen Sie den Verarbeitungsort fest und gleichen Sie ihn mit den datenschutzrechtlichen Vorgaben ab, bevor Sie Regionen zuschalten.
• Rechnen Sie nach tatsächlichem Verbrauch ab, wo das für den Lastverlauf günstiger ist.
• Liefern Sie unveränderliche Inhalte über ein Auslieferungsnetz aus.
• Betreiben Sie den Dienst auf Standardhardware ohne besondere Anforderungen an einzelne Bauteile.
• Legen Sie die Konfiguration als versionierten Code ab, damit sich die Umgebung nachbauen lässt.

• Wo läuft der Dienst, und wer verarbeitet dabei welche Daten?
• Wie verhält sich der Dienst bei einem Vielfachen der üblichen Last?
• Wie lange dauert es, eine zusätzliche Instanz bereitzustellen?
• Wie rechnet der Betrieb ab, und wie verhält sich das zum Lastverlauf?
• Läuft der Dienst in mehreren Zonen, und was spricht dafür oder dagegen?
• Wie lange dauert die Wiederherstellung nach einem Ausfall des Rechenzentrums, und wurde das erprobt?
• Welche Datenredundanz besteht, und welche Folgen hätte ein vollständiger Datenverlust?
• Wie oft müssen Sie den Betreiber kontaktieren, um ein Problem zu lösen?

Automatisierte Tests senken das Risiko, dass eine Änderung etwas beschädigt, das bisher funktioniert hat. Sie ersetzen weder manuelle Prüfung noch fachliche Abnahme. Ihr Nutzen liegt darin, dass sie häufige Auslieferung erst verantwortbar machen.

Automatisierte Auslieferung wirkt in dieselbe Richtung. Wo ein Produktivgang einen halben Tag Handarbeit kostet, findet er selten statt, und jede Auslieferung bündelt entsprechend viele Änderungen.

• Decken Sie die zentralen Abläufe der Nutzung mit automatisierten Tests ab.
• Ergänzen Sie Integrationstests für das Zusammenspiel der Komponenten.
• Führen Sie die Tests bei jedem Bauvorgang aus und brechen Sie den Vorgang bei Fehlern ab.
• Automatisieren Sie die Auslieferung, einschließlich der Rücknahme einer fehlerhaften Fassung.
• Führen Sie Last- und Leistungstests in festen Abständen durch, mindestens vor dem öffentlichen Start.
• Halten Sie fest, welche Bereiche bewusst nicht automatisiert getestet werden und warum.

• Welche Abläufe sind abgedeckt, und welche nicht?
• Wie lange dauert es von der Fehlermeldung bis zur behobenen Fassung in Produktion?
• Wie lange dauert dasselbe für eine neue Funktion?
• Wie oft laufen Bauvorgänge?
• Welche Werkzeuge nutzen Sie für Test, Integration und Auslieferung?
• Wie viele gleichzeitige Zugriffe hat das System im letzten Test getragen?
• Wie verhält sich der Dienst oberhalb dieser Grenze?

Sicherheit und Datenschutz sind eine fortlaufende Aufgabe. Klären Sie zu Beginn jeder größeren Änderung, welche Daten erhoben werden, wozu, wie lange sie bleiben und wer sie sieht.

Wiederverwendung senkt den Aufwand. Komponenten, die einmal geprüft und freigegeben wurden, lassen sich in weiteren Diensten einsetzen, ohne die Prüfung zu wiederholen. Das setzt voraus, dass Prüfergebnisse dokumentiert, versioniert und auffindbar sind.

• Bestimmen Sie gemeinsam mit der zuständigen Stelle für Datenschutz, welche Daten erhoben werden, warum, wie sie gespeichert und gesichert werden und wann sie gelöscht werden.
• Erheben Sie nur Daten, die für den Zweck erforderlich sind, und prüfen Sie diese Frage bei jeder neuen Funktion erneut.
• Klären Sie, wie Nutzende über die Verarbeitung informiert werden und wie sie im Fall einer Datenschutzverletzung benachrichtigt werden.
• Klären Sie, wie Nutzende ihre Daten einsehen, berichtigen und löschen lassen können, und setzen Sie das um.
• Führen Sie ein Verzeichnis geprüfter, wiederverwendbarer Komponenten mit Freigabestand und Gültigkeit.
• Legen Sie die Konfiguration der Produktivumgebung als Code ab, damit sie nachvollziehbar und wiederherstellbar bleibt.
• Richten Sie einen öffentlichen Meldeweg für Sicherheitslücken ein und beschreiben Sie, wie Sie darauf reagieren.
• Lassen Sie den Dienst in festen Abständen von Dritten prüfen.

• Welche personenbezogenen Daten verarbeitet der Dienst, und auf welcher Rechtsgrundlage?
• Erhebt der Dienst mehr, als er benötigt? Woran haben Sie das geprüft?
• Lassen sich die Daten in einer Weise verwenden, mit der Nutzende nicht rechnen?
• Werden Daten an weitere Stellen übermittelt, und an welche?
• Wie oft und mit welchen Verfahren prüfen Sie auf Schwachstellen?
• Wie meldet eine außenstehende Person ein Sicherheitsproblem, und wie schnell erhält sie Antwort?

Messen Sie in jeder Phase, wie gut der Dienst funktioniert. Das gilt für den technischen Betrieb ebenso wie für die Nutzung. Kennzahlen zeigen, wo Probleme liegen, aber nicht, warum. Für die Erklärung brauchen Sie die Verfahren aus Kapitel 1.

Ergänzen Sie die Messung um einen Rückmeldeweg, über den Menschen Probleme direkt melden können. Bevor Sie Kennzahlen veröffentlichen, prüfen Sie, ob sich daraus Rückschlüsse auf einzelne Personen oder auf Sicherheitseigenschaften ziehen lassen.

• Überwachen Sie Auslastung und Leistung des Systems fortlaufend, einschließlich Antwortzeit, Durchsatz und Fehlerquote.
• Richten Sie Alarme ein, die an eine benannte Bereitschaft gehen.
• Erheben Sie Nutzungsverhalten in aggregierter Form und in dem Umfang, der für die Verbesserung nötig ist.
• Machen Sie zentrale Kennzahlen intern zugänglich und, nach Prüfung, auch öffentlich.
• Halten Sie einen niedrigschwelligen Weg für Fehlermeldungen offen und beantworten Sie die Meldungen.
• Legen Sie für Vergleichstests vorab fest, welche Änderungen zulässig sind. Bei Diensten, auf die ein Rechtsanspruch besteht, dürfen sich Varianten nicht auf das Ergebnis auswirken.
• Halten Sie nach Störungen eine Auswertung fest, die Ursachen benennt und Maßnahmen ableitet.

• Welche Kennzahlen sind für diesen Dienst maßgeblich?
• Wie haben sie sich seit dem Start entwickelt?
• Welche mittlere Antwortzeit streben Sie an, und wie verteilen sich die Werte oberhalb davon?
• Wie oft kommen die häufigsten Vorgänge vor, und welcher Anteil davon wird abgeschlossen?
• Wie hoch ist die Verfügbarkeit, mit und ohne geplante Wartung?
• Wie erreicht ein Alarm die zuständige Person, und in welcher Zeit?
• Wie messen Sie Zufriedenheit, und wie belastbar ist dieses Verfahren?

Offenheit betrifft dreierlei: die Daten des Dienstes, seinen Quellcode und den Entwicklungsprozess. Sie erleichtert die Prüfung von außen, senkt die Bindung an einzelne Anbieter und ermöglicht Weiterverwendung.

Eine Voreinstellung lässt Ausnahmen zu. Personenbezogene Daten, sicherheitsrelevante Konfiguration und Betriebsgeheimnisse Dritter bleiben außen vor. Begründet wird aber die Zurückhaltung, nicht die Offenlegung.

• Stellen Sie Datensätze vollständig bereit, sowohl als Gesamtabzug als auch über eine Schnittstelle.
• Versehen Sie Daten mit einer offenen, international wirksamen Lizenz und nennen Sie diese eindeutig an einer Stelle. International verbreitet sind CC0 und Creative Commons Namensnennung 4.0. Deutsche Verwaltungen nutzen daneben die Datenlizenz Deutschland Zero 2.0, die national gilt.
• Nehmen Sie öffentliche Datensätze in das behördliche Datenverzeichnis und in das einschlägige offene Datenportal auf.
• Sichern Sie sich vertraglich die Rechte an eigens erstellter Software, damit eine Veröffentlichung möglich bleibt.
• Veröffentlichen Sie Quellcode unter einer anerkannten Open-Source-Lizenz und sorgen Sie dafür, dass die Lizenzangabe in Repository, Paketmetadaten und Dokumentation übereinstimmt.
• Bieten Sie eine dokumentierte Schnittstelle an, wenn Dritte den Dienst einbinden sollen.
• Machen Sie Vorgehen und Stand der Arbeit öffentlich sichtbar, soweit das ohne Risiko möglich ist.
• Halten Sie einen Meldeweg für Fehler offen und reagieren Sie nachvollziehbar darauf.
• Begründen und dokumentieren Sie jede Entscheidung gegen eine Veröffentlichung.

• Wie gelangen Fehlermeldungen aus der Öffentlichkeit zu Ihnen, und wie beantworten Sie sie?
• Welche Schnittstelle besteht, wer nutzt sie, und wo ist sie dokumentiert?
• Unter welcher Lizenz stehen Daten und Quellcode, und stimmen alle Angaben überein?
• Falls der Quellcode nicht offen ist: Worauf stützt sich diese Entscheidung?
• Welche Bestandteile sind bereits offen verfügbar, und welche sollen folgen?