Projektauftrag

Dieser Projektauftrag begründet formell die Existenz des Projekts „Datenfabrik SH | Architektur“ und genehmigt dessen Umsetzung. Der Projektauftrag gibt der Projektleitung die Befugnis, die in diesem Projektauftrag definierten Ressourcen zum Erreichen der Projektziele einzusetzen. Die Projektleitung ist berechtigt, die folgenden Arten von Änderungen vorzunehmen, ohne dass das Dokument erneut genehmigt werden muss:

  • Redaktionelle Änderungen, Formatierungen und Rechtschreibkorrekturen
  • Inhaltliche Klarstellungen Sonstige Änderungen bedürfen der erneuten Genehmigung.
Name, Laufzeichen Rolle Aktion Datum
Alexandra Blaschke Projektleitung Erstellt 23.05.2025
Moritz Karg Auftraggeber Abgenommen 26.05.2025

1. Einleitung

1.1 Ausgangssituation und Gründe für Projektdurchführung

In der Landesverwaltung gibt es zur Datenauswertung derzeit vor allem drei Möglichkeiten: Zum ersten die Nutzung von Tools, die lokal auf dem Laptop eines Mitarbeiters installiert sind. Zum zweiten die Nutzung von zentralen Fachverfahren, die als Ergänzung über Auswertungsmöglichkeiten verfügen. Zum dritten eigenständige Fachverfahren, die speziell für einen fachspezifischen Auswertungsfall eingerichtet wurden. Die erste Möglichkeit bietet keine Automatisierung, die zweite Möglichkeit ist im Anwendungsfall eng begrenzt und die dritte Möglichkeit sehr kostspielig bzw. mit einer hohen Einstiegshürde verbunden. Es ist eine Lücke vorhanden, die durch die Datenfabrik geschlossen werden soll. In Abgrenzung zum Datenhaus, das zeitgleich neu aufgebaut wird und zentrale Tools zur Datenauswertung bereitstellen soll, ist die Datenfabrik für individuelle Auswertungsbedarfe, die nicht von einem Tool direkt gedeckt werden können. Das betrifft in der Regel Bedarfe an automatisierter Datenauswertung in Kombination mit einer individualisierten Aufbereitung und Bereitstellung der Ergebnisse, z.B. in Form von nutzerspezifischen Berichten oder interaktiven Dashboards.

1.2 Optionen und ausgewählter Lösungsweg

Es soll daher eine Plattform aufgebaut werden. Der Kern der Datenfabrik ist: Automatisierte Datenauswertung und individualisierte Bereitstellung ermöglichen. Die Datenfabrik stellt dazu den Betriebsrahmen in Form einer laufenden Plattform. Experten und Entwickler können auf dieser Plattform ihre Anwendungsfallspezifischen Auswertungslogiken laufen lassen und damit Berichte oder individuelle Dashboard-Lösungen für Endnutzer anbieten. Ein umgesetzter Anwendungsfall läuft dann ohne manuellen Eingriff. Individualisierungsmöglichkeiten im Dashboard lassen sich ohne Experten- und Entwickler-Know-How nutzen. Die Datenfabrik wird begleitend zur Konzeptionierung vertestet und evaluiert. Dazu ist es möglich, frühzeitig Testsetups zu nutzen oder zu erstellen und die Tauglichkeit der Ansätze durch Dritte evaluieren zu lassen.

2. Projektziele

2.1 Produktziele

2.1.1 Organisatorische Produktziele

Im Folgenden erfolgt die Aufzählung der organisatorischen Produktziele, die sich auf die Implementierung, Ausführung und Zusammenarbeit beziehen wie den Prozess, den Betrieb und die Kollaboration rund um die Plattform.

1. Frühzeitige und fortlaufende Verprobung durch Dritte

  • Spezifisch: Die Datenfabrik wird während der Konzeptionsphase kontinuierlich getestet und evaluiert, indem frühzeitig Testsetups genutzt oder erstellt werden, um die Tauglichkeit der Ansätze zu prüfen.
  • Messbar: Die Ergebnisse der Evaluation werden dokumentiert und als Grundlage für die Optimierung der Ansätze verwendet. Der Erfolg der Verprobung wird anhand dokumentierter Ergebnisse der Testsetups und der durchgeführten Evaluationen nachvollzogen. Die Ergebnisse fließen sodann in die Optimierung ein.
  • Attraktiv: Eine frühzeitige Verprobung durch Dritte gewährleistet eine fundierte Evaluierung der Ansätze und unterstützt deren Weiterentwicklung. Realistisch: Testsetups werden erstellt und Dritten zur Verfügung gestellt, um eine regelmäßige Evaluation zu ermöglichen.
  • Terminiert: Die ersten Testsetups werden bis [Datum] bereitgestellt.

