Zweite Konsultation "Gesamtbild" - Feedback des Amtes für IT und Digitalisierung der Senatskanzlei der Freien und Hansestadt Hamburg

Die Freie und Hansestadt Hamburg (FHH) begrüßt die Initiative des BMDS und des Deutschland-Stacks. Im Folgenden nehmen wir zur zweiten Konsultationsrunde und den folgenden Fragestellungen zum Gesamtbild Stellung:

  1. Gibt es pragmatische Umsetzungsbedingungen die ergänzt werden müssen?
  2. Sind die priorisierten Technologiefelder mit den relevanten Technologien und Standards für den Deutschland-Stack unterlegt?
  3. Passt die Ausrichtung der Standards und Technologien zu den strategischen Zielen?

Die folgenden drei Hauptabschnitte enthalten das Feedback der FHH pro Leitfrage und jeweils entlang der Struktur des Gesamtbilds. Im Abschnitt "Sonstiges" sind allgemeine Anmerkungen enthalten.

Umsetzungsbedingungen

Gibt es pragmatische Umsetzungsbedingungen, die ergänzt werden müssen?

Strategie

  1. Die Umsetzungsbedingungen, die im Abschnitt „Strategie“ beschrieben sind, sind nicht klar abgegrenzt von den Zielen, dem Scope (Projektumfang), den Anforderungen und dem grundsätzlichen Lösungsansatz (hier strategische Pfeiler genannt).
  2. Der grundsätzliche Lösungsansatz ist unvollständig und lässt elementare Fragestellungen noch offen. Zum Beispiel, wie wird ein hoher Nachnutzungsgrad des Deutschland-Stacks flächendeckend über alle föderalen Ebenen erreicht? Wie wird die Governance des Deutschland-Stacks aufgesetzt, um sicherzustellen, dass er auch zukünftig die zentralen Anforderungen der staatlichen Bedarfsträger abdecken wird (z. B. im Post-Quantum-Zeitalter)?
  3. Die aktuelle Formulierung ist nicht klar, wie privatwirtschaftliche Lösungen nachgenutzt werden sollen. Privatwirtschaftliche Angebote bewegen sich stark in Richtung as-a-Service und werden in vielen Fällen nur noch als Cloud-Service angeboten. In den strategischen Eckpfeilern wird vom Einkauf und lokaler Datenhaltung gesprochen. Diese Formulierung kann man sowohl so interpretieren als das private Cloud-Angebote, bei denen die Datenhaltung in Deutschland/EU stattfindet genutzt werden sollen als auch, dass nur Hardware und Software beschafft wird, die lokal in staatlichen Rechenzentren betrieben wird.   
  4. Die aktuelle Formulierung ist nicht klar, was der Umfang vom Deutschland-Stack ist und welche Teile des Deutschland-Stacks zentral betrieben werden und welche Teile des Deutschland-Stacks dezentral betrieben werden sollen (siehe strategischer Pfeiler „Plattform als Grundlage für Interoperabilität“). Für die weitere Gestaltung ihrer IT-Landschaften brauchen Behörden von Bund, Ländern und Kommunen aber Klarheit, was in welcher Form vom D-Stack zu erwarten ist. Es wird empfohlen eine Architekturvision für den Deutschland-Stack zu entwickeln, aus der klar hervorgeht, welcher Stakeholder den D-Stack für welchen Zweck nutzt.

Architekturprinzipien

  1. Die formulierten Prinzipien sind je nach Schwerpunktsetzung nicht vollständig. So fehlt bspw. ein Prinzip zum Thema Cloud / Cloud Native, das analog zu „prefer buy over make“ etwa „prefer cloud native over on-prem“ lauten könnte. Es wird auch keine Aussage zu Open Source als ein markantes Thema der Verwaltungsdigitalisierung getroffen, bspw. „prefer open source over closed source“. In dem Zusammenhang könnte ein Abgleich oder ein Verweis auf die föderale bzw. nationale IT-Architekturrichtlinie helfen.
  2. Die formulierten Prinzipien sind nicht konkret genug ausgeführt oder erläutert. Bspw. fehlt eine Interpretationshilfe, was „neuester Stand der Technik“ bedeuten kann. Etwa im Vergleich zur Methode PACE-Layering, bspw. Einsatz neuester Technologien in schnelllebigen Bereichen, etablierte Technologien in Kernbereichen, die sich nicht häufig ändern.
  3. Verbindlichkeit:
    • Eine Unterscheidung in MUSS/SOLL wurde nicht getroffen, um die Verbindlichkeit darzustellen.
    • Die formulierenden Prinzipien sind nicht verpflichtend.
    • Durch die fehlende Verpflichtung und nicht beschriebene Prüfmechanismen, kann die Umsetzung der Prinzipien nicht sinnvoll gesteuert werden.
    • Eine Umsetzung der Prinzipien in den Themenbereichen wird somit nicht konsequent durchgeführt, sodass die Wirkung der Prinzipien verloren geht.
  4. „Managed services only“ ist sehr spezifisch in der Empfehlung bzw. Vorgabe, aber besonders unspezifisch im Ziel. Es gibt eine gewisse Überschneidung zu „DevSecOps“, trotzdem sollten insbesondere SLA-Themen wie Verfügbarkeit, Skalierbarkeit usw. genauer beschrieben werden. Dadurch dürfte sich die Vorgabe „managed services only“ auflösen und zurück bleibt das, was vermutlich mit „professioneller Betrieb“ gemeint ist. Griffiger Vorschlag als Diskussionsstarter: „Deutschland-Ops“ (Skalierung und professioneller Betrieb, angemessen der Verantwortung eines Deutschland-Stacks für ein ganzes Land  bzw. für den Anwendungszweck eines Stack-Elements)

