Gute digitale Dienste

Digitale Dienste entstehen selten in einem Zug. Sie entstehen 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. Sie bilden kein Reifegradmodell und keine Norm. Sie eignen sich zur Standortbestimmung, zur Vorbereitung von Vergaben und zur Verständigung zwischen Fachbereich, IT und externen Partnern.

Die Prüfliste nennt Handlungen, die überprüfbar sind. Die Leitfragen dienen dem Gespräch, nicht der Abnahme.

Zwei Hinweise vorab. Erstens gelten die Praktiken nicht unabhängig voneinander. Mehrere stehen in Spannung zueinander, etwa die Forderung nach kleinen Teams und die nach breiter Fachkompetenz. Diese Spannungen werden dort benannt, 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 unabhängig davon, ob der Dienst sich an die Öffentlichkeit oder an Beschäftigte der eigenen Organisation richtet.

Verwaltungshandeln ist rechtlich gebunden. Das Recht legt fest, was ein Dienst leisten muss und welche Angaben er erhebt. Es legt in der Regel nicht fest, wie der Dienst zu bedienen ist, in welcher Reihenfolge er fragt und in welcher Sprache er antwortet. Dieser Spielraum ist der Gegenstand der Gestaltung. Organisatorische Zuständigkeiten sind kein Argument dafür, 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 Verbreitung.
• Erproben Sie Entwürfe möglichst in der Umgebung, in der der Dienst später genutzt wird.
• Dokumentieren Sie Ziele, Bedarfe, Verhaltensweisen und Hemmnisse in einer Form, die spätere Teammitglieder ohne Rückfragen lesen können.
• 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?
• Was waren die Befunde, die Ihre ursprüngliche Annahme widerlegt haben?
• Wo liegt die Dokumentation, und wer hat Zugriff darauf?
• In welchem Abstand erproben Sie mit Personen außerhalb des Teams?

Ein Dienst endet nicht an der Grenze der Anwendung. Menschen wechseln zwischen Formular, Telefon, Schalter, Brief und Anwendung, oft innerhalb eines Vorgangs. Ein technisch gelungener Teilschritt hilft wenig, wenn der vorangehende Schritt eine Wartezeit von sechs Wochen erzeugt.

Betrachten Sie deshalb die Kette der Berührungspunkte, nicht 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 die Zuständigkeit für die Übergänge zwischen Abschnitten. Sie 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 nicht durch Weglassen von Information, sondern 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 jedem Punkt, wo im Ablauf sich die nutzende Person befindet und was noch folgt.
• Halten Sie die anerkannten Anforderungen an Barrierefreiheit ein und prüfen Sie sie 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 über alle Berührungspunkte konsistent, auch über die nicht digitalen.
• Halten Sie einen erreichbaren Hilfeweg vor und messen Sie, welche Fragen dort ankommen.

• Welche Aufgaben soll der Dienst tragen, und welche nicht?
• Ist die Sprache so voraussetzungsarm 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 nicht die Wahl einer Methode, sondern die Fähigkeit, ausgelieferte Software regelmäßig zu ändern.

Halten Sie das Team klein. Klein meint die Zahl der Personen, die täglich Entscheidungen treffen, nicht die Breite der verfügbaren Fachkompetenz. Kapitel 7 beschreibt, welche Kompetenzen erreichbar sein müssen. Sie müssen nicht alle dauerhaft im Team sitzen.

• Liefern Sie eine erste nutzbare Fassung aus, die den Hauptbedarf abdeckt. Ein Zeitraum von etwa drei Monaten ist ein brauchbarer Richtwert, kein Grenzwert.
• Führen Sie Nutzungstests in festem Abstand 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.
• Prüfen Sie Änderungen im Vier-Augen-Prinzip, 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?
• In welchem Abstand ü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. Das schließt iteratives Vorgehen nicht aus. Es verlangt, dass Sie das Verfahren, die Rollen, die Ergebnistypen und die Abnahmekriterien präzise beschreiben statt der einzelnen Funktion. Ziehen Sie die Vergabestelle früh hinzu, nicht erst zur Bekanntmachung. 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 eine Weitergabe und Weiterverwendung möglich bleibt.
• 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?
• In welchem Abstand 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. Daran wird der Dienst gemessen.