2. Einheitliche Umsetzung und Transparenz im Deploymentprozess zur Vermeidung von Hindernissen

  • Spezifisch: Guidelines und Best Practices werden bereitgestellt, um eine einheitliche Nutzung von Programmiersprachen und Frameworks sicherzustellen. Externe Dienstleister werden über den Deploymentprozess aller Stufen informiert, um eigenständig Anwendungsfälle, auch für Schutzstufe hoch, ohne signifikante Änderungsbedarfe entwickeln und einbringen zu können.
  • Messbar: Die Guidelines und der Deploymentprozess werden dokumentiert und bereitgestellt. Feedback aus dem Prozess dient als Grundlage für Verbesserungen.
  • Attraktiv: Ein transparenter und einheitlicher Deploymentprozess reduziert Hindernisse und ermöglicht eine effiziente Zusammenarbeit mit externen Dienstleistern.
  • Realistisch: Die Guidelines und Best Practices werden intern erarbeitet und dokumentiert. Eine klare Beschreibung des Deploymentprozesses wird erstellt, um externe Dienstleister gezielt zu informieren.
  • Terminiert: Die Guidelines und Best Practices sowie die Beschreibung des Deploymentprozesses werden bis [Datum] finalisiert und veröffentlicht.

3. Schnelle Beauftragung durch Rahmenvertrag

  • Spezifisch: Ministerien sollen durch einen Rahmenvertrag Anwendungsfälle unkompliziert und ohne vertragliche Hürden beauftragen können. Das Herangehen soll auch für kleine Anwendungsfälle geeignet sein.
  • Messbar: Die Nutzung des Rahmenvertrags wird anhand des Feedbacks der Ministerien zur tatsächlichen Nutzung des Vertrags gemessen.
  • Attraktiv: Der Rahmenvertrag erleichtert die Beauftragung und unterstützt die Entwicklung von Anwendungsfällen, indem bürokratische Verzögerungen minimiert werden.
  • Realistisch: Ein Entwurf für einen Rahmenvertrag wird erstellt und hinsichtlich seiner Eignung evaluiert, um festzustellen, ob und wie er von unterschiedlichen Ministerien genutzt werden kann.
  • Terminiert: Der Entwurf für den Rahmenvertrag wird bis [Datum] erstellt, und die Eignung wird bis [Datum] evaluiert.

4. Innovationsoffenheit durch offenen Code

  • Spezifisch: Der Code zu den entwickelten Anwendungsfällen wird in der Regel öffentlich bereitgestellt, um Drittparteien die Möglichkeit zu geben, darauf aufzubauen und innovative Ideen zu entwickeln.
  • Messbar: Der Code zu den Anwendungsfällen wird veröffentlicht und öffentlich zugänglich gemacht.
  • Attraktiv: Die Veröffentlichung des Codes fördert Innovationen und ermöglicht es Dritten, auf den bestehenden Lösungen aufzusetzen.
  • Realistisch: Der Code wird unter Berücksichtigung rechtlicher und technischer Rahmenbedingungen veröffentlicht, um eine breite Nutzung zu ermöglichen.
  • Terminiert: Die Veröffentlichung des Codes erfolgt kontinuierlich, beginnend mit den ersten Deployten Anwendungsfällen.

2.1.2 Technische Produktziele

Im Folgenden erfolgt die Aufzählung der technischen Produktziele, die auf die Eigenschaften und Fähigkeiten des Produkts abzielen, wie die technischen Eigenschaften und Funktionalitäten der zu entwickelnden Plattform.