Motivation

  1. Das Kapitel geht nicht auf die vorliegende Situation ein und bleibt vage in der Motivation; ist nur mit der Einleitung der Seite „Gesamtbild“ sowie Teilen der Strategie zu verstehen und zu interpretieren.

    Offen bleibt die Frage, für wen das Fundament bzw. die Bausteine des Deutschland-Stacks sein sollen und was die Empfängerinnen und Empfänger damit konkret und pragmatisch machen sollen bzw. können. Für „Bund, Länder und Kommunen“ ist hier als Antwort zu vage:

    • Geht es um Infrastruktur, auf der Lösungen selbst gebaut werden sollen?
    • Geht es um fachliche wie technische Komponenten inkl. Infrastruktur, die in die jeweilige Landschaft integriert werden sollen aber nicht alleine für sich stehen?
    • Geht es um fertige fachliche Lösungen im Sinne von „Ende-zu-Ende digitalisierten Diensten“, die komplette Fähigkeiten von Bund, Ländern und Kommunen umsetzen und nur verwendet werden müssen?
    • Es gibt vermutlich beliebig viele weitere Varianten und der Deutschland-Stack beinhaltet vermutlich Elemente aus allen Bereichen. Trotzdem sollten erste Eckpunkte als Teil der Motivation benannt werden, um in den Varianten klare Mehrwerte (als Motivation) aufzuzeigen. Bspw. Einsparungen an Infrastruktur, Standardisierung und Verbesserung der User Experience über alle Kommunen und Länder hinweg (für Mitarbeitende der Verwaltung wie für Verwaltungskunden gleichermaßen).

  2. Bereiche wie Nachnutzung, Effizienz, Souveränität werden nicht genauer beschrieben. Der Mechanismus, der motivierendes Verhalten fördern soll bleibt somit hinter den Möglichkeiten zurück.

Technologiefelder und Standards

Agentische und Generative KI

  1. Das BMDS muss sicherstellen, dass alle im D-Stack bereitgestellten Lösungen kompatibel mit dem EU AI Act sind.

  2. Es sollte eindeutig geregelt sein, wer fachliche, technische und organisatorische Verantwortung für eingesetzte KI-Modelle trägt. Dies betrifft vor allem Auswahl, Konfiguration, Training, Freigabe, Monitoring sowie Bewertung.

    Änderungen an Modellen, Trainingsdaten oder Speicherkonfigurationen sollten standardisierte Prozesse sein. Dazu zählen auch Updates, Modellversionen, verpflichtende RE-Validierung nach Änderungen.

    Es wäre sinnvoll, klare Regelungen zur Verantwortlichkeit für KI-gestützte Entscheidungen oder Ergebnisse zu schaffen, insbesondere im Hinblick auf KI-assistierte Entwicklungswerkzeuge und agentischer KI.

  3. Unklare Nachnutzungsbedingungen von KI-Lösungen des D-Stacks, bspw. ausgehend der H2-Plattform.

  4. Lösungen müssen unbedingt mit echten Anwenderinnen und Anwendern getestet werden.

  5. Wird in nachnutzbaren D-Stack-Komponenten künstliche Intelligenz (KI) eingesetzt, dann muss klar gekennzeichnet werden, für welche Zwecke und in welchem Rahmen die mit der Komponente angebotenen Services genutzt werden können, um einen rechtskonformen Einsatz (siehe auch EU AI Act) zu ermöglichen.

  6. Auch wenn Generative KI und Agentische KI ganz neue Möglichkeiten für die Automatisierung von menschlichen Aufgaben bieten, sind sie nicht immer die perfekten Werkzeuge für jede Automatisierungsaufgabe. In erster Linie sind sie teuer, und wir beginnen gerade damit herauszufinden, für welche Anwendungsfälle sie am besten einzusetzen sind.

    Wird in nachnutzbaren D-Stack-Komponenten künstliche Intelligenz (KI) eingesetzt, dann muss für nachnutzende Organisationen klar sein, welchen Quality-of-Services sie erhalten (z. B. Veränderung des Verhaltens von KI-Agenten über die Zeit (z. B. Bias), Wahrscheinlichkeit mit der KI ein korrektes Ergebnis liefert), Kosten, etc. um objektiv einschätzen zu können, ob eine Nachnutzung für die geplanten Zwecke sinnvoll ist.

  7. Wird generative KI eingesetzt, dann brauchen nachnutzende Organisationen, die Möglichkeit zu prüfen, wie die Ergebnisse zustande gekommen sind.  Darüber hinaus sollten kontrollierte Eingriffs- und Abschaltmöglichkeiten bestehen, um auf Fehlverhalten reagieren zu können.

  8. Neben konkret umgesetzten Lösungsbausteinen sollte der Deutschland-Stack auch einzelne Entwicklungsfähigkeiten im Umfeld KI bereitstellen, die bspw. kurz mit „Überwachung von Agenten“ und „Qualitätssicherung“ erwähnt werden. Diese Fähigkeiten können die Grundlage für die Entwicklung von Komponenten des Deutschland-Stacks und darüber hinaus bilden. Beispiele: ML-Ops mit Daten-Handling, Training und Fine-Tuning von Modellen, Inference-Infrastruktur, …

Semantische Technologien und Echtzeitanalytik

  1. Die Verwendung von standardisierten Daten- und Austauschformaten ist insgesamt zu begrüßen. Aus den Erfahrungen von Praxisprojekten heraus ist festzuhalten, dass die pragmatische und tatsächliche Anwendung (v.a. von fachlich geprägten Formaten) der theoretischen Ausarbeitung in kleinsten Details vorzuziehen ist.
  2. Die Vermengung der Themen Semantik und Echtzeitanalytik ist nicht ganz nachvollziehbar. Natürlich bilden einheitliche Daten- und Austauschformate eine gute Grundlage für Echzeitanalytik, ggf. kann es sinnvoll sein, die Bereiche getrennt zu betrachten, um jeweils pragmatisch auf einzelne Ziele hinzuarbeiten.

