0.1 Umsetzung der technischen, organisatorischen und lizenzrechtlichen Vorgaben
Die Umsetzung der Lose 1 (Middleware) und 3 (DMS Frontend) erfolgt unter konsequenter Beachtung der in Anlage 3, Kapitel 4 formulierten gemeinsamen Anforderungen der BayernCloud Tourismus (BCT) sowie der spezifischen Leistungsbeschreibungen für Los 1 (Anlage 3a) und Los 3 (Anlage 3c). Ziel ist eine modulare, offene und hochverfügbare Plattform, die sowohl den aktuellen als auch zukünftigen funktionalen und nicht-funktionalen Anforderungen gerecht wird.
Modularität
Die Umsetzung der Lose 1 (Middleware) und 3 (DMS-Frontend) erfolgt entlang eines strikt serviceorientierten Architekturprinzips. Beide Komponenten sind als eigenständige, containerisierte Services (Docker/Kubernetes) konzipiert, die ausschließlich über klar definierte, versionierte REST-APIs nach OpenAPI-Spezifikation kommunizieren. Die Trennung von Zuständigkeiten ist durchgängig: Während die Middleware (Los 1) als performante, read-only API-Schicht agiert, liegt der Fokus des DMS-Frontends (Los 3) auf Datenpflege, Dublettenmanagement und visueller Qualitätssicherung. Ein Headless-Ansatz im Frontend sorgt dafür, dass sämtliche Dateninteraktionen ausschließlich über APIs ablaufen, wodurch eine lockere Kopplung gewährleistet ist und direkte Datenbankzugriffe konsequent vermieden werden.
Zugleich ist die Architektur so gestaltet, dass die Übergaben zwischen den Losen sauber dokumentiert und wartbar sind - ein Aspekt, der auch in den übergreifenden Anforderungen der Ausschreibung betont wird. Die Middleware übernimmt u. a. konfigurierbare Filterlogiken, die über das DMS-Frontend gepflegt werden (Los 3), und kann damit nahtlos in Visualisierungsszenarien (Los 4 Widgets) eingebunden werden. Ebenso ist sichergestellt, dass Daten aus Los 2 über API-gesteuerte Schnittstellen in die Middleware eingebunden werden können. Für Änderungs- und Benachrichtigungsprozesse ist ein event-getriebenes Modell via Kafka vorgesehen. So bleibt das Gesamtsystem trotz verteilter Zuständigkeiten robust, skalierbar und zukunftssicher.
Open-Source-Strategie
Der gesamte Quellcode beider Lose wird unter der Apache-2.0-Lizenz bereitgestellt. Die Entwicklung erfolgt dabei in einem öffentlich zugänglichen GitHub-Repository, wodurch eine transparente Nachvollziehbarkeit der Architekturentscheidungen, Schnittstellen und Codeänderungen sichergestellt ist. Zum Einsatz kommen ausschließlich etablierte Open-Source-Komponenten wie Spring Boot, Keycloak, Next.js, React und Tailwind CSS. Sämtliche Schnittstellen werden OpenAPI-konform dokumentiert, um externe Integrationen zu erleichtern und vendor lock-in zu vermeiden.
Generische, wiederverwendbare Module - etwa API-Adapter oder Filter-Komponenten - können in Abstimmung mit dem Auftraggeber zur Weiterentwicklung der BCT-Open-Source-Basis beitragen. So leisten wir nicht nur einen konkreten Projektbeitrag, sondern stärken auch die Nachhaltigkeit und Offenheit der gesamten Plattforminfrastruktur.
Datenschutz
Die Umsetzung beider Lose erfolgt unter strikter Beachtung der DSGVO-Anforderungen. Das Hosting wird ausschließlich in Deutschland oder in EU-Mitgliedsstaaten mit angemessenem Datenschutzniveau realisiert. Alle Datenübertragungen erfolgen verschlüsselt über TLS 1.2 oder höher, sensible Informationen wie Tokens oder personenbezogene Daten werden zusätzlich im Ruhezustand verschlüsselt gespeichert. Für das DMS-Frontend (Los 3) kommt ein rollenbasiertes Zugriffsmodell mit feingranularer Rechtevergabe zum Einsatz, das eine sichere und differenzierte Steuerung der Datenzugriffe ermöglicht.
Zugriffe und Änderungen an Daten werden lückenlos protokolliert und stehen dem Auftraggeber bei Bedarf vollständig zur Verfügung - eine zentrale Voraussetzung für Auditierbarkeit und Transparenz. Die Verarbeitung personenbezogener Daten erfolgt streng nach dem Prinzip der Datenminimierung: Es werden nur solche Daten erhoben und gespeichert, die technisch zwingend erforderlich sind. Zudem sind Funktionen zur Löschung und Anonymisierung vorgesehen, um eine datenschutzkonforme Nutzung über den gesamten Lebenszyklus hinweg zu gewährleisten.
Performance
Für beide Lose ist eine performante und hochverfügbare Architektur zentraler Bestandteil der Umsetzung. Die Middleware (Los 1) setzt auf ein serverseitig optimiertes Caching-Layer für häufig abgefragte Inhalte sowie auf leistungsfähige Geo- und Attributfilter, die bei Bedarf durch eine ElasticSearch-Integration unterstützt werden. Die gesamte Infrastruktur ist skalierbar ausgelegt und umfasst Loadbalancing- sowie Failover-Mechanismen, um einen stabilen Betrieb auch unter Last sicherzustellen.
Im DMS-Frontend (Los 3) sorgen Lazy Loading, clientseitiges Caching und optimierte API-Zugriffe - etwa durch Pagination und gezielte Feldselektion - für eine schnelle und reaktionsstarke Nutzeroberfläche. Ergänzend wird ein zentrales Monitoring etabliert, das Metriken wie Antwortzeiten, Fehlerquoten und Systemauslastung kontinuierlich überwacht. Bei Auffälligkeiten erfolgen Echtzeit-Benachrichtigungen an das Betriebsteam sowie an den Auftraggeber, sodass Probleme frühzeitig erkannt und behoben werden können.
Umsetzung individueller Anforderungen
Die Weiterentwicklung beider Lose erfolgt iterativ im Rahmen agiler Sprintzyklen. Erweiterungen - etwa neue API-Endpunkte in Los 1 oder zusätzliche UI-Funktionalitäten in Los 3 - werden frühzeitig mit dem Auftraggeber abgestimmt und in einer dedizierten Staging-Umgebung demonstriert. Dabei achten wir konsequent auf Kompatibilität zur bestehenden Architektur: Alle Anpassungen erfolgen API- und modellkonform, sodass bestehende Integrationen stabil bleiben.
In der Middleware (Los 1) werden neue Filterlogiken und Endpunkte versioniert veröffentlicht und OpenAPI-konform dokumentiert. Das DMS-Frontend (Los 3) unterstützt eine flexible Erweiterung durch konfigurierbare Dashboards, modular aufgebaute Eingabemasken und wiederverwendbare Formularelemente. Dadurch lassen sich neue Datentypen und Workflows effizient integrieren - ohne tiefgreifende Umbauten oder Beeinträchtigung des laufenden Betriebs.
Übergänge und Schnittstellen zu angrenzenden Losen
Die Zusammenarbeit zwischen den Losen erfolgt entlang klar definierter, API-basierter Übergabepunkte und wird durch eine gemeinsam gepflegte Schnittstellendokumentation (z. B. OpenAPI-Spezifikationen im Git-Repository) transparent gestaltet. So konsumiert die Middleware (Los 1) sämtliche Inhalte aus der Datenintegration (Los 2) ausschließlich über standardisierte REST-APIs. Dabei werden definierte Aktualisierungsfrequenzen - etwa alle fünf Minuten für Sensordaten - zuverlässig eingehalten. Schreiboperationen im DMS-Frontend (Los 3), z. B. im Rahmen des Dubletten-Reviews, erfolgen ebenfalls ausschließlich über serverseitige Schnittstellen und niemals direkt aus dem Browser.
Darüber hinaus ist der Widget-Konfigurator aus Los 4 nahtlos in das DMS-Frontend (Los 3) integriert; die resultierende Konfiguration wird automatisiert über APIs an Los 4 übergeben. Für alle Erweiterungen und Änderungen an Schnittstellen gilt: Sie werden vorab mit den angrenzenden Losen abgestimmt und versioniert dokumentiert. In der Übergangsphase wird ein paralleler Betrieb der bisherigen und der neuen Komponenten sichergestellt, einschließlich vollständiger Übernahme aller relevanten Schnittstellen, Konfigurationen und Datenflüsse - um einen reibungslosen und ausfallsicheren Systemwechsel zu gewährleisten.
Die folgende Abbildung zeigt den Kontext der Lose 1 und 3 im Gesamtsystem:
@startuml
!includeurl https://raw.githubusercontent.com/RicardoNiepel/C4-PlantUML/master/C4_Context.puml
LAYOUT_LEFT_RIGHT()
SHOW_PERSON_OUTLINE()
' Personen
together {
Person(admin, "BayTM Admin", "Super-Admin, Governance & Freigaben")
Person(editor, "Redakteur:in / Destination", "Pflegt Inhalte")
Person(dev, "API-Consumer (App/Partner)", "Nutzt BCT-Daten über Middleware")
Person(visitor, "Website-Besucher:in", "Sieht Inhalte via Widgets")
}
' Systeme im Fokus
System_Boundary(bct, "BCT - Lose 1 & 3") {
System(mw, "Los 1: Middleware API", "REST (OpenAPI), JSON-LD/@graph", "Performante, read-only Bereitstellung; Filter & Lizenzlogik")
System(dms, "Los 3: DMS Frontend", "Next.js + Backend", "Datenpflege, Veredelung, RBAC, Widget-Konfigurator")
}
' Angrenzende Lose/Komponenten
together {
System_Ext(di, "Los 2: Datenintegration (dataCycle)", "REST/GraphQL", "Aggregation, Validierung, ODTA-Export")
System_Ext(widgets, "Los 4: Widgets", "Web Components/iFrame", "Ausspielung & Visualisierung")
System_Ext(iam, "Keycloak (IAM)", "OIDC/JWT", "Zentrale Authentifizierung")
System_Ext(mon, "Monitoring/Logging", "APM/Logs/Metrics", "Verfügbarkeit, Performance, Audit")
}
' Beziehungen
Rel(admin, dms, "Konfiguriert, verwaltet, gibt frei")
Rel(editor, dms, "Pflegt & veredelt Inhalte")
Rel(dev, mw, "Konsumiert Daten", "JWT")
Rel(visitor, widgets, "Nutzt eingebettete Widgets")
Rel(dms, di, "Lesen/Schreiben touristischer Daten", "REST/Backend-zu-Backend")
Rel(mw, di, "Liest normalisierte/aktuelle Daten", "REST/Read-Only")
Rel(dms, widgets, "Konfiguriert Widgets (Übergabe der Konfiguration)", "API")
Rel(mw, widgets, "Datenquelle für Widget-Laufzeit", "REST/JSON-LD")
Rel(mw, iam, "Auth (JWT/OIDC)")
Rel(dms, iam, "Login/RBAC (OIDC)")
Rel(mw, mon, "Metriken/Logs")
Rel(dms, mon, "Metriken/Logs")
@enduml0.2 Organisation von Wartung, Support und SLA-Einhaltung
Die Wartungs- und Supportprozesse für Los 1 und Los 3 sind so organisiert, dass sie die in Anlage 3, Kapitel 5 definierten Reaktions- und Wiederherstellungszeiten, Überwachungsmechanismen und Eskalationspfade vollumfänglich erfüllen.
Reaktions- und Wiederherstellungszeiten, Überwachung, Eskalationsmechanismen
Für die Betreuung von Los 1 (Middleware) und Los 3 (DMS Frontend) wird eine lückenlose Überwachung (24/7) der Kernkomponenten etabliert. Zum Einsatz kommen standardisierte Observability-Stacks auf Basis von Prometheus, OpenTelemetry und Grafana, mit Metriken zu Verfügbarkeit, Antwortzeiten, Fehlerraten, Durchsatz und Fehlerbudgets. Ein angebundenes Alerting-System (z. B. Alertmanager) löst im Fall von Schwellwertverletzungen automatische Eskalationen entlang definierter Eskalationsstufen aus - beginnend beim On-Call-Team, über den Incident Commander bis hin zur fachlichen und technischen Leitung. Die Alarmierung erfolgt dabei kanalübergreifend (z. B. MS Teams, E-Mail, SMS) und ist auf Prioritäten abgestimmt.
Im Störfall gelten klar definierte Reaktions- und Wiederherstellungszeiten. Bei einem P1-Incident (Showstopper) - etwa dem Ausfall der Middleware oder des DMS - erfolgt die Reaktion innerhalb von 3 Stunden, die vollständige Wiederherstellung innerhalb von 12 Stunden. Bei kritischen Einschränkungen (P2) beträgt die Reaktionszeit maximal 8 Stunden, bei weniger gravierenden Fällen (P3/P4) verlängern sich die Fristen entsprechend. Die Bearbeitung erfolgt über ein standardisiertes Ticketsystem (z. B. Jira Service Management oder OTRS), mit definiertem Support-Workflow (Intake → Priorisierung → Bearbeitung → QA → Abschluss). Ergänzend finden regelmäßige Post-Incident-Reviews bei P1/P2-Störungen statt, um Ursachen zu analysieren und Maßnahmen nachzuverfolgen.
Ein monatlicher SLA-Report informiert den Auftraggeber über Erfüllungsgrade (SLA/SLO), Incidents, MTTR/MTTA sowie erkannte Change-Risiken. Bei kritischen Vorfällen können Ad-hoc-Berichte erstellt werden.
Die folgende Darstellung zeigt die organisatorische Einbettung von Betrieb, Support und SLA-Management:
@startuml
!include <C4/C4_Container>
LAYOUT_LEFT_RIGHT()
' Personen / Rollen
Person(ag_ops, "AG Betriebsteam", "Empfängt SLA-Reports, Eskalationen, Statusmeldungen")
Person(support, "Support-Team BU", "1st/2nd/3rd Level Support, Wartung, Monitoring")
Person(enduser, "Endnutzer / Redaktion", "Verwendet DMS oder Widgets")
' Externe Systeme (andere Lose)
together {
System_Ext(los2, "Los 2: Datenintegration", "REST/GraphQL", "Aggregierte/validierte Daten, Dublettenmanagement")
System_Ext(los4, "Los 4: Widgets", "Web Components/iFrame", "Visualisieren BCT-Daten, erhalten Konfigurationen")
}
' Gemeinsame Querschnittsdienste
Container_Boundary(mon_stack, "Monitoring & SLA-Management") {
Container(mon_sys, "Monitoring / Telemetrie", "Prometheus, Grafana, OpenTelemetry", "24/7 Überwachung, Dashboards, SLA-Metriken")
Container(alerting, "Alerting / Eskalation", "Alertmanager, MS Teams, E-Mail/SMS", "Automatische Benachrichtigung bei SLA-Verletzung, Eskalationsstufen")
Container(ticket, "Ticket-System", "Jira Service Management / OTRS", "Erfassung, Priorisierung, Tracking von Incidents & Changes")
Container(docu, "Betriebsdokumentation", "GitLab/GitHub Wiki", "Betriebshandbücher, Runbooks, API-Doku, Changelog")
}
' Los 1 Middleware
System_Boundary(los1, "Los 1: Middleware - Performante API") {
Container(mw_api, "Middleware API", "Spring Boot/Kotlin", "OpenAPI REST, JSON-LD, Read-only; Filter, Caching")
Container(mw_cache, "Edge/Response Cache", "Redis/Varnish", "Caching, Rate-Limiting")
}
' Los 3 DMS Frontend
System_Boundary(los3, "Los 3: DMS Frontend - Toolbox Tourismus") {
Container(dms_ui, "DMS UI", "Next.js/React", "Barrierearm, responsiv, Headless-Frontend")
Container(dms_api, "DMS Backend API", "Node.js/Next API", "RBAC, Workflows, Proxy zu Los 2, Widget-Konfig")
}
' Beziehungen - Betrieb / Support
Rel(ag_ops, ticket, "Meldet / erhält Status zu Incidents")
Rel(support, ticket, "Bearbeitet, dokumentiert")
Rel(ticket, docu, "Verknüpft mit Runbooks, Wissensartikeln")
Rel(mon_sys, alerting, "Löst Eskalationen bei Threshold-Verletzungen aus")
Rel(alerting, support, "Benachrichtigt gemäß Eskalationsplan")
Rel(mon_sys, ag_ops, "SLA-Reports, Dashboards")
Rel(mon_sys, support, "Live-Daten, Logs, Metriken")
' Monitoring angebunden an Lose
Rel(mw_api, mon_sys, "API-Uptime, Performance-Metriken, Error-Logs")
Rel(dms_api, mon_sys, "Backend-Uptime, Performance, Fehlertracking")
Rel(los2, mon_sys, "Schnittstellen-Status, Datenlieferzeiten")
Rel(los4, mon_sys, "Widget-Performance, Nutzungsmetriken")
' Kern-Datenflüsse
Rel(dms_api, los2, "Lesen/Schreiben touristischer Daten", "REST/Server-to-Server")
Rel(mw_api, los2, "Read-only Datenbezug", "REST")
Rel(dms_api, los4, "Konfigurationsübergabe für Widgets", "API/Webhooks")
Rel(los4, mw_api, "Datenzugriff zur Laufzeit", "REST/JSON-LD")
' Dokumentation & Wissenstransfer
Rel(docu, ag_ops, "Zugriff auf aktuelle Systemdokumentation, Architekturen, API-Specs")
Rel(docu, support, "Wartungshandbuch, Runbooks, Konfigurationen")
@endumlStrukturierte Dokumentation im laufenden Betrieb
Alle Systemkomponenten, Schnittstellen und Betriebsprozesse werden im Sinne einer „Living Documentation“ kontinuierlich in einem Git-basierten Dokumentationssystem gepflegt (z. B. GitLab Wiki, GitHub Pages). Diese Dokumentation umfasst unter anderem:
- Systemarchitektur (UML)
- API-Spezifikationen (OpenAPI, ggf. GraphQL)
- Betriebs- und Wartungshandbuch
- Konfigurationen und Umgebungsdetails
- Runbooks, SOPs und Incident-Wiederanlaufstrategien
- Changelogs und Release Notes
Sämtliche Changes und Incidents im Ticketsystem werden mit der entsprechenden Dokumentation verknüpft. Änderungen an administrativen Konfigurationen oder Schnittstellen werden vollständig versioniert und über Audit-Logs nachvollziehbar protokolliert. Dokumentationsstände werden mit jedem Release automatisch getaggt, wodurch eine saubere Nachvollziehbarkeit zwischen Code- und Dokumentationsversion sichergestellt ist.
Die zentrale Bereitstellung über GitHub Pages (oder vergleichbare Git-basierte Lösungen) gewährleistet eine barrierearme, gut durchsuchbare und jederzeit aktuelle Informationsbasis - sowohl für das Supportteam als auch für den Auftraggeber.
Wissenstransfer und Übergabe am Ende der Vertragslaufzeit (Rampdown-Phase)
Für die Übergabe an einen Nachfolger oder zurück an den Auftraggeber wird frühzeitig - spätestens drei Monate vor Vertragsende - eine strukturierte Rampdown-Phase initiiert. Diese umfasst eine vollständige technische Dokumentation sämtlicher Architekturen, Datenflüsse, Schnittstellen und Betriebsdetails. Dank der während des Betriebs aufgebauten Living Documentation ist der Großteil dieser Inhalte bereits aktuell und vollständig verfügbar, was die Übergabe effizient und revisionssicher gestaltet.
Im Rahmen des Wissenstransfers werden zusätzlich alle offenen Vorgänge, technischen Schulden sowie relevante Konfigurationen dokumentiert. Die Übergabe umfasst darüber hinaus:
- Quellcode (gemäß Open-Source-Lizenz oder Nutzungsvereinbarung)
- Admin-Zugänge und Rollen in IAM-Systemen, Monitoring-Stacks, Repositories, Artefakt-Registries
- Übergabegespräche, Pairing-Sessions und Sprechstunden (Q&A)
- Ein gemeinsames Abnahmeprotokoll, das die erfolgreiche Übergabe dokumentiert
Durch die Verknüpfung von Betrieb, Support, Dokumentation und Transfer entsteht eine konsistente, nachvollziehbare und nahtlose Übergabestruktur, die den Betrieb auch nach Vertragsende absichert und weiterführende Entwicklungen erleichtert.