1. Einfache Installation und Rollout

  • Spezifisch: Die Datenfabrik Architektur kann von externen Nutzern in unter 4 Stunden in einem Kubernetes-Cluster installiert und ausgerollt werden.
  • Messbar:
    • Vollständiges README mit Deployment-Schritten
    • Initiales Deployment auf IBM Cloud Cluster
    • Deployment auf Mircok8s
    • Validierung durch Deployment auf Dataport Kubernetes Cluster (DEV)
  • Attraktiv: Externe Dienstleister können die Datenfabrik Architektur schnell evaluieren und in ihre Infrastruktur integrieren, was die Akzeptanz steigert. Realistisch: Die Installationsprozesse werden durch detaillierte Dokumentation und Automatisierungstools unterstützt.
  • Terminiert:
    • Erstmalig in 2 Monaten für IBM Cluster und Microk8s
    • Deployment auf Dataport Umgebung (DEV / PREPROD) im 3./4. Quartal

2. Einfache Umsetzbarkeit von Anwendungsfällen

  • Spezifisch:
    • Die Datenfabrik Architektur ermöglicht es, einfache Auswertungen und Anwendungsfälle schnell zu entwickeln und auszurollen.
    • Beispiele dienen als Ausgangsbasis für eigene Anwendungsfälle und können nach Bedarf angepasst und erweitert werden.
  • Messbar: Es sollen exemplarische Anwendungsfälle definiert werden, die eine Guideline für den Umfang von „schnell“ und „einfachen“ Anwendungsfällen bieten.
    • “einfach“: programmatische Verarbeitung einer hochgeladenen Datei und Rückgabe des Ergebnisses via API
    • “schnell“: Einbettung, wenn das Skript steht, erfolgt die Einbettung innerhalb von einem Werktag
  • Attraktiv:
    • Die Beispiele decken gängige Anwendungsfälle ab, die typischen Nutzeranforderungen entsprechen, sodass Anwendungsfälle in kurzer Zeit umgesetzt werden können.
    • Interessierten wird möglichst schnell ein Zugang geboten Realistisch: Beispiel liegt vor und ist lauffähig, Fähigkeiten werden konkret danach ausgebaut
  • Terminiert:
    • Erster einfacher Beispiel Anwendungsfall „JSON zu CSV“ in 2 Monaten JSON zu CSV: Ein einfacher Anwendungsfall, der innerhalb von zwei Monaten umgesetzt wird, ist die Transformation von JSON-Daten in das CSV-Format. Dabei werden JSON-Daten aus dem Open-Data-Portal (z. B. Zufish-Rohdaten) automatisiert abgerufen, mithilfe eines Python-Skripts transformiert und als CSV-Datei gespeichert. Das Ergebnis dient als Grundlage für Analysen und weiterführende Anwendungen
    • In den nächsten 6 Monaten sollen weitere Use Cases hinzukommen, welche bereits höherer Komplexitäten abbilden können.

3. Hochautomatisiertes Deployment

  • Spezifisch:
    • Das finale Deployment von Anwendungsfällen erfolgt ohne weiteren EHdB und manuelle Eingriffe durch den Betreiber der Plattform.
    • Das Ausrollen in der offenen Umgebung kann nach einmaliger Freigabe des Accounts durch externe Entwickler erfolgen.
  • Messbar:
    • Für Umgebungen mit normaler Schutzstufe wird ein Deployment innerhalb von maximal 1 Woche ermöglicht,
    • Für Umgebungen mit hoher Schutzstufe wird (vorausgesetzt das Depoyment der Plattform ist erfolgt) ein Deployment von 1 Monat ermöglicht
    • Funktionierende und gut dokumentierte Build-Pipeline in openCode.
  • Attraktiv: Automatisierte Prozesse reduzieren die Abhängigkeit von internen und externen Ressourcen und erhöhen die Effizienz.
  • Realistisch: Deployment-Pipelines werden auf Basis gängiger CI/CD-Tools (z. B. Jenkins, GitLab CI) umgesetzt.
  • Terminiert:
  • Die Deployment-Pipeline in der ersten Infrastrukturumgebung (IBM Cloud OpenShift PiC Cluster) funktioniert reibungslos
  • Erfolgt synchron mit den oben genannten Beispielfällen

4. Kompatibilität mit gängigen Programmiersprachen und Frameworks

  • Spezifisch: Die Datenfabrik Architektur unterstützt Anwendungsfälle, die in gängigen Programmiersprachen und Frameworks entwickelt wurden.
  • Messbar:
    • Ist durch Container-Technologie und Microservices infrastrukturseitig gegeben.
    • Python, Java, Javascript/Typescript, R, Go
  • Attraktiv:
    • Bestehende Lösungen können migriert werden, um die bestehende IT-Landschaft zu integrieren
    • Plattform macht keine Vorgaben, welche Sprachen zu nutzen sind
  • Realistisch: Die Kompatibilität wird durch standardisierte Container-Umgebungen sichergestellt.
  • Terminiert: Erfolgt synchron mit den oben genannten Beispielfällen