Virtualisierte Softwarebasierte Infrastruktur

  1. Es ist kein einheitliches Betriebsmodell definiert. Eine Formulierung der Mindestanforderungen an Plattformbetrieb, entlang der Prinzipien würde helfen, um eine Nachnutzung zu ermöglichen.

  2. Eine wichtige Umsetzungsbedingung für das Thema wäre zunächst eine Verortung in der Gesamtarchitektur des D-Stacks. Handelt es sich hierbei um Technologien, die im Vorhaben eingesetzt werden sollen, um zentrale Dienste zu realisieren oder handelt es sich um Vorgaben für (staatliche und private) Anbieter die Deutschland-Stack-Konforme Infrastrukturen anbieten wollen.

    Im ersten Fall ist eine öffentliche Technologie-Debatte nur zweitranging. Zudem man auf bereits existierenden Lösungen aufbauen möchte (siehe Ziele).

    Im zweiten Fall ist das viel zu dünn. Eigentlich müsste pro Dienst, den der Deutschland-Stack anbietet, definiert werden, über welche Schnittstellenstandards dieser zu nutzen / zu integrieren ist.

DevSecOps und APIs

  1. Aus Sicht der praktischen Umsetzbarkeit erscheint der Themenbereich stärker als Zielbild oder Leitidee formuliert zu sein, es fehlen praktische Umsetzungsmechanismen.
    • Es fehlt ein verbindlicher Referenzrahmen für DevSecOps (zentral, föderal, mandantenfähig, Betriebsmodell)
    • Derzeit besteht keine einheitliches Referenzmodell  für Build-, Test, Sicherheits-, Release-Pipelines. Eine Definition von einheitlichen Pipeline-Strukturen würden den sicheren und reproduzierbaren Betrieb ermöglichen.
    • Für APIs fehlen klar definierte Qualitätsanforderungen, z.B. Designstandards, Versionierung, Dokumentation, Sicherheitsanforderungen, Testbarkeit. Einheitliche Vorgaben würden Interoperabilität, Nachnutzung und langfristige Wartbarkeit unterstützen.
    • Einheitliche Verfahren für Freigaben, Änderungen und Weiterentwicklungen von Services, APIs und Pipeline-Komponenten wären nützlich.
    • OWASP basierte Security Policies sind aktuell eher konzeptionell. Für eine wirksame Umsetzung sollten diese als technisch durchsetzbare Plattform Policies implementiert werden.
    • Automatisierte Prüfmechanismen könnten Qualitäts-, Sicherheits- und Compliance-Anforderungen systematisch prüfen und dokumentieren.
  2. Für Code, Container, Artefakte und Infrastrukturdefinitionen sollte beschrieben werden. Dies ist vor allem für Wiederverwendbarkeit und Transparenz wesentlich. Es sollte eine Abwägung von Sicherheit und Kollaboration erfolgen:
    • Ob und wie zentrale bzw. föderierte Repositories vorgesehen sind
    • Wie der Zugriff geregelt wird
    • Wie die föderale Zusammenarbeit technisch ermöglicht wird
  3. Im Kontext Supply Chain Sicherheit sollte folgendes berücksichtigt werden:
    • Signierung von Artefakten und Containern
    • Nachvollziehbarkeit der Herkunft von Komponenten
  4. DevSecOps-Ansätze, insbesondere Policy-as-Code, eröffnen die Möglichkeit, datenschutzrechtliche Anforderungen wie Zugriffsbegrenzungen, Zweckbindungen oder Löschregeln nicht nur zu dokumentieren, sondern automatisiert und reproduzierbar durchzusetzen.

Managed Services und Cloud

Eine klare Trennung zwischen welche Elemente des Deutschland-Stacks als Cloud-Service von wem bereitgestellt werden und welche Aspekte des Betriebs eine staatliche Stelle eigene Leistungen erbringen oder bei einem MSP einkaufen muss, ist notwendig. Es müssen die verschiedenen Rollen bei Bereitstellung und Abnahme von Cloud-Services definiert und für eine erfolgreiche Integration von D-Stack Komponenten berücksichtigt werden (bspw. Rollenmodell DVC).

Insbesondere, wenn es Abhängigkeiten geben sollte im Sinne von diesen Cloud-Service des D-Stack bekommt man nur, wenn man zusätzlich MSP-Leistungen bei dem oder dem dazubucht. Grundsätzlich sollten diese Abhängigkeiten zwingend vermieden werden. Die aktuelle Formulierung suggeriert allerdings, dass hier keine klare Trennung stattfindet, die erlaubt die Dienste des D-Stack mit den Leistungen eines beliebigen MSP zu kombinieren.

IT-Sicherheit

Im Bereich IT-Sicherheit bestehen noch praktische Umsetzunglücken um zu nutzbaren, betreibbaren Stack-Fähigkeiten zu kommen.

Für zentrale Stack-Komponenten (Plattformdienste, Laufzeitumgebungen, Integrationsschichten, Entwicklungsumgebungen) fehlt eine einheitliche, technisch definierte Sicherheits-Baseline. Diese sollte die Mindestanforderungen festlegen und als verbindlichen Standard gelten.

Ein strukturiertes Schutzbedarfsmodell für Stack Elemente ist noch nicht erkennbar. Eine Abstufung wäre sinnvoll, um fachliche Anforderungen abzugleichen.

Es bestehen Verweise auf Sicherheitsstandards und Regelwerke, jedoch werden diese bislang nicht durchgängig in konkrete umsetzbare Stack-Vorgaben übersetzt.