Geteilte Verantwortung verlangsamt Entscheidungen und verschiebt sie nach oben. Der Name der Rolle ist zweitrangig. Entscheidend ist die tatsächliche Entscheidungsbefugnis.

• 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 Letzteres 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 welche Zustimmung brauchen.

• 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 bei Ausfall oder Wechsel der Person?

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 in der Regel zuarbeitend. Erreichbar sein müssen sie trotzdem, und zwar von Beginn an und 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 ein, nicht als Prüfinstanz am Ende.
• Beschreiben Sie, wie Wissen im Team verteilt wird, damit Abwesenheit keinen Stillstand erzeugt.

• 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.

Verbreitung in der Privatwirtschaft ist dafür kein hinreichendes Kriterium. Sie sagt etwas über den Arbeitsmarkt aus und 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 eine lokale Entwicklungsumgebung ohne Rückfragen entsteht.
• Bewerten Sie den Pflegezustand jeder Abhängigkeit, bevor Sie sie aufnehmen, und in festem Abstand danach.
• 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 Betriebsaufwand ab und erhöhen zugleich die Bindung. Behandeln Sie das als Abwägung mit dokumentiertem 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.
• Lassen Sie Kapazität an der tatsächlichen Nachfrage ausrichten, nach oben wie nach unten.
• Beschaffen und verwalten Sie Ressourcen über eine Schnittstelle, nicht über Formulare.
• Legen Sie den Verarbeitungsort fest und prüfen Sie ihn gegen die datenschutzrechtlichen Vorgaben, 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 auf Standardhardware ohne besondere Anforderungen an einzelne Bauteile.
• Halten Sie Konfiguration als versionierten Code vor, 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 die Bereitstellung einer zusätzlichen Instanz?
• 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 bestehendes Verhalten beschädigt. Sie ersetzen weder manuelle Prüfung noch fachliche Abnahme. Ihr Nutzen liegt darin, dass sie häufige Auslieferung überhaupt verantwortbar machen.

Automatisierte Auslieferung wirkt in dieselbe Richtung. Wo ein Produktivgang einen halben Tag Handarbeit kostet, wird er selten durchgeführt, und jede Auslieferung enthält 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 festem Abstand 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?
• In welchem Abstand 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 keine Abnahmekriterien am Ende, sondern 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 keine Daten, die für den Zweck nicht erforderlich sind. 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 Verletzung 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.
• Halten Sie die Konfiguration der Produktivumgebung als Code vor, 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 festem Abstand durch Dritte 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?
• In welchem Abstand 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 betrifft den technischen Betrieb und die Nutzung gleichermaßen. Kennzahlen zeigen, wo Probleme liegen. Sie erklären 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. Prüfen Sie vor jeder Veröffentlichung von Kennzahlen, 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.
• Veröffentlichen Sie zentrale Kennzahlen intern und, nach Prüfung, auch öffentlich.
• Halten Sie einen niedrigschwelligen Weg für Fehlermeldungen offen und beantworten Sie diese.
• 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 die maßgeblichen?
• Wie haben sie sich seit dem Start entwickelt?
• Welche mittlere Antwortzeit streben Sie an, und wie verteilen sich die Werte oberhalb davon?
• Welches Volumen haben die häufigsten Vorgänge, und welcher Anteil 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 drei Gegenstände: die Daten des Dienstes, seinen Quellcode und den Entwicklungsprozess. Sie erleichtert Prüfung von außen, senkt die Bindung an einzelne Anbieter und ermöglicht Weiterverwendung.

Voreinstellung heißt nicht Ausnahmslosigkeit. Personenbezogene Daten, sicherheitsrelevante Konfiguration und Betriebsgeheimnisse Dritter bleiben außen vor. Verlangt ist, dass die Zurückhaltung begründet wird und 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. Verbreitet sind Datenlizenz Deutschland Zero 2.0 und Creative Commons Namensnennung 4.0.
• 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 halten Sie die Angabe in Repository, Paketmetadaten und Dokumentation deckungsgleich.
• 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 erreichen Sie Fehlermeldungen aus der Öffentlichkeit, 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?