5. Eignung für rechen- und speicherintensive Anwendungsfälle

  • Spezifisch: Die Datenfabrik Architektur unterstützt rechen- und speicherintensive Anwendungsfälle.
  • Messbar: Dass es Nachvollziehbar in der Bewertung der Komponenten betrachtet und dokumentiert werden kann
  • Attraktiv: Ermöglicht Anwendungsfälle, die große Datenmenge verarbeiten müssen
  • Realistisch: Bewertung für alle Komponenten liegt vor
  • Terminiert: In Q3 liegt die Bewertung der Komponenten vor

2.2 Nutzen

2.2.1 Erwarteter Nutzen

Die Datenfabrik ist niederschwellig nutzbar und bietet damit auch für kleine Auswertungsskripte eine wirtschaftliche Möglichkeit, diese in einen automatisierten Betrieb zu überführen. Damit eröffnet die Datenfabrik einigen Bereichen erstmalig den Zugang zur Methodik der Datenauswertungen. Durch die Automatisierung trägt die Datenfabrik zu verlässlichen und nachvollziehbaren Auswertungen bei und reduziert Fehlerquellen.

Die Betriebskosten je Anwendungsfall werden gegenüber dem Betrieb als Einzelverfahren deutlich gesenkt. Durch die Verwendung gleicher Technologien über viele Anwendungsfälle hinweg werden auch die Wartungs- und Weiterentwicklungskosten gesenkt.

In Sachen Schutzbedarf skaliert die Lösung mit. In einer offenen Instanz können Interessenten nach Rechtevergabe durch das ZIT die Datenfabrik sofort zur Entwicklung und Produktivsetzung von Auswertungen nutzen, ohne dass ein weiteres manuelles Mitwirken von Datenfabrik-Seite erfolgen muss. Werden nicht nur offene Daten verarbeitet, gibt es weitere Instanzen für Schutzbedarf normal und hoch. Sie ermöglichen die Ausführung der gleichen Auswertungsstrecken, stellen aber zusätzliche Anforderungen an den Prozess der Produktivsetzung von Anwendungsfällen.

Durch den durchgehenden Einsatz von Open Source und die Bereitstellung der Datenfabrik als Open Source gibt es keinen Vendor-Lockin, sodass entwickelte Anwendungsfälle in Zukunft auch an anderer Stelle betrieben werden können. Durch Transparenz bei Plattform und Deploymentverfahren ist es IT-Dienstleistern möglich, ohne individuelle technische Abstimmungsbedarfe Anwendungen für die Datenfabrik zu entwickeln. Sie öffnet damit den Markt für Drittanbieter und fördert die Innvoationsoffenheit Ein Rahmenvertrag ermöglicht es den Ministerien, einen Anwendungsfall ohne vertragliche Hürden und ohne Zeitverzug umsetzen zu lassen.

2.2.2 Erwartete negative Nebeneffekte

Keine.

2.3 Umfang und Abgrenzung

2.3.1 Projektumfang und Liefergegenstände („Scope“)

Im Rahmen des Projekts wird die Datenfabrik als Plattform konzipiert und ausgerollt. Konzeption und Bereitstellung erfolgen iterativ. Die Datenfabrik entsteht in einem Git-Repository auf OpenCode. Dieses enthält alle für die Installation notwendigen Informationen, Konfigurationen und Skripte. Sie kann damit weitestgehend automatisiert in ein Kubernetes-Cluster ausgerollt werden.

2.3.2 Abgrenzung

Das Projekt selbst setzt keine Anwendungsfälle um, sondern setzt auf eine aktive Kooperation mit anderen Projekten. Das Projekt stellt jedoch eigenständig Beispiele bereit, an denen die Möglichkeiten der Datenfabrik nachvollzogen werden können. Eigenständige Datenanalysetools sind bevorzugt im Datenhaus zu etablieren und kooperativ einzubinden. Sollte dies nicht möglich oder nicht sinnvoll sein, können auch Tools Teil der Datenfabrik werden.