Workflowautomatisierung (LowCode)

  1. Themen wie „Vendor Lock-In“ sind angedeutet (Export, Unabhängigkeit von Infrastruktur), sollten aber noch klarer benannt werden.
  2. Kein Bezug zu Ende-zu-Ende-Digitalisierung, noch Erklärung wo Ende-zu-Ende beginnt/aufhört.
  3. Da keine Integrationspflicht in Fachverfahren besteht, bleibt die Wirkung des D-Stacks deutlich unter dem Potenzial. Falls es verpflichtend wird ist zu klären welche Mittel für die Anpassungen bereitgestellt werden.
  4. Eine Beschreibung von Beispielen könnte pragmatische Lösungen sowie einzelne Technologien konkreter beschreiben. (Siehe Kommentar zu „relevante Technologien“)

Zusammenhang zu weiteren Aktivitäten

  1. Es braucht eine Governance, über welche die Abgrenzung / Zusammenarbeit mit benachbarten Vorhaben gesteuert wird. Wie wird geklärt, was in welchem Vorhaben umgesetzt wird, was welches Vorhaben welchem anderen Vorhaben zu liefern muss, sprich wo bestehen welche Abhängigkeiten. Dazu wird hier leider keine Aussage getroffen. Das wäre aber der wichtigste Punkt in diesem Abschnitt gewesen.
  2. Es fehlt die Darstellung der Zusammenhänge zu weiteren nicht genannten Vorhaben (z. B. OZG, NOOTS, Register Modernisierung). Man müsste zumindest angeben, dass die Liste nicht vollständig ist.
  3. Die Abgrenzung zwischen dem D-Stack-Vorhaben und den anderen Initiativen muss viel konkreter beschrieben werden. Aktuell ist zu viel Interpretationsspielraum vorhanden, was es den Beteiligten in allen Vorhaben sehr schwer macht, punktgenau zu liefern. Es wird auf der Arbeitsebene sehr viel Aufwand betrieben, um den Schnitt zwischen den Vorhaben, aus Sicht der einzelnen Vorhaben und nicht aus der Gesamtsicht, zu definieren.
  4. Insbesondere die Abgrenzung zwischen D-Architektur und D-Stack ist unnötig unscharf. Formulierungsvorschlag: Die Deutschland-Architektur liefert den Bauplan für die Staats-IT auf der obersten Ebene. Der Deutschland-Stack realisiert Teile davon (insbesondere die zentralen Basisdienste wie die Deutschland-ID (vormals Bund-ID) und fertige, leicht nachnutzbare Lösungsbausteine für regionale staatliche Lösungen.

Portfolio, Roadmap und mehr

  1. Das Leistungsportfolio, dass über den Deutschland-Stack angeboten werden wird, wird sich über die Zeit verändern müssen. Dazu braucht es ein Portfoliomanagement, dass die Abstimmung zur Deutschland-Architektur leistet, die Weiterentwicklung bestehender, bzw. Außerbetriebnahme veralteter, D-Stack IT-Bausteine (Lifecycle-Management) verantwortet und Verbindlichkeit bzgl. der Verfügbarkeit und Leistungsfähigkeit der einzelnen vom D-Stack angebotenen Services für definierte Zeiträume garantiert. Ohne das wird keiner das Risiko einer Nutzung eingehen wollen.  

  2. Im Rahmen der Portfolioentwicklung muss für jeden über den D-Stack bereitgestellten Services / bereitgestellten IT-Lösungsbaustein geklärt werden, wie die einfache Nachnutzung durch staatliche Akteure rechtlich (z. B. Anpassung von gesetzlichen Regelungen) und technisch (z. B. technische Anschlussbedingungen, Abhängigkeiten) realisiert werden kann.

  3. Die Dienste, die über den Deutschland-Stack angeboten werden sollen (z. B. auf Ebene Plattformkern, Fachagnostische Plattformen) sollten im as-a-Service-Modell nutzbar sein. Wird die Buchung von Managed Services bei einem zentralen Dienstleister (Managed Service Provider) zwingend notwendig für die Nutzung der oben beschriebenen Dienste, wird die Nachnutzung erschwert und der MSP wird zum Flaschenhals. Das Modell skaliert nicht. 

  4. Der Ausschnitt beschäftigt sich hauptsächlich mit den Elementen eines Portfolios, nicht mit der transparenten Übersicht der bestehenden Fähigkeiten.

    Ohne eine solche zentrale Übersicht wird die Steuerung des Portfolios erschwert.

    Eine Beschreibung der Darstellung des Portfolios wäre hilfreich.

Relevante Technologien

Sind die priorisierten Technologiefelder mit den relevanten Technologien und Standards für den Deutschland-Stack unterlegt?

Strategie

n/a

Architekturprinzipien

Die priorisierten Technologiefelder sind im Grundsatz benannt, jedoch nicht durchgängig mit den für den operativen Einsatz im D-Stack erforderlichen Technologien, Standards und dem Umsetzungsmechanismen unterlegt. Insbesondere im Hinblick auf die praktische Realisierung und Betrieb als föderal skalierbarer Stack bestehen fehlen:

  • API-Governance als verbindliche Plattformfähigkeit
  • Technische Durchsetzung von Sicherheitsvorgaben (eher konzeptionell beschrieben)
  • Durchgängige Observability als Betriebsgrundlage (Funktionen zur Laufzeit als Voraussetzung für Steuerbarkeit, Transparernz und zuverlässigen Betrieb), Observability zur Laufzeit

Motivation

Aus der Motivation ergeben sich Themenfelder wie die Erfassung und Messung von Nachnutzung der D-Stack Lösungen, Effizienz und Transparenz über Mehrwerte zur nachhaltigen Steuerung und Weiterentwicklung des D-Stacks. Es fehlen u.U. Instrumente und Technologien sowie gemeinsame Bewertungsmaßstäbe, um eine Vergleichbarkeit herzustellen. Bspw. Monitoring und Messung der Nachnutzung, Effizienz – um auf Nutzungsintensitäten, Wiederverwendungsquoten, vermiedene Doppelentwicklungen, Skaleneffekte sowie Auswirkungen auf Entwicklungs-, Betriebs- und Prozesskosten einzugehen.

Technologiefelder und Standards

Agentische und Generative KI

  1. Die aktuell aufgeführten Standards sind sicherlich aktuell nicht falsch. Es gibt einige weitere Standards, wie ACP, die noch fehlen. Allerdings ist die Entwicklung hier aktuell sehr dynamisch. Zudem wird die Definition der hier aufgeführten Standards aktuell sehr von US-Unternehmen geprägt.  

    Die aktuell aufgeführten Standards für KI-Agenten fokussieren sehr auf die Integration von Agenten in ihre Umwelt (Datenquellen, andere Agenten, Menschen).

    Richtig wird dargestellt, dass darüber hinaus weitere Standards für die Überwachung von Agenten und die Sicherung der Ergebnisqualität braucht. In Summe muss aber das gesamte Lifecycle-Management von Agenten betrachtet werden. Um hier Interoperabilität zwischen den Agenten und ihrer Laufzeitumgebung sicherzustellen braucht es auch dafür Standards. Diese sollten wir in Europa gemeinsam mit unseren europäischen Partnern definieren und somit den Standard für den sicheren skalierbaren produktiven Einsatz von KI-Agenten schaffen. Dazu zählen u. a.:

  2. Hamburg stellt mit „LLMoin“ einen LLM-basierten Chatbot für die Verwaltungsarbeit (bspw. Recherche, Zusammenfassungen) bereit, der bis einschließlich Schutzbedarf „hoch“ betrieben werden kann. Es ist zu bewerten, ob LLMoin eine D-Stack Lösung darstellen kann.

Semantische Technologien und Echtzeitanalytik

  1. Die dargestellte Sammlung von Standards für diesen Kontext scheint zunächst sinnvoll. Es müssten vermutlich noch Konkretisierungen vorgenommen werden, um festzulegen für welchen Einsatzzweck welcher Standard (verbindlich oder optional) anzuwenden ist.

    Ergänzt werden könnten:

    • SHACL (Shapes Constraint Language) - für das Validieren von RDF-Graphen
    • Konkretisierung der Vorgabe von JSON um “JSON-LD” (for linked data) oder Alternativen dazu, die genutzt werden sollen
    • Weitere KI-bezogene semantische Standards, um die effiziente Nutzung der betreffenden Daten mit KI zu gewährleisten
    • Binäre Austauschformate (vgl. Impfzertifikate mit CBOR)

  2. Der Bereich Echtzeitanalytik könnte bewährte Konzepte, Technologien, Dienste wie bspw. den Unified Observability Stack und de-facto Standards wie OpenTelemetry oder Anwendungen wie Prometheus, Grafana aufgreifen.

Virtualisierte Softwarebasierte Infrastruktur

Die Beschreibung der virtualisierten softwarebasierten Infrastruktur adressiert zentrale technologische Grundlagen, bleibt jedoch mit einigen Punkten auf einer konzeptionellen Ebene. Für eine belastbare Nutzung wären ergänzende Klarstellung in folgenden Bereichen hilfreich:

  • Es sollte beschrieben werden, wie Transparenz über Zustand, Auslastung und Verhalten der Plattform hergestellt wird (Plattform-Observability).
  • Für die gemeinsame Nutzung der Infrastruktur durch Bund, Länder und Kommunen ist eine eindeutige technische und organisatorische Trennung der Nutzenden erforderlich. Dazu gehören standardisierte Mechanismen für Monitoring, Logging sowie die Nutzung für Betrieb, Fehleranalyse, Kostenisolation und Leistungssteuerung.
  • Die Nachnutzung über föderale Ebenen hinweg setzt voraus, dass mehrere Infrastrukturstandorte technisch zusammenwirken, ohne organisatorisch zentralisiert zu sein. Hier wären Aussagen hilfreich, wie Portabilität, gemeinsame Standards und verteilte Betriebsmodell konkret unterstützt werden.
  • Die Sicherherstellung kontinuierlicher Verfügbarkeit ist für kritische Verwaltungsleistungen zentral. Daher sollte deutlich beschrieben werden, wie Redundanzen geplant, betrieben und gesteuert werden.

DevSecOps und APIs

  1. Der Themenblock adressiert zentrale Prinzipien moderner Softwareentwicklung. Eine Konkretisierung wäre jedoch hilfreich. Insbesondere bzgl. Sicherheits- Transparenz- Lieferkettenmechanismen, bspw. aufbauend auf Technologien / Formaten wie SBOM.

    Folgende Aspekte könnten definiert werden; eine gemeinsame Definition dieser Anforderungen würde die Vergleichbarkeit, Transparenz und Sicherheitsqualität erhöhen:

    • Für die Qualitätssicherung standardisierte Prüfmechanismen
    • Scan Testing – SAST, DAST, Dependency Scans, Security Gates in CI/CD Pipelines,  zentrale Ergebnisaggregation & Reporting, Logging, Tracing, Metrics, SLA&SLO Messung

  2. Auflistung der Schnittstellen und Kommunikationsprotokolle sollte laufende Projekte des Planungsrats wie ZaPuK und deren Protokolle (matrix) berücksichtigen bzw. nicht ausschließen.

  3. SMTPS ist per default nicht Ende-zu-Ende verschlüsselt und sollte nicht als sicher gelistet werden (vgl. BSI).

  4. In dieser Sektion werden teilweise Technologien und Standards konkret benannt (z.B. Git), allerdings auch einige “Prinzipien” und “Ansätze” ohne entsprechende Konkretisierung (z.B. CI/CD, IaC). Hier sollten perspektivisch auch konkrete Technologien oder Standards festgelegt werden, welche für diese entsprechenden Ansätze im Rahmen des D-Stack eingesetzt werden sollen (z.B. IaC = Terraform, CI/CD = Jenkins?).

    Grundsätzlich sollten hierbei explizite Festlegungen getroffen und der jeweilige Anwendungsfall für die konkreten Standards dargestellt werden – keine unverbindliche Auflistung möglicher Standards/Technologien/Tools. Ansonsten sollte dargestellt werden, warum für bestimmte Aspekte explizit keine Vorgabe gemacht werden soll.

Managed Services und Cloud

Die genannten Technologien (OpenStack, SCS) sind sicherlich relevant. Aber die Einschränkung von Cloud auf Standards aus der DVC, SCS und OpenStack sind nicht nachvollziehbar. Warum ist es von Relevanz mit welcher konkreten Technologie (z. B. OpenStack, SCS) ein cloud-basierter D-Stack-Dienst angeboten wird? Viel wichtiger ist doch, dass definierte Rahmenbedingungen eingehalten werden (z. B. Erfüllung BSI C5-Standard oder auch DVC-Standards). Damit wird der Lösungsraum nicht unnötig eingeschränkt.

IT-Sicherheit

Der Abschnitt zur Sicherheit ist aufgrund der verlinkten Standards relativ kurz. Dadurch werden die Fähigkeiten des Stacks im Bereich IT-Sicherheit nicht klar.

Wie steht es bspw. mit diesen Themen:

  • IAM/M2M Identitäten nicht nur Protokoll
  • Key & Secret-Management
  • Zentrales Logging & SIEM
  • Backup & Recovery?
  • Datenschutz und Compliance sind eigene Themenfelder, aber auch Archivierung ist im öffentlichen Kontext von hoher Bedeutung

Workflowautomatisierung (LowCode)

  1. Es besteht noch keine konkrete Beschreibung der föderierten Workflow Engine oder eines Modellierungsstandards für LowCode-Flows.

    Inwiefern können bereits bestehende Lösungen der Länder wie Modul-F (Hamburg) verwendet werden?

  2. Die groben technischen Eckpfeiler sollten (beispielhaft) beschrieben werden, um Interoperabilität zu ermöglichen. So ließe sich beschreiben, wie Workflowautomatisierung eingesetzt und bei Bedarf auch aneinandergereiht werden kann. Bspw.:

    • (mindestens) zu unterstützende Trigger per API, E-Mail, zeitbasiert…
    • Gestaltung von Datenzugriff (externe Quellen, Anlieferung als Parameter, in-flow memory)
    • Ergebnisformate (Maschinenformate wie JSON, CSV; E-Mail)

  3. “externe IT-Lösungen” sollten genauer beschrieben werden, geht es um neue Fachanwendungen, oder um Systeme, die sich extern des Verwaltungsnetzes befinden?

    Handelt es sich um Fachanwendungen ist eine Integration ohne Implementierungsaufwand nahezu unmöglich. Es sei denn, der Scope, die benötigten Daten/-typen, bestehende Funktionen und der Prozess der Bearbeitung ändern sich nicht. Eine reine Schnittstelle reicht nicht aus, um den Workflow abzubilden.

Zusammenhang zu weiteren Aktivitäten

Eine Konkretisierung zu diesen Themen könnte helfen:

Für die praktische Einführung des D-Stacks ist entscheidend, wie bestehende Fachverfahren, Plattformen und laufende Digitalisierungsinitiativen technisch angebunden werden können. Hier wären klare Aussagen hilfreich, wie Interoperabilität, Daten- und Prozessintegration sowie gemeinsame Nutzung von Funktionen über Systemgrenzen hinweg unterstützt werden sollen.

Neben der Integration bestehender Lösungen ist auch der schrittweise Übergang auf D-Stack-basierte Strukturen relevant. Eine Konkretisierung der Unterstützungsmechanismen für eine Migration, Übergangsbetrieb und Transformation bestehender Systeme wäre sinnvoll

Portfolio, Roadmap und mehr

Im Portfolio werden einzelne Komponenten genannt, die im Portfolio gepflegt werden sollen, aber nicht, wie das Gesamtportfolio transparent bereitgestellt wird.

Ohne ein geeignetes Portfolio-Architektur Repository bleibt das Portfolio eine Liste, aber kein steuerbares Instrument.

Ausrichtung Technologien

Passt die Ausrichtung der Standards und Technologien zu den strategischen Zielen?

Strategie

n/a

Architekturprinzipien

  1. Datenschutz auf Architektur- und D-Stack-Ebene sollte als Prinzip aufgenommen werden, bspw. „einer prüft für alle“ und „privacy by design“: Datenschutzkonforme Komponenten bilden die Basis für datenschutzkonforme Lösungen.

  2. Prinzipien wie API-Frist, DevSecOps, ZeroTrust werden nicht stackseitig unterstützt.

    Die Prinzipien sollten sich in  “Stack-Fähigkeiten” wiederfinden.

Motivation

Die geplanten Technologien könnten Motivation bedienen, jedoch macht der Stack Motivation nicht messbar. Somit bleibt Motivation kommunikativ, nicht wirksam.

Technologiefelder und Standards

Agentische und Generative KI

  1. Passend zu Innovationsstrategie, bitte beachten als Gegenspieler zu „Souveränität- und Betriebsstrategie“.
  2. Die aktuelle Beschreibung fokussiert beim Einsatz von Generativer KI nur auf Anwendungsfall persönlicher Assistent reduziert. Wird generative KI in Werkzeugen der Verwaltung eingesetzt (z. B. um einen Bescheid, eine Urteilsbegründung zu entwerfen) dann muss die Betreiberorganisation in der Lage sein, bei technologischer Weiterentwicklung die zu Grunde liegenden Sprachmodelle austauschen zu können. Aber doch nicht der Verwaltungsmitarbeiter. Hier schieben wir die Verantwortung für die Auswahl des richtigen Werkzeugs auf die Nutzenden. Damit muss jeder Verwaltungsmitarbeiter einer Behörde immer wieder die Entscheidung persönlich treffen. Das ist sicher nicht zielführend. Das widerspricht auch den strategischen Eckpfeilern (siehe Strategie) für eine gute Usability. Die Entscheidung, welche KI-Modelle eingesetzt werden sollen, muss von Anwendungsverantwortlichen zentral getroffen werden.

Semantische Technologien und Echtzeitanalytik

Aufgrund des strategischen Fokus auf den Einsatz von KI sollte bei diesen datenbezogenen Standards etwas klarer herausgestellt werden, welche Formate / Standards hier benötigt werden, um solche Daten auch effizient mit KI einsetzen zu können. Die dafür benötigten Datenformate können von den „klassischen“ Formaten abweichen, was in diesem Abschnitt zumindest kurz dargestellt werden sollte (welche Standards sind für KI-Nutzung gut geeignet, welche ggf. nicht).

Virtualisierte Softwarebasierte Infrastruktur

Es bleibt unklar, wie eine Skalierung über mehrere föderalen Ebenen hinweg konkret umgesetzt werden soll. Für die praktische Nachnutzung und gemeinsame Nutzung von Infrastruktur wären klarere Aussagen zu Betriebsmodellen, Last Verteilung über Standorte sowie technische Voraussetzungen für föderale Nutzungsszenarien hilfreich.

Die Beschreibung der Infrastruktur bleibt vergleichsweise technologieoffen.

DevSecOps und APIs

DevSecOps ist eher als Ziel beschrieben nicht als Stack-Service.

Managed Services und Cloud

Mit OpenStack und SCS sind zwei Technologien aufgeführt, die sicherlich sinnvoll sind. Allerdings ist die Einschränkung auf diese beiden Technologien (+DVC) nicht sinnvoll, schränkt es doch den Lösungsraum, der dem D-Stack damit zur Verfügung steht, sehr stark ein. Insbesondere sind damit privatwirtschaftliche nationale / europäische Lösungen, die deutlich mächtiger sind als reines OpenStack/SCS ausqualifiziert. Das passt nicht zu den formulierten Zielen.

IT-Sicherheit

  1. „Zero-Trust“ wird als Architekturprinzip vorgegeben, jedoch nicht im Abschnitt "IT-Sicherheit" aufgegriffen. ALLE Lösungen im Kontext des D-Stacks müssen Zero-Trust-fähig sein und dafür entsprechende Technologien und Standards vorgegeben werden. Diese sind teilweise vorhanden (z.B. OIDC, OAuth), ggf. aber noch nicht abschließend. Auch das „Portfolio“ muss entsprechende Basisdienste und Standards berücksichtigen, damit eine Zero-Trust-Architektur umgesetzt werden kann.

    Die Festlegung solcher Standards, Technologien und Produkte sollte im Rahmen der Erstellung eines Zero-Trust-Konzepts für das gesamte Ökosystem des D-Stack hergeleitet werden.

  2. Die Vorgaben zur „IT-Sicherheit“ sind zurzeit noch wenig differenziert. Um die strategisch gewünschte Effizienz der Cloud-Angebote zu erreichen, sollten Sicherheitsvorgaben einer Staffelung folgen, so dass nicht für alle Cloud-Dienste die höchste Sicherheitsstufe mit entsprechenden Einschränkungen und Aufwänden erfüllen müssen. Dies sollte noch klarer herausgearbeitet werden.

    Bsp. Für eine solche Aufteilung der Cloud-Service Sicherheitsstufe (nicht inhaltlich, nur beispielhaft):

    • Sicherheitsstufe gering: BSI Grundschutz (kompakt)
    • Sicherheitsstufe mittel: BSI Grundschutz (erweitert)
    • Sicherheitsstufe hoch: BSI Grundschutz (erweitert) + C5

Workflowautomatisierung (LowCode)

  1. Workflow ohne E2E-Klammer bleibt isoliert und ist kein echtes „Ende-zu-Ende“, hier greifen auch Fach- und organisationsübegreifende Themen. Die nahe Orientierung am Workflow ist aber grundsätzlich richtig.
  2. Die Ausrichtung auf eine „...einfache Modellierung der Ablaufstrukturen und der Nachnutzung der Modelle in einer Ausführungsengine“ ermöglicht die leichtere Austauschbarkeit von IT-Lösungen für Ablauf-Engines und zahlt damit auf die strategischen Ziele ein. Hierzu sollte zeitnah eine Evaluation durchgeführt werden, um ein passendes (und souveränes) Format zu finden, das diesen Anforderungen gerecht wird und kompatibel mit passenden Software-Produkten (LowCode-Plattformen) ist.

Zusammenhang zu weiteren Aktivitäten

Inhalte sind anschlussfähig, die Umsetzung ist aber nicht koordiniert.

Portfolio, Roadmap und mehr

  1. Der D-Stack ist statisch formuliert, Strategien sind aber dynamisch. Daher stellt sich die Frage, wie mit Änderungen der Stack Elemente umgegangen wird?
  2. Bei den aufgeführten Beispielen sind nur bereits existierende staatliche Angebote oder geplante staatliche Angebote aufgeführt. Eine Nachnutzung bestehender privatwirtschaftlicher Lösungen ist nicht zu erkennen. Wie passt das mit den definierten Zielen (u.a. aus dem Koalitionsvertrag)? Wäre es nicht sinnvoll, Anforderungen für privatwirtschaftliche Lösungen zu definieren, sodass diese D-Stack-kompatibel zertifiziert werden können (vergleichbar mit dem Konzept GovStack) und für die regional zu betreibenden Anteile vom Deutschland-Stack genutzt werden können? Hier geht es vor allem auch um die notwendig IT-Infrastruktur für Fachplattformen und Fachverfahren. Siehe auch Cloud-Betriebsplattformen der DVC für die öffentliche Verwaltung auf Basis von IONOS / STACKIT.

Sonstiges

In diesem Abschnitt finden sich sonstige Anmerkungen, die während der Bearbeitung der Leitfragen entstanden sind, sich aber nicht direkt dort einordnen. Dieser Abschnitt nennt nur Unterbereiche, zu denen es tatsächlich Anmerkungen unsererseits gibt.

Strategie

  1. Die Beschreibung der Ziele konzentriert sich ausschließlich auf die Beschreibung des Scopes für das Vorhaben Deutschland-Stack (Was soll gemacht werden?) und einige Rahmenbedingungen. Welcher messbare Nutzen durch die Einführung eines Deutschland-Stacks für wen entstehen soll (Warum wird das Vorhaben gemacht?), bleibt offen. Um das Vorhaben über die kommenden Jahre, auch bei wechselnden Rahmenbedingungen, systematisch steuern zu können, muss der avisierte Nutzen messbar definiert und klar kommuniziert werden. [Siehe auch Bewertung „Umsetzungsbedingungen“ zum Abschnitt „Motivation“]

    Mögliche Nutzen:

    1. Reduktion der Zeit für die flächendeckende Einführung von eGovernement-Lösungen in Gesamtdeutschland
    2. Reduktion der Kosten für die gesamte Staats-IT (Bund/Land/Kommune) in Bezug auf Entwicklung und Betrieb von staatlichen IT-Lösungen.
    3. Reduktion der Abhängigkeit von außereuropäischen Technologieanbietern.
    4. Stärkung der nationalen / europäischen IT-Wirtschaft im internationalen Wettbewerb

  2. Die Strategie sollte die Ziele klar benennen, den allgemeinen Lösungsansatz (z. B. zentral bereitgestellte IT auf Basis privater und staatlicher Bausteine für die einfache Nachnutzung durch Bund, Land und Kommunen) und die für die Erreichung der Ziele notwendigen Maßnahmen (z. B. Entwicklung eines D-Stack, Einbeziehen der Privatwirtschaft, Bereitstellung des D-Stack, Anpassung der gesetzlichen Regelungen für die behördliche Nachnutzung, Incentivierung der Nachnutzung, Aufbau einer Governance für die Weiterentwicklung des D-Stacks, Messung des avisierten Nutzens, etc.). Für jede Maßnahme muss ein messbares Ergebnis definiert werden. [Siehe auch Bewertung „Umsetzungsbedingungen“ zum Abschnitt „Motivation“]

  3. Die bisherige Beteiligung der Länder ist unzureichend und muss in Zukunft besser strukturiert werden.

Architekturprinzipien

User Experience wird als Prinzip aufgegriffen aber nicht in den einzelnen Themenfeldern behandelt.

Hamburg stellt in dem Zusammenhang das UX/UI-Framework KERN zur Verfügung, welches möglicherweise Teil des D-Stacks werden könnte.

Portfolio, Roadmap und mehr

  1. Es ist unklar, was mit dem Begriff Portfolio im Kontext Deutschland-Stack gemeint ist. Sollten die Elemente des Deutschland-Stack gemeint sein, dann bitte Konsistenz herstellen zur Webseite Struktur Stack (https://deutschland-stack.gov.de/aufbau/)
  2. Abstimmung mit der durch den IT-Planungsrat erarbeiteten Deutschland-Architektur fehlt. Es sollte klar definiert werden, welche Elemente der Deutschland-Architektur der Deutschland-Stack abdeckt und welche nicht. Dabei sollte pro D-Stack Element klar sein, welche Services dieser bereitstellt, wie der Baustein genutzt werden kann (rechtliche, organisatorische und technische Voraussetzungen) und wie die Interoperabilität zu Nachbarsystemen (andere D-Stack-Elemente, eigene regionale IT-Lösungen, sonstige staatliche IT-Lösungen, IT-Lösungen der Verwaltungskunden) abgebildet wird. Es geht also weniger darum, womit der Baustein implementiert wird, sondern welcher Service von wem für welchen Zweck wie genutzt werden kann.
  3. Das Portfolio enthält keine fachlichen IT-Anwendungen mehr für Verwaltungsleistungen, wo die Regelungskompetenz beim Bund liegt und die Vollzugskompetenz bei den Ländern und Kommunen. Allein die Bereitstellung von Infrastruktur und Plattformfunktionalitäten wird den effizienten flächendeckenden Rollout von digitalen Lösungen für Verwaltungsleistungen nicht signifikant beschleunigen. Die Modernisierungsagenda vom BMDS sieht aber genau solche zentralen IT-Lösungen für Deutschland vor (z. B. die Zentralisierung der Portale für die internetbasierte Fahrzeugzulassung (iKfz) beim Kraftfahrtbundesamt). Auch wenn technisch gesehen diese zentralen Lösungen, nicht Teil vom D-Stack sein sollen, muss hier klar abgegrenzt werden, wer für die Teile der Deutschland-IT, die nicht vom Deutschland-Stack abgedeckt werden, verantwortlich ist und wie die Interoperabilität zwischen diesen Lösungsbausteinen zukünftig sichergestellt wird.