Umsetzung
Die Geodigitalisierungskomponente realisiert in der technischen Umsetzung folgende Szenarien:
- Bereitstellung Konfiguration
- Config-Frontend
- Config-Service
- Bereitstellung Visualisierungskomponente (Kartenviewer, Geometrieerfassung mit Attributierung)
Der Freistaat Bayern hat sich für die Digitalisierung im Rahmen des Onlinezugangsgesetzes (OZG) zum Ziel gesetzt, Grundstrukturen in Form eines Querschnittsservice zu schaffen, welcher der Digitalisierung diverser Verwaltungsleistungen von Anfang bis Ende dient. Neben Entwicklung der Onlinedienste als Schnittstelle zu Bürger:innen und Unternehmen, besteht die Herausforderung auch die internen Abläufe zu digitalisieren bzw. weiter digital auszubauen.
Für viele OZG-Leistungen erfolgt bereits eine Unterstützung durch Fachverfahren, insbesondere für solche Leistungen, die komplexerer Antragsprozesse bedürfen. Jedoch liegt der Fokus bzw. die Kompetenz oder auch die Umsetzungsmöglichkeit regelmäßig ausschließlich in den notwendigen Fachprozessen. Weitere Prozessoptimierungen oder Usability-Überlegungen werden oder können häufig nicht mitbedacht werden. Gerade die Optimierung oder der generelle Einsatz geeigneter Querschnittskomponenten kann für die Antragsteller aber auch die Antragsbearbeiter in den Verwaltungen deutliche Vorteile ermöglichen. Da hier regelmäßig besonderes Fachwissen notwendig ist, erschien die Bereitstellung einer Geokomponente von Geoexperten für "alle anderen Fachdisziplinen" ein notwendiger Schritt.
Vor dem Hintergrund, dass zahlreiche Antragsprozesse Raumbezug aufweisen, wird mittelfristig eine hohe Nutzung erwartet. Durch das zentrale Angebot werden zudem eine unbestimmte Anzahl von Individuallösungen und vielfache Entwicklungs- und Bereitstellungsaufwände vermieden. Die individuelle Entwicklung einer Geokomponente für einzelne Anträge ist nicht wirtschaftlich.
Neben der funktionalen Entwicklung einer hilfreichen Geokomponente im Umfeld der OZG-Antragsverfahren lagen von Beginn an auch die IT-Sicherheit und Anwendungsperformance im Mittelpunkt des Handelns. Daher sind auch das Landesamt für Sicherheit in der Informationstechnik (LSI) und das IT-Dienstleistungszentrum (IT-DLZ) des Freistaats Bayern fester Bestandteil der Projektstruktur.

Die folgende Grobarchitektur zeigt die Strukturen von Entwicklung, Betrieb und Nutzung in den unterschiedlichen Umgebungen auf.

Arbeitspakete
Zur agilen Umsetzung der Geodigitalisierungskomponente wurden durch die Projektgruppe Releaseplanungen für Entwicklung und Betrieb aufgestellt und regelmäßig fortgeschrieben. Das Entwicklungsteam arbeitet diese in Sprints ab und präsentiert die Ergebnisse im Review.

Weiterentwicklung
Feature-Requests können durch jeden Github-Nutzer angelegt werden. Es existiert eine Vorlage für die Erstellung von Feature-Request. Die Bewertung und Priorisierung von Feature-Requests erfolgt durch den Lenkungsausschuss und das DevOps-Team. Die einzige Quelle für Features zur Weiterentwicklung ist die Issue-Liste des Github Projektes. Auch Mitglieder des Lenkungsausschusses und des DevOps-Teams müssen Feature-Requests anlegen, wenn sie ein neues Feature benötigen. Bei der Erstellung von Feature-Requests ist das Produktmanagement unterstützend tätig.
Die Issues werden über Milestones nach dem Schema Quartal/Jahr (z.B. Q3J2024) geordnet. So wird festgelegt, welche Issues in einem Quartal bearbeitet werden. Zusätzlich zu den Milestones werden Issues mit “Must”, “Should” und “Could” getaggt und so eine Priorisierung der Issues innerhalb einer Milestones hergestellt.

Releases orientieren sich an Feature-Request und Bug-Reports. Für jeden erledigten Bug-Fix bzw. Feature-Request erfolgt das Release einer neuen Version der betroffenen Anwendung. Um ein qualitativ hochwertiges Produkt anbieten zu können, wird vor einem Release ein Release-Candidate aus dem Testing-Branch erzeugt. Dadurch können

Die Bearbeitung von Featuer-Requests und Bug-Reports erfolgt nach dem Gitflow Model, bei dem sich die Änderungen am Code in Feature-Branches abspielen. Weiter Branches sind Dev, Testing und Main, die als Protected Branches konfiguriert sind. Feature-Branches werden regelmäßig in den Dev-Branch gemerged um frühzeitig Konflikte aufdecken zu können. Fertige Feature-Branches werden zuerst in den Testing- und nach erfolgreichen End2End Tests in den Main-Branch integriert.

Während der Entwicklung ist durch automatisch startende Pipelines kontinuierliches Feedback durch Linting, Audit und Testing sichergestellt. Zur Übernahme eines Branches in einen der Protected Branches ist ein erfolgreiches Durchlaufen der Pipelines nötig.
Nach dem erfolgreichen Durchlauf der Pipelines erfolgt ein manueller Review-Prozess durch Maintainer des Projekts und ggf. Feedback zum Pull-Request. Am Ende erfolgt die Integration in das Projekt.
Um sicherzustellen, dass Sicherheitsschwachstellen schnell erkannt werden, kommen automatisierte Scanner sowohl für das Auffinden von Schwachstellen im Code (CodeQL) als auch das Auffinden verwundbarer Abhängigkeiten (Dependabot) zum Einsatz. Findings dieser Scanner werden umgehend bearbeitet. Die Scanner laufen in regelmäßigen Zeitabständen.
Verfügbarkeit
Der Betrieb erfolgt in einer Cloud-Infrastruktur. Dies bringt gerade für diese bundesweit zur Verfügung stehende Querschnittskomponente erhebliche Vorteile und wird als beste Lösung betrachtet. Neben der 24/7/365 Verfügbarkeit (ohne Wartungsfenster) können so auch unterschiedlichste Bedarfe hinsichtlich der Skalierbarkeit (hochverfügbar) abgedeckt werden. Die zentral angebotenen Services (Config-Web-Service und Config-Code-Service, Erläuterung siehe unten) stehen somit für die Nutzer verlässlich und jederzeit zur Verfügung. Die Verfügbarkeitsklassen für EfA-Onlinedienste des Bundesamtes für Sicherheit in der Informationstechnik (BSI) werden jeweils in "Gold" erfüllt.

Künftige Releasewechsel beeinflussen bzw. unterbrechen die bestehende Nutzung nicht; die einmal eingebundene Komponente wird ununterbrochen ausgeliefert. Neue Funktionalitäten können hinzu konfiguriert werden. Die registrierten Nachnutzer erhalten hierzu Informationen.