Deutschland-Stack - Stellungnahme Cloudogus zur 2. Konsultationsrunde

Diesen Beitrag haben wir auch im Rahmen des Beteiligungsverfahrens zum Deutschland-Stack über den offiziellen Kanal OpenCode geteilt.

Als mittelständisches Unternehmen in der Digitalindustrie, das seine Produkte als Open Source Software anbietet und seit fast 10 Jahren auch für den öffentlichen Dienst tätig ist, freuen wir uns, als Cloudogu GmbH auch in der zweiten Konsultationsrunde zum Deutschland-Stack Feedback zu geben.

Zusammenfassung

Wir sehen es als positives Signal, dass Rückmeldungen aus der ersten Konsultation bereits Einfluss auf die strategische Ausrichtung, Portfolio und Kriterien des Deutschland-Stacks genommen haben. Besonders erfreut nehmen wir zur Kenntnis, dass sich Teile unserer Forderungen aus der ersten Konsultation (siehe #428) im aktuellen Entwurf wiederfinden:

• Open Source, sowohl bei der bevorzugten Vergabe als auch bei Eigenentwicklungen im Rahmen des D-Stacks
• Dynamische Beschaffung, Nennung erster bestehender Marktplätze und Nachnutzung der Angebote der DVC
• Nennung von bestehenden Technologien wie SCS und KIPITZ

Wir sehen hier Schritte in die richtige Richtung und wünschen uns weitere Verfeinerung:

• Strategie: Konkretisierung - ist D-Stack verbindlich oder nicht?
• Portfolio: Durch Inventur weitere erfolgreiche Systeme finden und Nachnutzung fördern, beispielsweise OpenDesk, SWEC, etc.
• Beschaffung: Mittelstandsfreundliche Bedingungen schaffen
• Weitere Aktivitäten: Mehr Zusammenhänge herstellen oder abgrenzen, beispielsweise zu GovStack und Marktplätzen wie FIT-Store, EfA-Marktplatz und Cloud Service Portal, GovTechs Plattform Deutschland.
• Kriterien: Konkretisierung durch Nennung der Inhalte der Stufen des ersten Entwurfs
• Kriterium digitaler Souveränität: Begriff Open Source/freie Software definieren, abgrenzen von Openwashing, Source Available und Open Core.
• Technologiefelder konkretisieren und Prozess für regelmäßige Aktualisierung etablieren.
• Tech-Stack Landkarte: Als Open Source veröffentlichen. Übersicht wahren, beispielsweise durch Tech-Radars, Golden Paths, Alternativen.
• Vertrauen durch Aufführen von Quellen, Fakten und vor allem Referenzen schaffen.

Im Folgenden betrachten wir die Änderungen seit der ersten Konsultationsrunde und gehen dabei auf die konkreten Fragestellungen der zweiten Konsultationsrunde ein.

Gesamtbild

Dieser Abschnitt betrachtet die Seite “Gesamtbild” (“Zusammenhänge” im Seitenmenü) mit Ausnahme des Abschnitts ”Technologiefelder und Standards”. Aufgrund seiner technischen Tiefe widmet sich ihm ein separater Abschnitt.

Wir nehmen eine deutliche Schärfung der bestehenden Bereiche wie Motivation, Zusammenhänge und Portfolio wahr. Besonders die Technologiefelder konkretisieren viele Punkte wie Standards und Protokolle übersichtlich, ohne die Landkarte aufzublähen.

Strategie

Der neue Abschnitt “Strategie” schafft eine breitere politische Grundlage, vor allem durch die Belege. Er geht dabei weit über den bisher ausschließlich referenzierten Koalitionsvertrag hinaus. Mit Vorrang für Open Source Lösungen oder Lösungen europäisch souveräner Anbieter wird hier eine Forderung erfüllt, die in der öffentlichen Debatte um das Thema digitale Souveränität omnipräsent ist.

Die zusätzliche Klarstellung, dass “notwendige eigene Anteile an Lösungen” als Open Source entwickelt werden, kommt dem oft geforderten “Public Money, Public Code” nach. Dies gilt es jedoch auch zu liefern, denn bisher ist nur das Repository d-stack-home einsehbar, das Repository der Landkarte, erreichbar (noch) nicht. Wie schon in unserer Stellungnahme zum ersten Konsultationsverfahren #428 fordern wir hier einen transparenten Aufnahmeprozess durch das Veröffentlichen der Landkarte als Open Source. Dort kann eine transparente Diskussion über die Aufnahme weiterer Technologien stattfinden. Außerdem wäre die Pflege der Einträge durch Anbieter und Benutzende über diesen Prozess möglich, sowie eine Historie einsehbar.

Unklar bleibt im Bereich Strategie: Soll der Deutschland-Stack nun verbindlich sein oder nicht? Was ist unter “verbindlicher und fakultativer Nutzung” konkret zu verstehen?

Aus den “Erfahrungen bisheriger Umsetzungen und bestehender Umsetzungsbedingungen” werden Pfeiler gesetzt. Hier wäre eine Konkretisierung hilfreich, um welche Umsetzungen und Umsetzungsbedingungen es sich handelt.

Zusammenhang zu weiteren Aktivitäten

Der bereits vor der ersten Konsultation bestehende Abschnitt “Zusammenhang zu weiteren Aktivitäten” bietet jetzt mehr Klarheit. Die Ergänzung der föderalen Modernisierungsagenda erweitert das Potenzial des D-Stacks auf Länderebene. Die Klärung des Verhältnisses des D-Stacks zur Deutschen Verwaltungscloud (DVC) ist begrüßenswert und eine Nachnutzung der Vorarbeiten sinnvoll.

Auffällig ist, dass im aktuellen Stand die Erwähnung von GovStack entfallen ist. Hier wäre es interessant zu erfahren warum. Generell kann es auch hilfreich sein, Aktivitäten zu erwähnen, zu denen kein Zusammenhang besteht, damit diese Diskussionen nicht immer wieder entfachen.

Portfolio

Das Portfolio hat durch die drei genannten Elemente “Plattformkern”, “Fachagnostische Plattformen” und “Managed Services” eine Struktur erhalten. Die Nennung konkreter Beispiele EUDI-Wallet, FIT-Connect, KIPITZ und Marktplatz Deutschland Digital, DVC Portal und OpenCode schafft Praxisbezug. Wir halten es für sinnvoll, eine Inventur bestehender erfolgreicher Systeme im öffentlichen Dienst mit Fokus auf bereits etablierte, souveräne Technologien fortzusetzen. Weitere Beispiele sind OpenDesk von ZenDis und SWEC des ITZBunds. Diese sind auch fachagnostische Plattformen, jedoch in einer bestimmten Domäne (digitaler Arbeitsplatz bzw. Softwareentwicklung/Projektmanagement). Zweifelsfrei gibt es hier viele weitere Produkte oder Standards, denen der D-Stack zu einer Nachnutzung verhelfen könnte. Darin sehen wir eine der wichtigsten und am niedrigsten hängenden Aufgaben des D-Stacks.

Das Aufgreifen der Idee der Schaffung eines dynamischen Beschaffungssystems kann die Vergabe beschleunigen, Zugang für Startups und Mittelstand vereinfachen und Innovationen fördern. Das Erwähnen bestehender Marktplätze wie Marktplatz Deutschland Digital und DVC Portal schafft Zusammenhänge. Es ist jedoch unklar, wie dies genau zu verstehen ist - werden diese Teil des D-Stacks? Wie sieht es mit weiteren Marktplätzen aus wie FIT-Store, EfA-Marktplatz, Cloud Service Portal, GovTechs Plattform Deutschland aus - wird hier eine Konsolidierung stattfinden? Im Bereich der Beschaffung sehen wir eine besondere Chance, Innovationen voranzutreiben, beispielsweise durch eine KMU-Quote oder mittelstandsfreundliche Teilnahmebedingungen. Gerade kleine Unternehmen sind oft leichtgewichtig und innovativ, aber durch die übliche Vergabe benachteiligt. Sie verfügen nicht über personelle Ressourcen, Fachwissen, juristische Unterstützung oder Referenzen, um über Ausschreibungen an große Rahmenverträge zu kommen. Eine weitere Hilfe können Badges sein, wie man sie von manchen großen Einzelhandelsplattformen kennt, die visualisieren, wenn Produkte von KMU angeboten oder unterstützt werden.

Kriterien und Reifegrad

Bevor mit dem Abschnitt “Technologiefelder und Standards” ein tieferes Eintauchen in die Technik stattfindet, betrachtet der folgende Abschnitt die Seite “Kriterien und Reifegrad” (“Kriterien im Stack” im Seitenmenü).

Die deutliche Vereinfachung der Kriterien seit der ersten Konsultation hilft einerseits in der Praxis, vor allem denjenigen, die diese beachten sollen. An einigen Stellen geht die Vereinfachung jedoch auf Kosten der Klarheit. Manche Themen sind unkonkreter geworden, beispielsweise Marktrelevanz, Vertrauenswürdigkeit, Nachhaltigkeit und Digitale Souveränität. Hier würden die Inhalte der Stufen als Konkretisierung dienen - allein um zu verstehen, welche Aspekte bei diesem Kriterium berücksichtigt werden.

Bei digitaler Souveränität ist die Wechselfähigkeit zwischen Betreibern und Anbietern als Mindestbedingung, sowie zumindest die Nennung von Open Source sinnvoll. Die im ersten Entwurf noch unter den Stufen genannten Kriterien Anbietereinfluss und Gestaltungsfähigkeit (Produktpartizipation) halten wir gerade im öffentlichen Dienst für besonders wichtig. Unabhängig von den Stufen des ersten Entwurfs sollten diese Begriffe wieder als Konkretisierung oder Leitfragen des Kriteriums digitale Souveränität erwähnt werden. Weitergehend wäre eine Definition des Begriffes Open Source und/oder freier Software (beispielsweise durch OSI-kompatible Lizenz) und Abgrenzung oder explizite Erwähnung von Rahmenbedingungen sinnvoll. Hier sehen wir die Abgrenzung zu Openwashing, Source Available, Open Core. Außerdem sind Rechteinhaber/Codeowner (Firma vs. NPO/Konsortium/Verein/Stiftung) und der gültige Rechtsraum relevant. Beispiel: Zum einzigen Source Code Management im derzeitigen Tech-Stack GitLab (amerikanische Firma mit Open Core Modell) gibt es souveränere Alternativen, beispielsweise Forgejo (Open Source, Weiterentwicklung durch deutschen Verein Codeberg) oder SCM-Manager (Open Source, Weiterentwicklung und Support durch Cloudogu, also ein KMU aus Deutschland). Bei Interoperabilität wird Offenheit als ”begrüßenswerter Faktor” erwähnt. Ist das also keine Mindestbedingung?

Bei Zukunftsfähigkeit ist die Mindestbedingung, dass Lösungen kontinuierlich aktualisiert werden. Dies sollte konkretisiert werden, sodass es numerisch messbar ist, beispielsweise “mindestens alle n Wochen in den letzten m Monaten oder seit Beginn des Projekts”.

Technologiefelder und Standards

Dieser Abschnitt bezieht sich auf die Seite “Gesamtbild” (“Zusammenhänge” im Seitenmenü), Abschnitt “Technologiefelder und Standards” und damit konkret auf die zweite Frage des Konsultationsverfahrens: “Sind die priorisierten Technologiefelder mit den relevanten Technologien und Standards für den Deutschland-Stack unterlegt?”.

Zu einigen Technologiefeldern können wir konkrete Details aus unserer Erfahrung in der Entwicklung und dem Betrieb von cloud-nativen und KI-Anwendungen beitragen.

Agentische und Generative KI: Gerade in diesem Technologiefeld zeigt sich, wie wichtig es ist, einen Prozess für die Aktualisierung des D-Stacks von Anfang an mit einzuplanen. Das Feld ist noch neu und hochdynamisch. Beispielsweise zeichnet sich durch die Entwicklung der letzten Wochen ab, dass die Verbreitung des Model Context Protocol (MCP), das auch erst ein Jahr alt ist, wieder abnehmen könnte (Beispiel). Vergleichbar wie vor einem Jahr der Hype um MCP den Hype um Retrieval-Augmented Generation (RAG) abflachen ließ. Diese Entwicklung wird hier nicht enden. Insofern wären beispielsweise quartalsweise Aktualisierungen der D-Stack Technologiefelder eine gute Mindestbedingung.

DevSecOps und APIs: SBOM selbst ist kein Standard, sondern ein Konzept. Gängige Standards nennt beispielsweise die CISA: SPDX, CycloneDX und VEX. Neben Git und Prinzipien wie CI/CD Pipelines und IaC hat sich das Konzept von GitOps als cloud-natives Continuous Delivery etabliert. Die drei Punkte zu "Mechanismen" sind sehr allgemein gehalten. Diese sollten konkretisiert werden. Bei “Monitoring, Logging und Observability” ist unser Vorschlag “Observability (Monitoring, Logging, Tracing und Profiling)”, da Observability gängigerweise als Oberbegriff mit den vier genannten Säulen verstanden wird. Konkrete gängige Standards sind Prometheus (OpenMetrics) und OpenTelemetry. Bei “Mechanismen für Package Management und Distribution” ist OCI (Open Container Initiative) der gängigste Standard. Er hat sich vom Container Image zum generischen Standard entwickelt, über den auch SBOMs, Signaturen, Helm Charts, WebAssembly-Module und Machine-Learning-Modelle, etc. verteilt werden.

Managed Services und Cloud: Bei der Cloud sind die Konzepte einer Exit-Strategie und damit verbunden die Möglichkeit des Cloud-Switching als Umsetzung der Mindestbedingung Wechselfähigkeit (siehe digitale Souveränität) ergänzungswert. Cloud-Switching wird auch vom Data Act der EU gefordert (siehe Blog Post von Cloudogu). Hier sollte der D-Stack nicht nachstehen.

IT-Sicherheit: Bei der Sicherheit ist eine Konkretisierung zum Verhältnis von den genannten BSI IT-Grundschutz / C5 zu den gängigen Themen NIS2 / ISO 27001 hilfreich. Sieht der D-Stack ISO 27001 und/oder NIS2-Konformität als hinreichend an? Bei Angabe kryptographischer Algorithmen sind entweder genauere Spezifikationen (beispielsweise Schlüssellängen) nötig und/oder eine zeitliche Limitierung sinnvoll. Laut BSI ist beispielsweise das im D-Stack genannte RSA nur noch mit größeren Schlüssellängen zulässig. Erst kürzlich hat das BSI generelle Migrationsfristen zur Abkündigung klassischer asymmetrischer Verfahren in Hinblick auf Post-Quanten-Kryptographie veröffentlicht.

Tech-Stack Landkarte

Keinen Unterschied zur ersten Konsultation sehen wir bei der Tech-Stack Landkarte. Nach wie vor sehen wir das Finden der richtigen Balance zwischen Auswahl und Übersicht als entscheidend für die Nutzbarkeit und den Erfolg des D-Stacks. Durch die Schaffung der außerhalb der Landkarte dokumentierten Technologiefelder und Standards können die Standards aus der Landkarte entfernt werden, um Übersicht zu gewinnen. Es verblieben dann noch konkrete Technologien. Dass diese allein schon mehr als genug sein können, zeigt schon die riesige CNCF-Landscape, die als technologische Basis für die Darstellung des Tech-Stack dient. Auf Tech-Konferenzen taucht sie regelmäßig in sarkastischen Memes auf, um die Qual der Wahl bei der Auswahl der richtigen cloud-nativen Technologien zu visualisieren. Die Landkarte des D-Stack hat mit seinen domänenspezifischen Kriterien Potenzial, nützlicher zu sein als die CNCF-Landscape. Methoden, die man aus Tech-Radars kennt, können hier ergänzend konkretisiert werden. Vielleicht lässt sich ein “Golden Path” Ansatz umsetzen, der die gängigsten Lösungen und mögliche Integrationen für gängige Anwendungsfälle aufzeigt.

Auf der Landkarte sollten außerdem Fakten und Quellen gelistet sein. Auch souveränere Alternativen sollten direkt angezeigt werden.

Ein vertrauensbildende Maßnahme für Technologien können Referenzen sein: Wo in Deutschland, Europa, im öffentlichen Dienst, bei welchen Behörden kommt ein Produkt zum Einsatz und wie viele User verwenden es?