Wann sich Eigenentwicklung lohnt
Nicht jede Anforderung braucht ein eigenes Produkt. Für Standardaufgaben wie Finanzwesen oder Personal ist eine Fachanwendung meist die bessere Wahl. Eigenentwicklung lohnt sich dort, wo Kommunen bisher Lücken zwischen Systemen von Hand schließen:
- Querschnittsdienste, die viele Kanäle nutzen: Benachrichtigungen, Meldungen, Termine, Dokumentenprüfung
- Verbindungen zwischen Fachverfahren, die keine gemeinsame Schnittstelle haben
- Bürgernahe Dienste, bei denen Gestaltung, Barrierefreiheit und Datenschutz besonders wichtig sind
- Dienste, die nach dem Prinzip „Einer für Alle“ auch anderen Kommunen helfen können
Leitplanken für das Entwicklungsteam
Ein Team, das Microservices für eine Verwaltung baut, braucht wenige, aber verbindliche Regeln. Wir schlagen einen Startsatz vor, der sich in der Praxis bewährt hat, und passen ihn mit Ihrem Team an:
| Thema | Leitplanke |
|---|---|
| Schnitt | Ein Service hat eine fachliche Aufgabe und eigene Daten. Andere Services greifen nur über seine API zu, nie direkt auf seine Datenbank. |
| API zuerst | Die Schnittstelle wird als OpenAPI-Beschreibung entworfen und mit den Nutzenden abgestimmt, bevor Code entsteht. |
| Betrieb | Container, Konfiguration über Umgebungsvariablen, Gesundheitsprüfung, strukturierte Logs, wiederholbares Deployment per Pipeline. |
| Qualität | Automatische Tests für die Fachlogik, Barrierefreiheitsprüfung für Oberflächen, Abhängigkeiten werden auf Sicherheitslücken geprüft. |
| Datenschutz | Datensparsamkeit im Datenmodell, Löschfristen im Code statt im Handbuch, keine Drittanbieter im Browser ohne Grund. |
| Offenheit | Quellcode im Besitz der Stadt, offene Lizenz, auf Wunsch auf OpenCoDE veröffentlicht – nach dem Grundsatz „öffentliches Geld, öffentlicher Code“. |
Ein Service von Anfang bis Ende
Wie das konkret aussieht, zeigt unser Mängelmelder. Er ist bewusst als eigenständiger Dienst gebaut, den eine Website, eine App oder ein Fachverfahren gleichermaßen nutzen kann.
Steckbrief: Mängelmelder
Aufgabe: Meldungen annehmen, als Ticket bearbeiten, Meldende benachrichtigen, geprüft veröffentlichen.
Schnittstellen: öffentliche API für Meldungen, Status und Karte; geschützte API für das Bearbeitungs-Dashboard; eigenes Postfach, dessen Eingang ausgewertet wird – Antworten mit Vorgangsnummer landen automatisch im Ticket.
Betrieb: eigener Container, Postausgang mit automatischem Nachholen fehlgeschlagener Mails, Gesundheitsprüfung, Löschfrist für personenbezogene Daten 90 Tage nach Abschluss.
Datenschutz im Entwurf: Veröffentlichung erst nach Prüfung, Fotos ohne Standortdaten, Karte und Adresssuche über den eigenen Server statt über Drittanbieter.
Im Tandem mit Ihrem Team
Für ein neues Entwicklungsteam ist der erste Service der wichtigste. Wir schlagen vor, ihn gemeinsam zu bauen – mit Ihren Entwickler*innen am Steuer und uns daneben:
- Woche 1–2: Anforderung mit dem Fachbereich schärfen, Service schneiden, API entwerfen, Leitplanken festlegen.
- Woche 3–6: Gemeinsame Entwicklung mit Pairing und Code-Reviews, wöchentliche Vorführung beim Fachbereich.
- Woche 7–8: Härtung, Dokumentation, Betriebshandbuch, Übergabe an den IT-Betrieb – mit einer Probe, bei der Ihr Team allein deployt.
Übergabe in den Betrieb
Ein Service ist erst fertig, wenn ihn der Betrieb übernehmen kann, ohne die Entwickler*innen anrufen zu müssen. Dazu gehören:
- Betriebshandbuch: Start, Update, Rücksprung, Sicherung, Wiederherstellung
- Überwachung mit klaren Grenzwerten und Ansprechpersonen
- Datenschutzunterlagen: Verzeichnis der Verarbeitungstätigkeiten, technische und organisatorische Maßnahmen, Löschkonzept
- Erklärung zur Barrierefreiheit für alle Oberflächen