Aktuelle Rückmeldungen

In unserer Rubrik "Aktuelle Rückmeldungen" finden Sie regelmäßige Updates und Veröffentlichungen zu den Leitfragen, die im Rahmen des Konsultationsprozesses diskutiert werden.

Wir sind bestrebt, eine transparente und offene Diskussion zu fördern und unsere Erkenntnisse sowie die eingegangenen Vorschläge und Kommentare der Leitfragen mit Ihnen auf dieser Seite zu teilen. Die eigentliche Online-Konsultation findet über Open CoDE statt. Durch das FIT-AB formulierte Leitfragen können dort von den Teilnehmenden des Konsultationsprozesses kommentiert werden.

Nach der offiziellen Veröffentlichung der Leitfragen für die Teilnehmenden, werden diese auch auf dieser Seite für Sie bereitgestellt. Dabei sind sie nach den Themenschwerpunkten der Leitfragen strukturiert. Nur Leitfrage 12, welche das Thema der Open CoDE Kommentarfunktion thematisiert, wird hier nicht gespiegelt, da sie ledigleich den Impuls hatte, die Diskussion innerhalb Open CoDE anzuregen und auf bestehende Kommentare zu referenzieren.

Letzte Aktualisierung: 08.05.2024

Nutzendengruppen und Nutzendenreisen

03. Zu berücksichtigende Nutzenden- bzw. Prozessteilnehmende

Datum der Veröffentlichung: 25.10.2023
Anzahl eingegangener Antworten: 47
Issue # in GitLab: #136
Leitfrage 03

Welche Nutzenden- bzw. Prozessteilnehmende sollten Ihrer Meinung nach bei der Erarbeitung von Nutzendenreisen beachtet werden?

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

S.B - editiert am 01.11.2023

Bei der Beschreibung der Nutzergruppen zum OZG wäre es wichtig, davon auszugehen, dass nicht nur "affine" Nutzer vom OZG betroffen sind, sondern in naher Zukunft der digitale Zugang zur Verwaltung obligatorisch sein dürfte und entsprechend Zugangshürden gering auszugestalten sind. Erwartbar wäre auch, dass nicht nur klassische Kunden der Verwaltung auftreten (also bspw. Antragsteller) sondern dass auch andere betroffene von Verwaltungshandeln im weiteren Sinn zu berücksichtigen sind. Das können bspw. Personen (auch mit einer nicht-EU Staatsangehörigkeit) sein, die Widerspruch zu einem OWiG einlegen wollen, oder nicht geschäftsfähige Personen und deren Vertretungsberechtigte. Hierbei dürfte auf Seiten der Kunden der Verwaltung die Erwartungshaltung entwickelt sein, dass OZG-Prozesse vollständig, Ende-zu-Ende digitalisiert sind und nicht ein digitaler Antrag einen postalischen Bescheid nach sich zieht. Ideal wäre in diesem Zusammenhang auch, die Nutzergruppen und ihre Anliegen zu priorisieren: für die erfolgreiche Digitalisierung ist die optimale digitale Gestaltung der Schnittstelle und der digitalen Prozesse zwischen Kunden und Verwaltung sicher wertvoller als die innerbetrieblichen Anforderungen der Verwaltung selbst.

DIHK.I.K - editiert am 01.11.2023

Bei Entwickelnden und Betreibenden sollte unterschieden werden nach Nähe der Organisation zum öffentlichen Dienst: Verwaltungseigene Dienstleister, etablierter Dienstleister der öffentlichen Hand, markteintretendes Unternehmen (bspw. Startup). Von vorne nach hinten steigt der Bedarf an Transparenz (aktuelle, vollständige, strukturierte Informationen im Internet) über Rahmenbedingungen an

Es fehlen Vereine / non Profits und Behörden als Organisationsnutzer

M.P - editiert am 09.11.2023

Ergänzend zu den Aufgeführten sehen wir die Einbeziehung der folgenden Personas für die Nutzendenreisen als sinnvoll, nicht unbedingt als Reisende, aber auch als Mitdenkende.

IT Entwickelnde, Betreibende

Softwareentwickler

Open-Source Entwickler und deren Vertriebsgesellschaften

Betreiber der Infrastruktur Plattform

IT-Experten

Anwender

Vertreter der Zivilgesellschaft

Berater

Politik

Entscheidungsträger

Beauftragte zur Sicherstellung der Barriere Freiheit

Datenschutzbeauftragte

Cisco_Issue_3

T.G - editiert am 12.01.2024

IBM regt folgende Änderungen / Ergänzungen der relevanten Nutzendengruppen an (siehe „231024_Konsultationsprozess_Online-Webseminar_I, Seite 15):

• Bürgerinnen und Bürger: Wir möchten an dieser Stelle auf die Verwendung auf „Bürgernahe Sprache“ und ggfs. Fremdsprachen anregen. Als zusätzliche Gruppe / Persona sollte es auch möglich sein, mit einer entsprechenden Vollmacht in Vertretung eines Antragstellenden zu handeln.

• Organisation und Unternehmen: Organisation und Unternehmen zeichnen sich u.a. daraus, dass oft mehrere Beteiligte in der Bearbeitung einer OZG-Leistung involviert sind. Hierdurch gibt es Bedarf nach Themenbereichen wie Vertreterregelungen, Freigabe / Zeichnungsprozess z.B. nach dem 4-Augenprinzip etc.

• Verwaltungsmitarbeitende: Generelle Unterscheidung zwischen Sachbearbeitende für Massenverfahren und Wissensarbeitsplätzen.

Veraltungsmitarbeitende können auch die Rolle eines Antragstellenden wahrnehmen, z.B. Rolle „Einkauf“ oder auch Antragstellende für Förderleistungen. In diesem Fall empfehlen wir, die Verwaltungsmitarbeitende der Nutzendengruppe „Organisation und Unternehmen“ zuzuordnen.

• IT-Entwickelnde, Betreibende: Für diese Gruppe sind unserer Erfahrung nach weniger Nutzendenreisen (User Journeys) relevant. Interessanter sind hier technische Rahmenbedingungen aufgrund vorhandener zu integrierender Systeme und strategi-scher Vorgaben hinsichtlich zukünftiger Betreiberszenarien (z.B. Containerisierung, Cloud-Technologien etc.).

• Politik: (neuer Rolle) Verfasser von Gesetzestext, Richtlinien, Vorschriften etc. . Der Erfahrung nach werden Vorschriften nicht von IT-Kräften geschrieben. Wir empfehlen, frühestmöglich im Rahmen eines Governance-Prozesses IT-Expertise in Vorschriften einfließen zu lassen. So kann sichergestellt werden, dass die fachlichen Vorgaben umsetzbar und ggfs. automatisiert umgesetzt werden können. Analog ist zu prüfen, ob existierende Vorschriften geändert werden sollten, um diese digitalisierungsfreundlich zu gestalten.

R.P - editiert am 02.11.2023

buergerservice.org e.V.:

Seit vielen Jahren lautet die Forderung der E-Government-Fachleute: "... die Usability muss besser werden. E-Government muss so einfach gehen wie eine Bestellung bei Amazon". Dabei verkennt die Fachwelt einen wesentlichen Aspekt: beim Beispiel "Bestellung bei Amazon" übernimmmt der User so gut wie keine Verantwortung. Gefällt die bestellte Ware nicht, kann auf einfachste Weise die Bestellung rückgängig gemacht werden. So wurde es möglich, dass sogar eine One-Klick-Bestellung angeboten wurde.\ Beim E-Government hingegen, muss der User sehr umfangreich Verantwortung übernehmen. Bei fehlerhaftem Handeln wird er mit mehr oder weniger harten Konsequenzen konfrontiert. Durch die neue Dimension "Verantwortung übernehmen" muss deshalb zur Leitfrage 03. "Zu berücksichtigende Nutzenden- bzw. Prozessteilehmende" eine zusätzliche Instanz vorgesehen werden. Diese Instanz (Arbeitsbegriff: Wissensvermittler) muss Aufklärungsarbeit für die User betreiben. So lernen die User mit der Verantwortung umzugehen und sie werden deutlich schneller die E-Government-Angebote annehmen und nutzen.

Die OZG-Rahmenarchitektur sollte unterschiedlichste Akteure zur "Wissensvermittlung" unterstützen:

Kommunen als Schnittstelle zu den Bürgerinnen und Bürgern;

Schulen (alle Arten inkl. Hochschulen und Universitäten);

Situativ Betroffene (der Autohändler im Umfeld von iKfz, die Personalabteilung im Umfeld Führungszeugnis online beantragen, die Schule beim Untersuchungsberechtigungsschein, die Hochschulen im Umfeld der Wohnsitz An-,Ab- oder Ummeldung, die Architekten im Bereich des elektronischen Bauantrags usw.);

Betreuungscenter;

Krankenhäuser;

Polizei (polizeiliche Kriminalprävention, ....);

Zur Unterstützung kann die OZG-Rahmenarchitektur Hilfsmittel bereitstellen:

Testsysteme/Schulungssysteme;

Lehrmaterial;

Multiplikatorenschulungen;

Codebausteine für die Entwicklergemeinde (Hackathons, ....);

Varianten der OZG-Diensteangebote für einen optimalen Einsatz auf Smart-Terminals bei den unterschiedlichsten Akteuren (s.o.);

Mehrwerte beim Online-Ausweisen mit dem Deutschen Personalausweis für den alltäglichen Eigennutzen der Bürgerinnen und Bürger anbieten (z.B. Passwortmanager mit eID, eID-Schutzmaßnahmen gegen "Hater" usw.)

S.M - original vom 03.11.2023

Bundesagentur für Arbeit: - Bürgerinnen und Bürger - Unternehmen - Behörden / Verwaltung - Träger / Vereine / gemeinnützige Organisationen - Betreiber der IT-Landschaften

M.S - original vom 03.11.2023

Open Source Business Alliance - Bundesverband für digitale Souveränität e.V.:

(Ehrenamtliche) Open-Source-Communities und Open-Source-Stiftungen: Im Open-Source-Bereich gehören zu den IT-Entwickelnden nicht nur privatwirtschaftliche Unternehmen, sondern oft auch (ehrenamtliche) Communities oder Stiftungen (wie z.B. The Document Foundation, die Linux Foundation u.a.), die – oft in Zusammenarbeit mit privatwirtschaftlichen Unternehmen oder wissenschaftlichen Einrichtungen - die Software oder relevante Standards weiter entwickeln. Diese Nutzendengruppe muss gesondert berücksichtigt werden. Die Debatten um den Cyber Resilience Act haben gezeigt, dass an ehrenamtliche Entwicklungscommunities nicht die gleichen gesetzlichen Anforderungen mit Blick auf Verpflichtungen gestellt werden können, wie an privatwirtschaftliche Unternehmen, die mit der Erstellung und dem Vertrieb der Software Geld verdienen, da die ehrenamtlichen Akteure oft nicht über die Ressourcen und die Möglichkeiten verfügen um diese Anforderungen zu erfüllen, wie es bei Unternehmen der Fall ist (siehe u.a. https://background.tagesspiegel.de/cybersecurity/der-cyber-resilience-act-hat-open-source-software-nicht-verstanden). Gleichwohl tragen ehrenamtliche Open-Source-Communities und Open-Source-Stiftungen sowie andere nicht kommerziell aufgestellte Entwicklungsakteure (z.B. aus dem wissenschaftlichen Umfeld) entscheidend zur Weiterentwicklung und Verbesserung von Open Source Software und offenen Standards bei. Da auch in den föderalen IT-Architekturrichtlinien u.a. in SR8 „Einsatz von Open Source“ auf die Bedeutung von Open Source Software verwiesen wird, muss diese Nutzendengruppe mit ihren speziellen Anforderungen gesondert berücksichtigt werden.

Überschneidungen zwischen Nutzendengruppen: Es muss berücksichtigt werden, dass es zu Überschneidungen zwischen den einzelnen Nutzendengruppen kommen kann und dies eigene Anforderungen mit sich bringen kann, die berücksichtigt werden müssen. So gibt es bspw. Fälle, in denen innerhalb einer Verwaltung Open Source Software selbst von den IT-Mitarbeitenden (weiter-)entwickelt wird. Als Beispiel sei hier das Oberverwaltungsgericht Rheinland-Pfalz genannt, siehe u.a. https://gitlab.opencode.de/ovgrlp und https://github.com/Oberverwaltungsgericht-Rheinland-Pfalz. Einige Verwaltungen schrecken allerdings immer noch davor zurück, ihren Angestellten die Selbstentwicklung oder Mitarbeit an Open-Source-Projekten zu ermöglichen. Zu den Gründen gehört oft eine Unsicherheit, welche Implikationen diese Entwicklungsarbeit mit sich bringt, wenn die Beamt:innen in Doppelrolle als Verwaltungsangestellte und als Software-Entwickler:innen aktiv sind. Um diese Unsicherheiten zu adressieren sollte diese spezielle Nutzendengruppe separat mitgedacht werden.

IT-Mitarbeitende der Verwaltung: Neben Sachbearbeitenden sollten auch die IT-Mitarbeitenden der Verwaltung in der Gruppe der Verwaltungsmitarbeitenden gesondert mitgedacht werden. Denn es sind am Ende die Administrierenden in den einzelnen Behörden, die IT-Lösungen aufsetzen, pflegen und als Ansprechpartner für den Rest der Verwaltung zur Verfügung stehen müssen. Wie oben bereits ausgeführt, fungieren Verwaltungsangestellt manchmal auch als Entwickelnde der Software.

Verwaltungsmitarbeitende aus Vergabe- und Beschaffungsstellen: Zusätzlich zu der Gruppe „Einkauf“ müssen auch die Verwaltungsmitarbeitenden aus Vergabestellen gesondert mitgedacht werden, falls diese nicht unter „Einkauf“ im breiteren Sinne bereits mitgemeint sind. Andernfalls kann es in der Praxis passieren, dass die übergeordneten strategischen Ziele einer föderierten IT-Architektur im Alltag daran scheitern, dass sie von einzelnen Mitarbeitenden in konkreten Beschaffungs- und Vergabeverfahren nicht berücksichtigt werden. In den föderalen IT-Architekturrichtlinien wird u.a. in SR8 „Einsatz von Open Source“ der Vorrang von Open Source Software formuliert: „Open Source Lösungen sind Nicht-Open Source Lösungen vorzuziehen, sofern geeignet und wirtschaftlich“. In der Praxis ist es aber so, dass oftmals weiterhin proprietäre Lösungen beschafft werden, obwohl gleichwertige Open-Source-Lösungen zur Verfügung stünden. Die Gründe hierfür liegen oft in einer Unsicherheit der Beschaffungs- und Vergabestellen, da sie über den in den föderalen IT-Architekturrichtlinien formulierten Vorrang von Open Source nicht informiert sind oder sogar überzeugt sind, eine rechtssichere Beschaffung von Open Source Software sei aus irgendwelchen Gründen grundsätzlich nicht möglich. Aus diesem Grund müssen insbesondere alle Verwaltungsmitarbeitenden, die an Bedarfsformulierung, Leistungsbeschreibung, Beschaffung und Vergabe beteiligt sind, in den Nutzendengruppen berücksichtigt werden.

Öffentliche IT-Dienstleister: Öffentliche IT-Dienstleister spielen eine besondere Rolle bei der Verwaltungsdigitalisierung und der Umsetzung des OZG. Aus der bereit gestellten Grafik geht nicht hervor, ob sie eher der Nutzendengruppe „Organisationen und Unternehmen“ und/oder der Nutzendengruppe „IT-Entwickelnde, Betreibende“ zuzuordnen sind. Ggf. ist es sinnvoll, die öffentlichen IT-Dienstleister separat zu berücksichtigen, da sie eine besondere Stellung zwischen den Verwaltungen und der Privatwirtschaft einnehmen.

T.S - original vom 09.11.2023

Im Sinne einer Nutzendenzentrierung sollte die Kategorie "Bürgerinnen und Bürger" auf jeden Fall unterteilt werden, um neben der Barrierefreiheit für Menschen mit Handicaps auch der digitalen Inklusion Rechnung zu tragen. Damit sollte ein stärkerer Fokus auf folgende Gruppen gelegt werden:

Geflüchtete

sozial benachteiligte Menschen

Menschen aus bildungsfernen Milieus

ältere Menschen

Es sollte so vermieden werden, dass digitale OZG-Services in erster Linie für digitale affine Nutzende konzipiert und realisiert werden. Die digitalen Services sollten Verwaltungsleistungen in ihrer Komplexität für die o.g. Zielgruppen reduzieren und verlässliche Guidance geben.

A.S - original vom 14.11.2023

Zu den bereits beschriebenen:

IT-Architekten der Behörden

IT-Strategen und Fachanwendungsbetreuer in den Behörden

T.B - editiert am 12.01.2024

In Ergänzung der bereits aufgeführten Nutzenden möchten wir gerne folgende Vorschläge/Anregungen auf Basis unserer (Projekt-)Erfahrungen mit einbringen: Bürgerinnen und Bürger: - Einwohnende aus Drittstaaten: Durch das Fachkräfteeinwanderungsgesetz ergeben sich neue Herausforderungen in der Authentifizierung von Personen und Verifizierung von Nachweisen. Das sollte im digitalen Prozess berücksichtigt werden. Zusätzlich sollten weitere Fremdsprachen neben der englischen Sprache mit berücksichtigt werden - Nutzende sollten nicht nur Online-affine Bürgerinnen und Bürger sein. Dieser Personenkreis kommt auch mit komplexeren Prozessen klar. Fokus sollte auch auf den Personen liegen, die sich mit digitalen Lösungen schwer tun - hier kann ein erheblicher Mehrwert geschaffen werden Verwaltungsmitarbeitende: - Unsere Projekterfahrungen zeigen, dass der für die OZG-Umsetzung und den "Change-Gedanken" verantwortliche Personenkreis innerhalb einer Verwaltungsorganisation oft selber nicht das notwendige IT-Knowhow besitzt, um solch Vorhaben effektiv und flächendeckend begleiten zu können. Oft sind es Fachexperten, die für die technische Umsetzung und prozessuale Ausgestaltung innerhalb der Behörde verantwortlich sind. Es sollten Nutzende wie "Umsetzungsverantwortliche", "IT-affine und nicht IT-affine Nutzende", "technische Vordenker und Visionäre" sowie die Fachebene berücksichtigt werden. - Eine wichtige Rolle spielen die Juristen auf Bundes- und Landesebene. Oft kommt es vor, dass technische Lösungen bereitgestellt werden, aber die dazugehörige Gesetzgebung noch zu novellieren ist. Eine frühzeitige Einbindung entsprechender Juristen kann dies verhindern. - Auch sollten die jeweiligen IT-Landesrechenzentren und Dienstleister frühzeitig mit eingebunden werden, um zentrale IT-Infrastrukturen entsprechend anpassen/vorbereiten zu können.

M.S - original vom 17.11.2023

NKR: Die Verwaltungspraxis ist komplexer als "1 antragstellende Person <--> 1 bearbeitende Behörde"

Bürgerinnen und Bürger - EU-Einwohnende - Online-Affine Bürgerinnen und Bürger - Enkel als Hilfe über Großeltern - Nachbarschaftshilfe beim Vorausfüllen von Formularen - Private Vermieter

Organisationen und Unternehmen - Freiberufler - Beratende Zunft (Steuerberater, Rechtsanwälte, Fördermittelberater usw.) mit teilweise eigenen Lösungen wie Steuerberaterportal mit Berufsträgereigenschaft, Bundesnotarkammer mit Online-GmbH-Gründung - Ärztinnen Ärzte - Arzthelferinnen und Arzthelfer - Konzerne mit unterschiedlichen Vertretungsberechtigungen auch durch Nicht-EU-Bürger (also ohne eID) - Kammermitarbeitende

Verwaltungsmitarbeitende - Sachbearbeitende - Einkauf - Haushalt - Buchhaltung - Vergabestelle - Dienstleistersteuerung - Vertragsmanagement

IT-Entwickelnde, Betreibende - Komponenten-Entwickler - Business Analyst - Fachverfahrenshersteller

M.N.AKDB - original vom 17.11.2023

Bei der Erarbeitung der Nutzendenreise für das OZG sollte berücksichtigt werden, dass in Zukunft der digitale Zugang zur Verwaltung der Regelfall sein wird, wobei die Zugangshürden minimal sein sollten. Dies betrifft nicht nur typische Verwaltungskunden wie Antragsteller, sondern auch Personen mit besonderen Bedürfnissen, wie Nicht-EU-Bürger oder nicht geschäftsfähige Personen und ihre Vertreter. Es wird erwartet, dass OZG-Prozesse vollständig digitalisiert sind, sodass digitale Anträge nicht zu postalischen Bescheiden führen. Priorität sollte auf der optimalen digitalen Gestaltung der Schnittstellen und Prozesse zwischen Kunden und Verwaltung liegen, wobei das Prinzip "Digital Only" im Vordergrund steht.

Ergänzend zu oben Gesagten und den bereits adressierten Stakeholdern der Bürger:innen, Verwaltungsmitarbeitende, Organisationen und Unternehmen,IT-Entwickelnde/Betreibende sowie Politik ist im ersten Schritt die notwendige Differenzierung nach den betroffenen Staats-/Verwaltungsebenen erforderlich. Verwaltungsmitarbeiter auf kommunaler Ebene haben andere Bedürfnisse und dienstliche Anforderungen an Mitarbeiter in zentralen Bundeseinrichtungen etc. Deshalb ist Differenzierung der jeweiligen Stakeholder-Gruppe eng an der untersuchten Nutzendenreise erforderlich.

Ebenfalls sollte die Gruppe der Stakeholder noch um cross-funktionales Expertenteam von UX-Designer, Produktmanagern, Entwicklern, Content-Strategen und Datenanalysten erweitert werden. Dies garantiert die notwendige Souveränität bei der Methodik und Fachlichkeit.

D.T.OZG.S - original vom 17.11.2023

Aus Sicht der Deutschen Telekom sollte das „Nutzendenmodell für die OZG-Rahmenarchitektur“ in zwei Ebenen unterteilt werden. Dieses Ebenen-Modell folgt der Annahme, dass die konkrete Nutzung der OZG-Rahmenarchitektur bzw. des Zielbildes der OZG-Rahmenarchitektur als Grundlage für die konkrete Realisierung von OZG/Verwaltungsleistungen im Fokus steht.

Ebene 1: Personengruppen, die mit der Definition und Umsetzung der Verwaltungsleistung und des digitalen Angebots betraut sind.

-> Unmittelbare/direkt Nutzende des Zielbildes der OZG-Rahmenarchitektur

Ebene 2: Personengruppen, die Verwaltungsleistungen in Anspruch nehmen

-> Mittelbar/Indirekt Nutzende des Zielbildes der OZG-Rahmenarchitektur

Ebene 1: Unmittelbar/Direkt Nutzende des Zielbildes der OZG-Rahmenarchitektur

Als Hauptnutzer des Zielbildes der OZG-Rahmenarchitektur sehen wir alle am Ausbau der Digitalisierung der Verwaltung Deutschlands beteiligten Stakeholder. Dieses sind insb. die IT-Dienstleister der Verwaltung auf Bundes-, Landes- und kommunaler Seite. Im Kern sind die IT-Dienstleister der Verwaltung dafür verantwortlich die OZG-Rahmenarchitektur mittels Netze, Hard- und Software (on premise oder in der Cloud), Schnittstellen, Serviceprozessen sowie eigenem und externen Personal praktisch umzusetzen und operativ zu betreiben. Innerhalb dieser Ebene sind die Organisationen enthalten, die das Digitale Angebot umsetzen und betreiben.

Das Zielbild der OZG-Rahmenarchitektur bildet aber darüber hinaus eine zentrale Grundlage für alle Partner bzw. Lieferanten der IT-Dienstleister der Verwaltung also der gesamten IT-Wirtschaft, die für die öffentliche Verwaltung IT-Dienstleistungen und Produkte entwickelt, weiterentwickelt und betreibt.

Weitere Hauptadressaten sind diejenigen Institutionen und Personen, die den rechtlichen, organisatorischen, finanziellen und technischen Rahmen für die Verwaltungsleistung bzw. die Online-/OZG-dienste verantworten. Mithilfe der OZG-Rahmenarchitektur kann diesen Personengruppen vermittelt werden, welchen Status die Fähigkeiten und Funktionen im Rahmen der OZG-Umsetzung besitzen. Die Definition von Verwaltungsleistungen kann dann auf Grundlage des IST oder unter bewusster Entscheidung eines notwendigen Migrationsplans erfolgen. Insb. sind dabei folgende Stakeholder zu nennen:

Abgeordnete von EU-Parlament, Bundestag, Landtagen ggf. mit Mandanten in Ausschüssen (die für Digitalisierung einzelner Verwaltungsleistungen oder Finanzierung zuständig sind) sowie gewählte Mitglieder der Kommunalvertretungen,

Behörden, die Verwaltungsleistungen beaufsichtigen bzw. Onlinedienste verantworten/definieren (Verwaltungsleitung, Referenten, Vergabestellen).

Darüber hinaus bildet das Zielbild der OZG-Rahmenarchitektur eine wichtige „Leitplanke“ für die deutsche und europäische Gesetzgebung. Dieses vor dem Hintergrund, dass im Rahmen des Digitalchecks möglichst alle Gesetze zukünftig digital gestaltet werden sollen. Die OZG-Rahmenarchitektur bildet insofern eine sehr wichtige Orientierung- und Prüfbasis für den Digitalcheck.

Zusammenfassend sehen wir folgende unmittelbare/direkte Nutzer des Zielbildes der OZG-Rahmenarchitektur:

IT-Dienstleister der Verwaltung auf Bundes-, Landes- und kommunaler Seite

Partner bzw. Lieferanten der IT-Dienstleister der Verwaltung also die gesamten IT-Wirtschaft

Entscheidungsinstanzen für die Verwaltungsdigitalisierung (Digitalisierungs-Strategien, Digitalisierungsgesetze, Digitalhaushalte, Vergaben etc.)

Gesetzgebungsinstanzen in Deutschland und Europa (Stichwort „Digitalcheck“)

Ebene 2: Mittelbar/Indirekt Nutzende des Zielbildes der OZG-Rahmenarchitektur

Unter diese Kategorie fallen alle Personen, die die Verwaltungsleistungen, welche auf der Basis der OZG-Rahmenarchitektur erbracht werden, tatsächlich in Anspruch nehmen. Dies sind sowohl Bürger:innen als auch Mitarbeiter:innen von Verwaltungen/Behörden, Unternehmen, Vereinen, und anderen Organisationen. Grundsätzlich brauchen diese Personengruppen keine direkte Kenntnis über die OZG-Rahmenarchitektur haben, sondern sie haben Interesse daran, welche Verwaltungsleistungen bzw. Services auf der OZG-Rahmenarchitektur realisiert wurden, und möchten diese aus ihren Fachaufgaben heraus performant, sicher, ergonomisch und barrierefrei nutzen.

Darüber hinaus sind auch die interessierte Öffentlichkeit, Presse, Verbände und die Wissenschaft und Forschung indirekte Nutzende der OZG-Rahmenarchitektur, da sie z.B. an Digitalisierungsstudien bzw. Statistiken Interesse haben, ohne direkt selbst die digitalen Verwaltungsleistungen in Anspruch zu nehmen.

Zusammenfassend sehen wir folgende mittelbar/indirekt Nutzende des Zielbildes der OZG-Rahmenarchitektur:

Bürger:innen

Verwaltungsmittarbeiter:innen

Mitarbeiter:innen von Unternehmen

Mitarbeiter:innen von Verbänden

Mitarbeiter:innen von Wissenschaft und Forschung

Mitarbeiter:innen von Presse

Mitarbeiter:innen von Parteien

Auf eine Besonderheit bei aufgeführten Nutzenden möchten wir in diesem Zusammenhang noch hinweisen:

Nutzende können als natürliche Person in verschiedenen Rollen agieren, z.B. als Mitarbeiter:innen eines Unternehmens, einer Behörde und einer Organisation. Deshalb sollte das Zielbild der OZG-Rahmenarchitektur auch das Zusammenspiel von Unternehmens- bzw. Organisations-Identitäten und deren Mitarbeiter:innen mit zugewiesenem Rollen und Rechte-Konzept berücksichtigen. Ein Lösungsansatz hierfür bestünde darin, eine weitere Nutzendengruppe oder eine spezielle hierarchische Interaktion in das Nutzenden-Modell mit aufzunehmen.

Frage03_OZGRahmenArchitektur_Konsultationsprozess

D.K - original vom 19.11.2023

Bei der Erarbeitung von Nutzendenreisen sollten die verschiedenen Stakeholder berücksichtigt werden, darunter Bürgerinnen und Bürger, Unternehmen, Verwaltungsbeschäftigte, Beschäftigte von IT-Dienstleistern sowie Verbände. Es ist wichtig, die Bedürfnisse und Erwartungen aller Nutzergruppen zu verstehen, um nutzerzentrierte Lösungen zu entwickeln. Die Einbeziehung der verschiedenen Prozessteilnehmenden ermöglicht eine ganzheitliche Betrachtung der Verwaltungsprozesse und trägt dazu bei, die Akzeptanz und Effizienz der digitalen Verwaltung zu steigern.

D.S - original vom 19.11.2023

Die Frage ist leider unklar gestellt. Um welchen Prozess geht es? Den Prozess zur Entwicklung digitaler Angebote, oder den Verwaltungsprozess? Bei ersterem ist das Schaubild nicht ganz komplett. Es fehlt hier jedoch die Ministerialbürokratie, welche Vorgaben als Gesetz oder Verordnung ggf. anpassen, entfernen oder neu entwickeln muss, um eine sinnstiftende Digitalisierung möglich zu machen. Deren juristische Kompetenz ist bei der Entwicklung von digitalen Angeboten zwingend erforderlich. Außerdem fehlt hier noch der Datenschutz, welcher zwingend zu beteiligen ist, um nicht von diesem auf den letzten Metern ausgebremst zu werden. Ist der Verwaltungsprozess gemeint (was wir vermuten), dann sind die Software- Entwickler und -Betreiber aus dem Schaubild zu entfernen, weil sie keine Beteiligten des Verwaltungsprozesses und damit einer Nutzendenreise sind. Wenn im Schaubild Kommunikationsprozesse visualisiert werden sollten, dann wären neben den zuständigen Behörden auch Behörden zu integrieren, die Zustimmungspflichtig sind, einen Beitrag zum Ergebnis des Prozesses leisten oder Informationen zu einem Prozess zuarbeite

B.R - original vom 20.11.2023

Alle Instanzen der ausführenden Verwaltung durch Repräsentanten (z.B. Kommunale Landesverbände der Länder), Bürger, Dienstleister (ins. Fachverfahrenshersteller), IT-Mitarbeitende und Sachbearbeitende der Verwaltungen.

TSA.S.W - original vom 20.11.2023

Da das Ziel nur eine soweit wie möglich vollständige Digitalisierung der Verwaltung sein kann, so unsere Überzeugung als TSA Public Service GmbH, müssen auch sämtliche Gruppen von Personen und Organisationen, also Bürgerinnen und Bürger, Unternehmen und Verbände, als Verwaltungskunden betrachtet werden.

Da Verwaltungshandeln Teil des Alltags ist, müssen entsprechend auch alle gesellschaftlichen und wirtschaftlichen Gruppen betrachtet werden.

Gleichzeitig sollte die Erarbeitung von Nutzendenreisen auch die Beteiligung von Verbänden und Fachverfahrensherstellern im Kontext der Weiterentwicklung von bestehenden und zukünftig umgesetzten Lösungen betrachtet werden, beispielsweise im Hinblick auf praktische Erfahrungen, die wertvolles Feedback geben können.

L.S - original vom 20.11.2023

Die Designprozesse bei Microsoft sind menschengeleitet. Wir empfehlen am Anfang eines Projektes zur Erkennung der wichtigsten Personen eine s.g. Ökosystemübersicht zu erstellen und damit zu ermitteln, welche Rollen und Nutzenden involviert sind. Diese erstellt man am besten in einem Arbeitstreffen zu Beginn mit allen internen Rollen, so haben alle mal die Möglichkeit sich einzubringen. Der Termin kann auch zur Präzisierung der Rollen genutzt werden. Das Angebot muss immer über den bloßen Erhalt der rechtlichen Rahmen (wie EN 301549) hinausgehen und intuitive Angebote für unterschiedliche Zielgruppen (intern und extern) erschaffen.

Relevante Informationen und das Persona Spectrum findet sich hier: https://inclusive.microsoft.design/InclusiveDesignInAction

Zur automatisierten Erkennung und Behebung von Problemen mit der Barrierefreiheit empfiehlt es sich bestehende Lösungen anzusehen und zu nutzen: https://accessibilityinsights.io/docs/en/windows/overview

Wir empfehlen weiter die Nutzung von offenen Toolkits und Marktstandards https://www.microsoft.com/en-us/haxtoolkit

J.E - original vom 20.11.2023

Unseres Erachtens müssen im Kontext der Digitalisierung sukzessive alle an den Verwaltungsprozessen beteiligten Personengruppen (Bürgerinnen und Bürger, Organisationen, Unternehmen, Verwaltungsmitarbeiterinnen und -mitarbeiter, …) und Untergruppen bei der Erarbeitung beachtet werden. Die Beteiligung ergibt sich u.E. aus der jeweils betrachteten Verwaltungsleistung.

M.M - editiert am 21.11.2023

Im Mittelpunkt sollten die Domainexperten in der Verwaltung stehen.

Diese Domainexperten sind Dienstleister für den Bürger.

Der Bürger kann barrierefreie, digitale und transparente Dienste erwarten.

Das Handeln der Domainexperten in der Verwaltung basiert auf Gesetztestexten.

Die Politik entwirft Gesetztestexte, welche die Verwaltungsmitarbeiten (Domainexperten) umsetzen müssen.

Diese Gesetztestexte führen zu Verwaltungsabläufen - oft in unbekannten Ausmaß.

Dementsprechend braucht Politik ein Monitoring der durch Gesetztestexte verursachte Kosten.

Somit kann das Handeln der Politik auf die Verwaltung abgestimmt werden.

Organisationen, Unternehmen, IT-Entwickelnde und Betreibende sind Dienstleister und sollten die Domainexperten enablen, ihr auf Gesetztestexten basierendes Handeln selbst digitalisieren und abändern zu können.

Alle Akteure müssen vom gleichen semantisch beschriebenen und verknüpften interoperablen Wissen zu Leistungen, deren Gesetzesgrundlagen und benötigten Standards ausgehen. Keine "One-Size-Fits-All"-Lösung. Alle müssen auf der gleichen Grundlage arbeiten können, aber für sie angepasste Aufbereitungen dieses Wissens erhalten. Als Bürger sind mir andere Punkte wichtig (oder relevant) denn als Verwaltungsmitarbeiter.

Politik sollte explizit einbezogen werden. Nicht nur als Quelle eines Zielbildes, sondern auch als Nutzer eines solchen. Der Vorteil für Politik steht schon da (Abschätzung von Folgen/Kosten/... neuer Vorhaben). Es hängt aber auch die Aufgabe dran, Vorschrifften auch entsprechend passend zu definieren, dass sie sinnvoll digitalisiert werden können. (Altes) Beispiel ist der Zwang von händischen Unterschrifften, der eine effektive Digitalisierung unterbindet. Die Forderungen neuer Gesetze etc. müssen auch die technische Basis berücksichtigen. Ich kann als Politiker nicht nur sagen "macht das so", sondern muss auch daran denken, was man dafür alles braucht.

S.H - editiert am 20.11.2023

Was unklar ist, vor Beantwortung der Frage:

Über welchen Value Stream reden wir?

a) Etablierung neuer OZG Services in Form von Projekten unter Anwendung der Rahmenarchitektur, um diese live zu bekommen?

b) Bereitstellung bestehender Prozesse auf Infrastruktur (incl. Sachbearbeitung), wenn diese „live“ sind.

c) beides?

Reden wir von Nutzende oder Stakeholder per se?

Weitere aus der Praxis relevante:

Politik ggf. weiter differenzieren, da unterschiedliche Zielsetzungen – (Legislative, Exekutive, Judikative)

IT differenzieren oder genauer beschreiben. Interne/externe IT-Dienstleister der unterschiedlichen Größe bis hinunter zum IT-Admin, interne IT´s der Kommunen

Wichtig! Mitarbeitende der Sachbearbeitung im Fokus (!), denn das schönste Bürgerportal funktioniert nicht, wenn die teilweise noch nicht durchgängigen Prozesse der Sachbearbeitungen schlecht laufen. Bspw. aufgrund von medienbrüchigen, oder „UX-fernen“ Toolsets.

E.S - original vom 20.11.2023

Zur besseren Strukturierung unterscheiden wir als Bitkom in der folgenden Antwort unter Front- und Back-End-Nutzerinnen und Externen.

Front-End

Bürgerinnen und Bürger

Nicht digital-affine Personen: Hier gilt es, die zu erwartende Altersstruktur- und Digitalaffinität und -kompetenz zu berücksichtigen. So muss ein digitaler BAföG-Antrag anders ausgestaltet sein als ein digitaler Rentenantrag.

Marginalisierte Gruppen, Minderheiten und deren Vertretungen: Nutzendenreisen müssen inklusiv gestaltet sein, z.B. in dem die Angebote in mehreren Sprachen angeboten werden und Anforderungen wie die leichte Sprache erfüllt werden.

Organisationen, Unternehmen und wirtschaftliche Tätige

Ausländische Unternehmen: Unternehmen aus dem Ausland müssen Services genauso nutzen können, wie in Deutschland ansässige Unternehmen.

Verschiedene adressierte Antragsbearbeiter in und von Unternehmen z.B. der externe Steuerberater oder die Ingenieurin

Stellvertretende Dritte wie z.B. Steuerberaterinnen, Rechtsanwälte, gesetzliche Vertreter und Bevollmächtigte

Back-End

Verwaltungsmitarbeitende: Die Ergebnisse der Online-Dienste sollten einen Wiedererkennungswert haben, damit sich die Mitarbeitende nicht immer wieder in neue Formulare einarbeiten müssen.

Verwaltungsmitarbeitende aller föderalen Ebenen und involvierter öffentlicher Organisationen wie z.B. Gerichte: Dadurch wird sichergestellt, dass die Anliegen und Bedürfnisse der Hauptnutzer digitaler Services und Prozesse einbezogen werden.

Hauptpersonalräte und Schwerbehindertenvertretungen: Sie sollten ebenso in die Erstellung von Nutzendenreisen einbezogen werden, um besondere Bedürfnisse abbilden zu können.

Informationssicherheitsbeauftragte und Datenschutzbeauftragte: Sie können entsprechende Fallstricke in dem Bereich bereits frühzeitig identifizieren. Im Umkehrschluss können diese Beteiligten häufig auch praktikable und rechtssichere Lösungen vorschlagen.

Beschaffungs- und Vergabestellen von IT-Services: Sie können dank ihrer Erfahrung wertvollen Input liefern.

Kammern: Sie und ihre Anforderungen wurden in der bisherigen OZG-Umsetzung nicht ausreichend berücksichtigt.

Externe

Fachpersonen und Expertinnen: Sie werden nicht als Nutzende befragt, sondern aufgrund ihres Wissens. Sie dienen ebenfalls als Erfahrungsträgerinnen für Nutzendenreisen und die Entwicklung und Einbindung digitaler Lösungen.

Politik / gesetzgebende Institutionen, um einen medienbruchfreien Prozess von der Gesetzgebung ausgehend zu schaffen.

Generell gilt bei der Erstellung der Nutzenreisen auch wirklich mit den Nutzerinnen und Nutzern zu sprechen und nicht z.B. mit ihren Führungskräften oder entsprechende Fachpersonen. Ebenso ist eine „einfache Nutzendenreise“ nicht ausreichend, um die Komplexität abzubilden. Es bietet sich hier an, mehr in Richtung Service Blueprint zu gehen.

B.S - original vom 20.11.2023

Aus Sicht der GKV:

Den Bürger als Ausgangspunkt des Prozesses zu betrachten ist zu begrüßen, allerdings sollte beachtet werden, dass auch dritte (Be-treuer, Angehörige, Firmen; Bevollmächtigte) für den Bürger Anträge stellen wollen bzw. müssen.

Insbesondere im Umfeld der GKV kommt es regelmäßig vor, dass hier dritte die Interessen des Bürgers vertreten, wenn dieser aufgrund von Alter oder Krankheit dazu nicht mehr in der Lage ist.

Die Möglichkeit dies zu tun, sollte durch die Digitalisierung nicht unnötig erschwert und Vertretungsregeln etabliert werden. Aufgrund der mit dem Thema verbunden Datenschutz-thematik, sollte auch hier eine zentrale Lö-sung gefunden werden, die nur einmal durch die jeweiligen Datenschützer geprüft und freigegeben werden muss.

R.W - original vom 20.11.2023

Die AWV fokussiert sich in ihren Anmerkungen zum Konsultationsprozess in erster Linie auf die Anforderungen von Kommunikation und Lösungen zwischen Wirtschaft und Verwaltung.

Als Prozessteilnehmende möchten wir uns dafür einsetzen, dass Unternehmen in unterschiedlichen Konstellationen berücksichtigt werden. Als Nutzendengruppe fehlen unserer Meinung nach die "freien Berufe". Unter Bürgern und Unternehmen sollte zudem noch die Rolle "Berechtigter Dritter" Erwähnung finden (z. B. "Shared Service Center").

Zu berücksichtigen ist, dass kleine, mittlere und große Unternehmen unterschiedliche Anforderungen und Möglichkeiten der Nutzung von digitalen Verwaltungsleistungen haben. Dies gilt für die Formen der Wahrnehmung digitaler Dienstleistungen und die technischen Möglichkeiten aufgrund der installierten technischen Infrastrukturen. Auch übernehmen Dienstleister teilweise Teile der fachlichen Verarbeitung und der Datenverarbeitung von Unternehmen und müssen im Berechtigungskonzept und in der Anbindung entsprechend berücksichtigt werden.

A.S - original vom 20.11.2023

Aus Sicht der DigitalService GmbH des Bundes: - Die vier bisher identifizierten Nutzendengruppen sehen wir auch als die relevantesten an. Für die Nutzendenreisen wäre es aus unserer Sicht besonders wichtig, mit Personen aus den identifizierten Gruppen eine sinnvolle Mischung aus qualitativen und quantitativer Recherche (bspw. Interviews, Befragungen, Shadowing, Auswertung von verfügbaren Metadaten) zu führen, um diese nicht nur auf Annahmen aufzubauen. - Bei den IT-Entwickelnden sollten auch die speziellen Bedarfe der Zivilgesellschaft, Unternehmen und in-house IT-Systemhäuser (wie das IT-Systemhaus der Bundesagentur für Arbeit) berücksichtigt werden.

S.G - original vom 20.11.2023

Wie bereits in Leitfrage 02 ausgeführt, ist die Nutzenden-Sicht die entscheidende bei der Digitalisierung. Aus Sicht der VISION Consulting GmbH sollten deshalb bei der Erarbeitung folgende Nutzenden- und Prozessteilnehmende beachtet werden:

-          Hauptnutzer sind die Bürger und Bürgerinnen. Für diese sind also Nutzendenreisen zu entwickeln: Bürger will Leistung xy nutzen (aktuell unabhängig davon, ob die Bürger dies online, per App, per Post, per Telefon oder persönlich vor Ort wollen, zukünftig ggfls. mit weniger Möglichkeiten), was passiert alles, bis die Leistung erfüllt ist.

-          Weitere wesentliche Nutzer sind Unternehmen. Für diese sind also Nutzendenreisen zu entwickeln: Unternehmen will Leistung xy nutzen, was passiert alles, bis die Leistung erfüllt ist.

-          Weitere wesentliche Nutzer sind Organisationen (non-profit, Vereine, etc.). Für diese sind also Nutzendenreisen zu entwickeln: Unternehmen will Leistung xy nutzen, was passiert alles, bis die Leistung erfüllt ist.

-          Darüber hinaus bestehen bereits Lösungen für die Inanspruchnahme grenzüberschreitender Verwaltungsleistungen innerhalb der EU (Wirtschaft, Bürger, Organisationen). Hierfür sind abgestimmte Nutzenden-Reisen mit den EU-Partnern anzustreben.

-          Weitere wesentliche Nutzer bzw. Prozessteilnehmende sind die Mitarbeiter der Leistungserbringer (Verwaltung in Bund, Länder, Gemeinden). Für diese sind also Nutzendenreisen zu entwickeln (Antrag auf Leistung xy wird durch den Bürger gestellt (entsprechend der oben angegebenen Möglichkeiten): Wie läuft der Antrag intern durch die Verwaltung, bis die Leistung erfüllt ist.

-          Weitere Prozessteilnehmende sind Auftragnehmer (öffentlich und privat), die an der Entwicklung bzw. Weiterentwicklung der Systeme/Funktionen und am Betrieb derselben beteiligt sind. Hierfür sind Nutzendenreisen zu entwickeln, die die Zusammenarbeit der verschiedenen Auftragnehmer mit den jeweiligen Auftraggebern (Bund, Länder, Gemeinden) abbilden.

S.L.B - original vom 20.11.2023

Aus Sicht der Bundessteuerberaterkammer ist neben der Betrachtung einzelner (end-)nutzerzentrierter Anwendungsfälle auch die Betrachtung ganzer Organisationen bzw. Unternehmen an diesem Gesamtvorhaben wichtig.

So sind Vertretungskonstellationen bisher nicht „mitgedacht“. Gerade Unternehmen lagern eine Vielzahl von Prozessen an Bevollmächtigte aus. Hier fehlt es bisher an konkreten organisatorischen, gesetzlichen sowie technischen Richtlinien, sodass die bisherigen Realisierungskonzepte stark auseinander gehen. Eine Vereinheitlichung wäre an dieser Stelle wünschenswert.

Insbesondere mit der Einführung föderierter Identitäten, müssen Prozesse von Ende-zu-Ende gedacht werden. Mit der digitalen Steuerberateridentität ist es beispielsweise möglich sich an der Steuerberaterplattform über den neuen Personalweis (eID) zu authentifizieren. Die festgestellte Berufsträgereigenschaft gilt dann als Berechtigung und autorisiert zur Teilnahme an verschiedenen Fachprozessen.

So werden schon heute die Vollmachtsdaten der Mandanten der identifizierten Berufsträger elektronisch an die Finanzverwaltung über eine Vollmachtsdatenbank übermittelt. Unter Nutzung der digitalen Steuerberateridentität erfolgt die Kommunikation mit Finanzgerichten elektronisch über das besondere elektronische Steuerberaterpostfach. Auch können über das zentrale OZG-Antragsportal der Steuerberaterkammern vereinheitlichte Verwaltungsprozesse schon heute genutzt werden. Alle Prozesse werden mit der digitalen Steuerberateridentität abgewickelt.

Eben diese schon bestehenden Identitäten und Prozesse sollten bei der Betrachtung im Rahmen der OZG-Rahmenarchitektur nicht außer Acht gelassen werden.

Auch wenn die Berücksichtigung aller Nutzenden illusorisch ist, wäre es sinnvoll durch Ausarbeiten von Gemeinsamkeiten so viel Stakeholdergruppen, wie möglich zu finden und durch dieses Vorhaben anzusprechen. Der nun gestartete Konsultationsprozess ist sicherlich ein richtiger Weg, um diese Gruppen herausbilden zu können.

SEITENBAU - original vom 20.11.2023

Besonders bei den Nutzendengruppen Bürgerinnen und Bürger, Organisationen und Unternehmen sowie Verwaltungsmitarbeitende sollte die Heterogenität berücksichtigt werden, die sich z.B. durch den Grad der IT-Affinität, durch das Alter (Erwartungshaltung, altersbedingte Beeinträchtigungen,...), Bildungsgrad oder Herkunft ergibt. Beachtung gilt auch behinderten Menschen, die auf eine barrierefrei Anwendung angewiesen sind.

Evtl. ist es sinnvoll "kombinierte Nutzende" zu beachten (z.B. beide Elternteile bei einem Elterngeldprozess oder Bauherr/Architekt bei einem Bauantrag).

Bei der Nutzendengruppe Verwaltungsmitarbeitende kann darüber hinaus für die Identifikation der Nutzenden den Schritten der Leistungsbereitstellung und -bearbeitung gefolgt werden: - Redakteure: Beschreibung der Leistungen - Verantwortliche für den Onlinedienst: Verlinkung/Veröffentlichung/Aktivierung sowie Parametrisierung des Onlinediensts - Sachbearbeiter - ...

E.H - editiert am 27.01.2024

Antwort von Bundesamt für Migration und Flüchtlinge (BAMF):

Es darf keinen Ausschluss eines Personenkreis bei einer Nutzerreise geben. Die Prozesse sind so zu gestalten, dass jeder daran teilhaben kann.

Zur Zielgruppe sollen auch ausländische Staatsangehörige aus Nicht-EU-Staaten gehören, insbesondere Asylsuchende, Asylantragstellende und Geduldete (die keinen elektronischen Aufenthaltstitel) haben.

Dabei ist auch darauf hinzuweisen, dass auch die ausländischen Staatsangehörigen, die einen elektronischen AT oder die eine ID-Karte für EU-Bürger haben, diese Identifikationsmittel noch relativ selten nutzen, jedenfalls nicht häufiger als die eID-Funktion des Personalausweises von Deutschen genutzt wird (auch die deutsche eID wird noch vergleichsweise selten genutzt). BAMF interagiert in zahlreichen Fachprozessen mit ausländischen Staatsangehörigen, die weder über einen Standardidentitätsnachweis in der Europäischen Union noch in Deutschland verfügen. Ein Zugang ohne Standardidentitätsattribute aus dem Personalausweis, Aufenthaltstitel, usw. ist für die Authentifizierung erforderlich, um dieser Gruppe auch digitalen Zugang an den OZG-Diensten des BAMF zu gewähren Erforderlich ist der Zugang zu einem Authentifizierungsmittel, dass grundsätzlich allen Personenkreisen zur Verfügung gestellt werden kann. Dies muss zur Nachnutzung zur Verfügung stehen, wenn das "Elster-Zertifikat" im Bürgerkonto nicht mehr genutzt werden kann. Dies war bisher noch eine Möglichkeit zur Authentifizierung auch für diejenigen, die kein eID-Dokument haben.

Zur Zielgruppe sollen auch Personen ohne Deutsch- (und Englisch-) Kenntnisse gehören, weshalb die Mehrsprachigkeit-/Übersetzungsfunktion des Behördenportals sowie der Antragsformulare wichtig ist.

Ein weiterer wichtiger Aspekt ist auch die Teilhabe aller Menschen. Die Barrierefreiheit der Systeme muss von Anfang an mitgedacht werden und auch umgesetzt werden. Hier ist ein Potential vorhanden, beeinträchtigten Menschen Chancengleichheit zu ermöglichen.

Auf die Nutzendenreise sollten auch Datenschützer mit modernen Architekturkenntnissen mitgenommen werden, um nicht das Unmögliche zu fordern und zugleich die Möglichkeiten einer verteilten Architektur mit einzubringen.

Weiterhin sollen Nutzende berücksichtigt werden, die neben dem Portal auch digitale API-Schnittstellen für automatisierte Prozesse nutzen wollen, um direkt mit ihren eigenen Anwendungen mit einer Behörde interagieren zu können. Im Fall von BAMF sind das Träger mit ihren Backendsystemen, die Sprachkurse, Integrationskurse, Dolmetscher usw. für das BAMF anbieten. Eine manuelle Eingabe am Portal und Übermittlung der Daten muss hier strukturiert und authentifiziert durch eine juristische Person (Träger-Identifikation) oder vertretende Person erfolgen

Zur Zielgruppe des Ende-zu-Ende-OZG-Prozesses sollen auch die Gerichte (z.B. Verwaltungsgerichte) gehören.

Zudem: Das Recht auf einen Papier-Antrag gilt weiterhin. D.h., die Teilhabe und freie Wahl der Verfahrensart sollte verankert werden und "Papierantragstellende" müssen im Prozess mit berücksichtigt werden → es sollte jedoch keinen komplett andersartigen Prozess für Papieranträge geben, sondern Papierantragseingang sollte möglichst schnell in digitalen Prozess münden (z.B. durch ersetzendes Scannen). (dies gilt für Anträge von Bürgern; hingegen gilt für Unternehmen: digital only)

F.K - editiert am 28.11.2023

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen:

**Bürgerinnen und Bürger ** - Studieninteressierte/Studienbewerber/Fachkräfte/Ausbildungsbewerber (außerhalb von EU) ohne Aufenthaltstitel
- (sie benötigen Studienplatz für Aufenthaltstitel und können daher nicht auf Online-Dienste zugreifen mangels Aufenthaltstitel) - Studierende und ihr besonderes Verhältnis zur Hochschule, (Immatrikulationsverhältnis), viele Leistungen werden nicht über öffentliche Verwaltungsportale abgerufen (Beurlaubungsanträge, Mitteilungspflichten, Exmatrikulationsbescheinigung – diese finden im Rahmen eines Immatrikulationsverhältnisses mit nur einer Hochschule statt)

**Organisationen und Unternehmen ** - NGOs wie Museen bei Kulturgutausfuhr - Behörden wie Baubehörden im Bereich Denkmalschutz oder Denkmalbescheinigung für Finanzamt über Bürger beantragt kann direkt an Finanzamt geschickt werden - Hochschulen

**Verwaltungsmitarbeitende ** - Zuliefernde Künstler, Forscher, Professoren, Mitarbeiter auf Fachseite z.B. Für Stellungnahme oder Antrag die nicht üblicherweise mit Verwaltungssystemen arbeiten - Verwaltungsmitarbeitende der Hochschulen: Sachbearbeitende (die digitale Anträge „backstage“ bearbeiten), z.B. Studierendenbüros, Studiensekretariate, Prüfungsämter usw.

**IT-Entwickelnde, Betreibende ** - Open Source Communities - Campusmanagementsystem-Hersteller, SfH (Stiftung für Hochschulzulassung), uni assist e.V., weitere SaaS im Hochschulkontext, z.B. PIM - Landes- und kommunale IT-Dienstleister, z.B. Hessische Zentrale für Datenverarbeitung

A.K - original vom 20.11.2023

Unternehmen entlang der Top100 Leistungen

Bürgerinnen und Bürger aber konkret nach Personas, der tatsächlich Betroffenen (mehrstufiger Prozess denkbar, der zunächst je Anwendungsbereich Nutzergruppen und Personas identifiziert)

Öffentliche IT-Dienstleister

Fitko

Privatrechtliche Dienstleister

Standardisierungsregime z. B. DIN

hier ist ein mehrstufiger Prozess adäquat, der zunächst je Anwendungsbereich Nutzergruppen und

A.K - original vom 20.11.2023

Der Fokus bei den föderalen Architekturrichtlinien liegt auf der IT der Bundesverwaltung. Diese Architekturrichtlinien lassen die Sicht der Bürgerinnen und Bürger sowie Unternehmen als Nutzende entsprechend außer Acht. Die föderalen Architekturrichtlinien eigenen sich als Grundlage für eine Spezialisierung und Erweiterung der Richtlinien für das OZG. Die Richtlinien für das OZG müssten auch allgemeine Annahmen über die IT der Nutzenden sowie allgemeine Vorgaben für Web-Standards für Nutzbarkeit und Performanz enthalten.

Bekanntheit der föderalen IT-Architekturrichtlinien

Zugänglichkeit und Aktualität der Informationen  Format als PDF

Keine Architekturreviews analog zu Bund / Maßnahmenmeldung im Zuge der HH-Aufstellung

Die Architekturrichtlinien stellen weitgehend den „Common Sense“ einer verantwortungsvollen IT-Umsetzung für die Verwaltung dar, damit sind die Architekturrichtlinien aber eher generisch und unkonkret. Einerseits führt das dazu, dass eine große Vielfalt an Lösungen z.B. Interoperabilität jeweils für sich beansprucht, dies in der Summe unterschiedlicher Schnittstellen und Produkte nicht mehr der Fall ist. Andererseits gibt es Interpretationsspielräume, die dazu führen, dass auch Lösungen akzeptabel scheinen, die eigentlich nicht die Vorgaben erfüllen. Empfehlung: Die generischen Vorgaben sollten weiter konkretisiert werden um Zweideutigkeit auszuschließen. Z.B. „API First“  nur noch erfüllt, wenn alle APIs als REST-Services ausgeprägt sind und die zugehörige Schnittstellenbeschreibung im Format OpenAPI 3.0 in Open CoDE publiziert ist.

T.K - editiert am 27.11.2023

Sammlung CDO-MID Sachsen-Anhalt und Vertreter von Kommunen des Landes:

• In welche Kategorie fallen IT-Dienstleister, wie z.B. Dataport?

• Zentrale Kommunale Dienstleister sollten mit einbezogen werden - siehe Anmerkung zuvor

• Vielleicht auch Begleitung durch Hochschulen?

OZG.R - original vom 21.11.2023

IT-Dienstleister fallen in die Kategorie IT-Entwickelnde und Betreibende.

AS - original vom 20.11.2023

Wichtige Voraussetzung für die Auswahl relevanter Zielgruppen wäre, den Scope der anvisierten Rahmenarchitektur zu kennen. Wir gehen davon aus, dass zum jetzigen Zeitpunkt der Zielbilderstellung der Fokus auf Seiten der Sachbearbeitung liegen wird.

Aus sachbearbeitenden Sicht: Verwaltungsmitarbeiter (insbesondere auf kommunaler Ebene), aber auch Vereine und Verbände, Bildungseinrichtungen und Unternehmen des öffentlichen Rechts

Aus entwickelnden Sicht: Fachverfahrenshersteller, Betreiber, Entwickler, Support und Administratoren

Aus politischer/gesetzlicher Sicht: Datenschutzbeauftragte, Gesetzgeber und OZG-/Digitalisierungsbeauftragte

Aus antragstellenden Sicht: stellvertretende Dritte wie z.B. gesetzliche Vertretungsberechtigte und Bevollmächtigte

Für eine umfassende, vergleichende Betrachtung von User-Journeys sollten fachspezifische Domänen wie z. B. Gewerbe, Bildung, Familie & Kind etc. berücksichtigt werden.

J.P - original vom 21.11.2023

Antworten Team PwC: - Einbindung der Vollzugsebene der jeweiligen Verwaltungsleistung (Kommune bei kommunalem OD) - „Online-affin“ streichen, Einbindung einer heterogenen Gesellschaft (insb. ältere Personengruppen) - Fachlichkeit im Sinne der Rechtsaufsicht für eine Leistung - Priorität weniger bei Nutzerreise IT-Dienstleister, sondern bei anderen Gruppen - Nutzendenreisen mit Supportfunktionen flankieren (Inklusion durch Befähigung)

M.K - original vom 22.11.2023

Antworten des PB-OZG-EU-OOTS der Registermodernisierung

Bei der Betrachtung der bereits erarbeiteten Nutzendenreisen schlagen wir vor zwischen IT-Entwickelnden und IT-Betreibenden zu unterscheiden, da deren Informationsbedarfe und -stände stark voneinander variieren. Geprüft werden sollte zudem inwiefern Unternehmen und Organisationen auseinandergezogen werden kann. Ggf. unterscheiden sich gerad Unternehmen von (halb-)staatlichen Organisation bezüglich ihrer Erwartungen, Wünsche und Entwicklungsständen.

Zudem sehen wir folgende Akteure unterteilt nach den jeweils vorgegebenen Clustern:

1. Bürgerinnen und Bürger Besonders auch nicht digitalaffine Bürgerinnen sollten in Nutzendenreisen bedacht werden, um die Komplexität der Prozesse zu reduzieren.

2. Organisationen - Gemeinnützige Vereine - Verbände

3. Unternehmen - Unternehmen in Deutschland - Unternehmen im EU-Ausland - Einzelgewerbetreibende - Krankenkassen

4. Verwaltungsmitarbeitende - Sachbearbeitung (im Rahmen der Nutzung von ODs und der Rolle als "Backoffice)), - Verwaltungsmitarbeiter aller föderaler Ebenen - "Konfiguratoren" für die Konfiguration von eingekauften EfA-Online-Dienste - Einkauf von EfA-Online-Diensten - Registerführende Stellen - Registerverantwortliche Stelle

5. IT-Entwickelnde - Fachverfahrens-hersteller - Softwareentwickler - Start-Ups

6. IT-Betreibende - Cloudbetreiber (in DEU) - Hyperscaler (AWS, Google) - Inhouse-Betreiber (Bund, Länder, Kommunen) - Mitarbeiter:innen in Rechenzentren zur technischen Anbindung von EfA-ODs - Fachverfahrens-hersteller als Betreiber SaaS-Fachverfahren - Mitarbeiter:innen von Betreibern von EfA-ODs, von Kommunikations- und Basisinfrastruktur und Fachverfahren

M.H - original vom 24.11.2023

Universtität Duisburg-Essen, HISinOne-Cm.nrw: Bei der Gestaltung von Nutzer:innenreisen im Kontext der OZG-Umsetzung an Hochschulen ist es essenziell, verschiedene Nutzenden- bzw. Prozessteilnehmende zu berücksichtigen.

Studieninteressierte spielen eine zentrale Rolle, da ihre Erfahrungen den Bewerbungs- und Zulassungsprozess prägen. Studierende als Hauptnutzergruppe müssen in allen Aspekten des Hochschullebens, von der Einschreibung bis zum Abschluss, beachtet werden. Das Verwaltungspersonal ist entscheidend für die Optimierung interner Prozesse und Schnittstellen.

Lehrende benötigen unterstützende Tools für ihre Lehr- und Forschungsaktivitäten. Forschende sollten im Hinblick auf Datenmanagement und Forschungskollaborationen berücksichtigt werden.

Internationale Studierende und Forschende erfordern besondere Aufmerksamkeit, um ihre spezifischen Bedürfnisse im Hinblick auf Mobilität und Integration zu erfüllen. Arbeitgeber:innen sind für die Entwicklung praxisrelevanter Bildungsangebote wichtig.

Die Perspektive von Eltern und Angehörigen kann für die Gestaltung von Informations- und Unterstützungsangeboten relevant sein.

Schließlich sind Behörden und Partnerinstitutionen entscheidend für die Prozesskette, z.B. Durchlässigkeit im Bildungssektor.

J.H - original vom 27.11.2023

Wichtig wäre aus unserer Sicht zu berücksichtigen, dass im Rahmen von Antragsverfahren häufig nicht nur die Betroffenen selbst, sondern sie über Dritte agieren. Mitarbeiterinnen von Beratungsbüros, Nachbarschaftsbüros, Rechtsanwaltskanzleien sind gerade bei komplexeren Antragsverfahren eher die Regel als die Ausnahme. Im Rahmen der Nutzer:innenreise sollte daher Antragsteller:innen von Vertretungsberichtigte / Mandatsträger:innen / o.s.f. unterschieden werden können.

A.M - original vom 27.11.2023

Antworten ekom21 KGRZ Hessen

Kommunale IT-Dienstleister, die bisher in der OZG-Umsetzung ein Vielzahl von Leistungen umgesetzt haben und ihre Erfahrungen und das Nutzerfeedback einbringen können.

Softwarehersteller mit langjährigen Erfahrungen und Kenntnissen über die Automation, Digitalisierung und Design von Fachprozessen innerhalb der Verwaltung.

Konsortien, Unternehmensverbünde, Kooperationen, die bereits Erfahrungen in der Erarbeitung und Umsetzung gemeinsamen IT-Architekturen für Verwaltungen haben und über die theoretischen, vor allem aber über die praxisrelevanten Grundlagen verfügen.

Kommunen als wesentliche Schnittstelle zu Bürgerinnen / Bürgern und Unternehmen und Nutzer von Backend-Prozessen.

Unternehmen, Verbände und Poweruser, die Antragsprozesse mit hohen Fallzahlen nutzen und hohe Anforderungen an Effizienz und Effektivität von Schnittstellen.

K.G - editiert am 07.12.2023

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister:

Endnutzer, sprich Bürger*innen oder Unternehmen, welche die Anträge stellen. Dies sind die Zielgruppen, die das Produkt oder die Dienstleistung benötigen. Es ist wichtig, ihre Bedürfnisse, Herausforderungen und Ziele zu verstehen.

Entscheidungsträger in Verwaltung und Politik: Diese Personen treffen Entscheidungen und sind in der Regel nicht unbedingt die Endnutzer. Es ist wichtig zu verstehen, was sie bei der Entscheidungsfindung beeinflusst.

Die Sachbearbeiterinnen in den Behörden können wertvolle Einblicke in die Probleme und Herausforderungen der Bürgerinnen / Unternehmen geben. Sie können auch Informationen darüber liefern, in welcher Art und Weise die Nutzer*innen das Produkt oder die Dienstleistung benötigen, welche Probleme auftreten können und welche rechtlichen Rahmenbedingungen zu beachten sind.

Personen mit besonderen Bedürfnissen, wie im Ausland lebende deutsche Staatsbürgerinnen, Nicht-EU-Bürgerinnen oder nicht geschäftsfähige Personen und ihre Vertretenden.

Grundsätzlich ist eine Differenzierung nach den betroffenen Staats-/Verwaltungsebenen erforderlich. Verwaltungsmitarbeiter auf kommunaler Ebene haben andere Bedürfnisse und dienstliche Anforderungen an Mitarbeiter in zentralen Bundeseinrichtungen etc. Deshalb ist Differenzierung der jeweiligen Stakeholder-Gruppe eng an der untersuchten Nutzendenreise erforderlich. - Ebenfalls sollte die Gruppe der Stakeholder noch um cross-funktionales Expertenteam von UX-Designer, Produktmanagern, Entwicklern, Content-Strategen und Datenanalysten erweitert werden. Dies garantiert die notwendige Souveränität bei der Methodik und Fachlichkeit. - Die Fachverfahrenshersteller sollten an der Erarbeitung der User-Stories beteiligt werden, um sicherzustellen, dass das Produkt tatsächlich alle Anforderungen und Bedürfnisse der Nutzer*innen abdeckt. - Kommunale IT-Dienstleister bringen ihre kommunale und praxisbezogene Perspektive als Umsetzer und Multiplikatoren in den Prozess ein.

G.B - editiert am 29.01.2024

Neben den klassischen Vertreterinnen der digitalen Zivilgesellschaft im Rahmen technischer Konsultationsprozesse ist es dringend nötig Vertreterinnen von Organisationen der intendierten Nutzer*innengruppen der entsprechenden Verwaltungsleistung im Sinne einer Technikfolgenabschätzung einzubinden und aktiv anzusprechen. Hierbei ist auch zu evaluieren in wie weit entsprechende Organisationen die Gruppe der Betroffenen repräsentien. Diese sollten anhand des Konzeptes des Lebenslage u.a. im Bereich der Sozialträger identifizierbar sein.

Den etablierten Best-Practices der Softwareentwicklung für B2B2C Produkte folgend scheint Zielführend sowohl die Mitarbeiterinnen der Verwaltung auf Ebene von Sachbearbeiterinnen sowie repräsentative Nutzer*innen einzubeziehen um die Bedürfnisse beider Seiten so weit möglich einzubeziehen und ggf. notwendige Überarbeitungen der Gesetzeslage und weiterer Regulatorik zu veranlassen sollten die möglichen oder angestrebten technischen Lösungen zu Grundrechtsverletzungen führen, wie bspw. die fehlende Veröffentlichung der Datenschutzfolgeabschätzung im Bereich der Fürsorge für Geflüchteten durch das BAMF nahelegt.

Strategische Leitplanken

09. Strategische Leitplanken und Ausprägungen

Datum der Veröffentlichung: 06.12.2023
Anzahl eingegangener Antworten: 29
Issue # in GitLab: #146
Leitfrage 09 Strategische Leitplanken und Ausprägungen

Auf Basis der eingegangenen Kommentare wurden die strategischen Leitplanken* aktualisiert und angepasst, eine erste Übersicht finden Sie anbei.

Welche ausgewählte Ausprägung halten Sie für sinnvoll?

Jede Ausprägung hat unterschiedliche Folgen für die einzelnen Stakeholdergruppen (hier vertreten im Konsultationsprozess). Bitte beschreiben und bewerten Sie die relevanten Szenarien aus Ihrer Perspektive.

*Definition Strategische Leitplanken: sind ein Arbeitswerkzeug zur Erarbeitung von Architekturprinzipien. Sie stellen mögliche Ausprägungen eines Architekturprinzips anhand eines „Schiebereglers“ gegenüber und ermöglichen so eine Abwägung zwischen verschiedenen Alternativen.

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

Leitfrage_09_Zusatzmaterial

Update vom 13.12.2023:

Leitfrage_09_Zusatzmaterial_Update_13

D.H - editiert am 18.01.2024

Bezüglich der folgenden strategischen Leitplanken hätte ich eine klare Meinung:

Interoperabilität sollte ein zentrales Grundprinzip sein, da nur so eine reibungslose Zusammenarbeit der verschiedenen Dienste, Komponenten und Akteure möglich ist. Hierbei sollte ein möglichst hoher Grad der Standardisierung angestrebt werden. Darüber sollten nach Möglichkeit internationale Standards verwendet werden und die verwendeten Standards müssen dem jeweiligen Stand der Technik entsprechen. Das ist beispielsweise bei den "Standards" der XÖV-Familie regelmäßig nicht mehr der Fall. Der Stand der Technik entwickelt sich im Übrigen fortlaufend weiter, so dass hier eine kontinuierliche Überprüfung und ggf. Fortschreibung der zu verwendenden Standards erfolgen sollte. Diese Überprüfung und Anpassung der Festlegung sollte insbesondere unter der Berücksichtigung von fachlichen und technischen Aspekten und somit eher nicht von politischen Gremien mit geringer Fachkompetenz erfolgen.

Der Zugang zum Ökosystem sollte mit möglichst geringen Hürden verbunden sein, so dass hier auch kleine kommunale Behörden und KMUs aktiv mitwirken können.

Es sollte auf eine größtmögliche Digitalen Souveränität für die eingebundenen Akteure und eine möglichst große Offenheit und Transparenz hingewirkt werden. Insofern sollten in der OZG-Rahmenarchitektur nach Möglichkeit Open Source Komponenten ** eingesetzt werden und bei der Beschaffung von Lösungen durch die öffentliche Hand muss es eine generelle Verpflichtung zur Bereitstellung der entwickelten Lösungskomponenten als Open Source** geben (Public Money - Public Code!).

K.E - original vom 19.12.2023

Ich möchte das gerne unterstreichen, was Sie geschrieben haben. Mit Blick auf die Vielfalt der Rahmenbedingungen in Kommunen und anderen Verwaltungen, was IT-Ausstattung, Fachverfahren etc. betrifft, ist es in meinen Augen ebenfalls unerlässlich, dass Interoperabilität ein zentrales Grundprinzip ist.

Damit wären aus meiner Sicht bspw. die beiden Ausprägungen unter Transformationsgrad gar kein Widerspruch mehr.

Auch bei den Themen Zugang zum Ökosystem und Digitale Souveränität schließe ich mich Ihren Ausführungen an. Die Ausprägung Open Source fehlt mir aktuell bei der digitalen Souveränität noch.

M.M - editiert am 19.12.2023

Arbeitsgruppe Offenes Design digitaler Verwaltungsarchitekturen (opendva.de, FSU Jena und Partner): Nur Abweichungen zum aktuellen Arbeitsstand, bisher nicht ausreichend definierte Ausprägungen wurden nicht kommentiert: * (Offenheit bzw. Transparenz) -> maximale Transparenz * (Digitale Souveränität) -> -> "Vollständige Unabhängigkeit". Die öffentlichen Verwaltungen sollten bestimmen, welche Lösungen von ihr bevorzugt werden. Dazu müssen neue Lösungen mit vorhandenen vorbehaltlos konkurrieren dürfen. Aus den übrigen überlegungen muss hier maximale Unabhängigkeit folgen * (Transformationsgrad) -> "Disruption priorisieren" Ohne eine gewisse Disruption werden nur bestehende Arbeitsabläufe mit all ihren Problemen 1:1 digital umgesetzt. Eine spätere "Optimierung" gestalltet sich dann deutlich schwerer, als wenn dies von Anfang hier mitgedacht wird. Es muss die Regel sein, Ende-zu-Ende digitalisierte Verfahren neu zu gestalten, sonst werden neue Ideen nicht in die Umsetzung kommen. Investitionsschutz sollte soweit mitgedacht werden, wie er Neues nicht behindert. * (Grad der Interoperabilität) -> "Übergreifende Standardisierung" | "Lokale Standardisierung" Eine deutschlandweite Standardisierung dürfte aufgrund der Vielzahl von Interessen nicht in kurzer Zeit umsetzbar sein. Von daher vielleicht praktikabler nur manche, grundlegende Standards zentral zu definieren, die dann lokal entsprechend ergänzt bzw erweitert werden. Dies wäre dann wohl auch eher im Einklang mit der Regulierungsstrategie. * (Zugang zum Ökosystem) -> "Offen für alle" Hier muss wohl stärker differenziert werden als es eine solche Übersicht ermöglicht. Fundamental sollte der Zugang zu geschaffenen Schnittstellen, Informationen, etc. frei und offen gestaltet werden. Dies ermöglicht insb. eine Mitwirkung der Zivilgesellschaft (vgl. Aktivitäten des CCC in verschienden Bereichen). Eine formale Akkrekditierung ist hier im Zweifel nur ein Hebel bestimmte, unliebsame Akteure auszuschließen. Um aber offensichtlich bösartige Akteure auszuschließen bieten sich ggf "verifizierte Partner" oder ähnliche Ansätze an. So können sich Nutzende entweder auf dieses "Siegel" verlassen oder müssen bei nicht verifizierten Partnern selbst eine Überprüfung vornehmen oder anderen, dritten Parteien entsprechend vertrauen. Ein zu enger Kreis an möglichen Akteueren kann hier zum einen zu einer Monopolisierung bestimmter Bereiche führen (wenn bspw die Auflagen einer Akkreditierung einen zu großen finanziellen Aufwand erfordert und so nur entsprechend große Akteure zum Zug kommen) und führt auch nur zu einem Vertrauensverlust in die Gesamtheit des Prozesses (weil bspw durch den Mangel an Alternativen und damit Wettbewerb der Innovations- und Qualitätsdruck auf die verbleibenden Akteure abnimmt). Letzteres spielt dann auch mit der Leitplanke "Offenheit und Transparenz" zusammen. * (Nachhaltigkeit) Hier wäre erst die Begriffsdefinition in Abgrenzung zu anderen Leitplanken zu klären. Nachhaltigkeit im Sinne einer Unabhängigkeit von einzelnen Akteuren ist wohl schon im Punkt "Digitale Souveränität" adressiert. Nachhaltigkeit im ökologischen Sinne wäre zwar ein interessantes Feld, geht aber wohl über eine solchen Rahmenarchitektur hinaus. Bei einer Nachhaltigkeit im ökonomischen Sinne müssten wohl mögliche Optionen geklärt werden. Im Vordergrund hier sollte doch die mittel- bis langfristigen Kosten der öffentlichen Hand im Vordergrund stehen. Insb. beziehen diese den Betrieb und die Weiterentwicklung von zu erstellenden System/Architekturen ein und müssen auf verschiedenen Ebenen betrachtet werden (unmittelbare Kosten bzw durch Bereitstellung on Services, indirekte Kosten bspw durch reguläre Sicherheitsaudits, Aufwand für Ergänzungen bzw Anpassungen an neue Gegebenheiten, ...).

S.M - editiert am 22.12.2023

Bundesagentur für Arbeit: Die Bundesagentur für Arbeit bewertet die 9 strategischen Leitplanken wie folgt:

Leitplanke „Transformationsgrad“: Ausprägung „Investitionsschutz priorisieren“ Leitplanke „Grad der Interoperabilität“: Ausprägung „Vollständige Standardisierung“ Leitplanke „Regulierungsstrategie“: Ausprägung „Nutzung intern. Standards mit Erweiterung & nationale Standards wo notwendig“ Leitplanke „Einheitlichkeit von Qualitätsstandards“: Ausprägung „keine/Enthaltung“, da die BA als Bundesbehörde hier keine Betroffenheit für sich sieht. Leitplanke „Kooperationsgrad“: Ausprägung „Einsatz eigener fachübergreifender Module immer möglich“ Leitplanke „Vertrauensmechanismen“: Ausprägung „Zero Trust Ansatz“ Leitplanke „Zugang zum Ökosystem“: Ausprägung „Offen für ausgewählte Beteiligte“ Leiplanke „Digitale Souveränität“: Ausprägung „Setzen auf etablierte Lösungen“ Leitplanke „Transparenz“: Ausprägung "Offenlegung des Quellcodes"

T.L.S.P - original vom 18.12.2023

Bzgl. „Einheitlichkeit von Qualitätsstandards“: Eine Abweichung von bundesweiten Qualitätsstandards halten wir nur dann für zweckdienlich, wenn es um Leistungen bzw. Komponenten geht, die rein auf ein Bundesland beschränkt sind. Diese können aus unserer Sicht aber dann außerhalb der Rahmenarchitektur betrachtet werden. Insofern würden wir den Regler weiter in Richtung „Bundesweite Qualitätsstandards“ verorten.

Ansonsten halten wir die Leitplanken und Einordnungen (wo vorhanden) für sinnvoll.

D.K - original vom 29.12.2023

Transformrationsgrad: Wir sehen auch eine höhere Priorisierung auf disruptiven Ansätzen. Die bisherige IT-Architektur der Verwaltung ist über die vergangenen 20 bis 30 Jahren extrem gewachsen. Es gibt viele individuelle und stark dezentrale IT-Systeme, deren heutige Daseinsberechtigung sehr überschaubar ist. Grund dafür ist, dass sich die Aufgaben aus der damaligen Zeit heutzutage anders darstellen, z. B. bei Bezahlvorgängen und Authentifizierungen. Auch gibt es viele IT-Systeme, die rein technologisch betrachtet aus dem letzten Jahrtausend stammen (Legacy), was deren Aufrechterhaltung teuer macht. Würde man also den heutigen Status quo aus Aspekten des Investitionsschutzes erhalten, erhält man mit einigem Aufwand obsolete IT-Systeme am Leben und – viel schlimmer – rund um diese alten Systeme wird eine neue Architektur gebaut.

Grad der Interoperabilität: Interoperabilität hat nicht zwingend etwas mit der Standardisierung oder Diversifizierung zu tun. Die angewandte Skalierung ist hier fehlleitend. Ein höchster Grad an Interoperabilität ist zu befürworten. Allerdings sollte dies mittels offener und dokumentierter Schnittstellen erreicht werden - das ist das Mindestmaß. Darauf aufbauend wäre eine Standardisierung dieser offenen Schnittstellen wünschenswert, damit die Zahl der verschiedenen (offenen und dokumentierten) Schnittstellen langfristig reduziert werden kann. Dabei ist keine zentral vorgegebene Standardisierung gemeint, sondern eine wachsende und iterativ stattfindenden Standardisierung – ähnlich den Standards des W3C.

Regulierungsstrategie: Die vorzugsweise Nutzung internationaler, damit vorhandener und erprobter, Standards ist wünschenswert. Eine nationale Abpassung oder Erprobung ist eher abzulehnen, da damit die EU-weite und internationale Interoperabilität gefährdet wird.

Einheitlichkeit von Qualitätsstandards: Hier gilt gleiches wie für die Regulierungsstrategie – die föderale Ausgestaltungsmöglichkeit öffnet Tür und Tor für eine in der Folge daraus resultierende geringere Interoperabilität.

Vertrauensmechanismen: Zero Trust ist gut, allerdings auch in der Industrie noch nicht überall verbreitet. Da der Digitalisierungsdruck auf die Verwaltung aber groß ist und damit eine zeitliche Dringlichkeit einhergeht, sollte vermieden werden auf nicht ausgereifte Ansätze, Technologien und Standards zu setzen, d.h. hier sollte die heute gangbare Technologie bevorzugt und experimentelle Ansätze eher zeitlich depriorisiert werden.

Zugang zum Ökosystem: Der bevorzugte Weg sollte „Offen für alle“ sein. Offene Schnittstelle und offene Dokumentationen sind Pflicht – am besten kann das mit Open Source Software umgesetzt werden (z. B. als Referenzimplementierung für die vorhandenen Standards). Es gibt KEINE Argumente, die für eine Akkreditierung von Marktteilnehmern sprechen.

Digitale Souveränität: Hier wird mit einer falsch eingesetzten Skalierung gearbeitet. Digitale Souveränität hat nichts damit zu tun, ob man „auf globale Marktführer“ setzt. Es geht darum, den vertraglichen und technischen Rahmen so zu setzen, dass man alleinig ohne Einfluss von Dritten über die Art und Weise des Softwareeinsatzes entscheiden kann. Das gelingt mit großen und kleinen Anbietern. Wenn dabei darauf geachtet wird sich entsprechende Rechte im Vertrag einräumen zu lassen und bestimmte Marktdynamiken bekannt sind. Die Verwendung von OSS-Softwarelizenzen ist sicherlich ein gutes Beispiel, das einen hohen Grad an Digitaler Souveränität ermöglicht, jedoch nicht das einzige.

(Auf Basis des Arbeitsstandes vom 28.11.2023)

J.F.IBM.X.B - original vom 02.01.2024

(Hallo @OC000023434222 , ein technischer Kommentar von mir: die Links zu den PDFs funktionieren leider nicht, ich bekomme immer nur Fehler 500 beim Zugriff auf Leitfrage_09_Zusatzmaterial_Update_13 und Leitfrage 09 Zusatzmaterial Update 13.12..pdf )

SEITENBAU - original vom 02.01.2024

Sinnvolle Ausprägung: Eine ausgewählte Ausprägung ist sinnvoll, wenn plausibel hergeleitet werden kann, dass ein angestrebtes Ziel unter Berücksichtigung der gegebenen Ausgangslage erreicht wird.

Angestrebtes Ziel: Verwaltungsleistungen für Bürgerinnen, Bürger, Unternehmen, Verwaltungsmitarbeitende und die Verwaltung selbst durch attraktive, nutzendenfreundliche digitale Angebote einfach, sicher und von überall und zu jedem Zeitpunkt nutzbar zu machen (Ziel OZG).

Gegebene Ausgangslage: Es gibt einen Bestand digitaler Angebote der bzgl. der betrachteten Leitplanken inhomogen ausgeprägt ist.

Die Leitplanken sollen auf das angestrebte Ziel hinführen, aber die gegebene Ausgangslage berücksichtigen.

Folgende Ausprägung halten wir als Softwareentwicklungs-Dienstleister für sinnvoll:

Transformationsgrad: Einen mittig angeordneten Regler halten wir für sinnvoll, um eine wirtschaftliche, fallweise Beurteilung auszudrücken. Bestehendes soll so gut wie möglich genutzt werden, um zusätzliche kosten- und zeitintensive Investitionen zu verhindern. Gleichzeitig darf der Investitionsschutz alleine nicht verhindernd sein für eine andere sonst überlegende Lösung.

Grad der Interoperabilität: Wir halten eine übergreifende Standardisierung für sinnvoll (Regler entsprechend mittig bei der übergreifenden Standardisierung). Standardisierung soll eine Interoperabilität unterstützen aber gleichzeitig Innovationen nicht hemmen.

Regulierungsstrategie: Regler in der zweiten Stufe: Aus Gründen der Effizienz und Interoperabilität auf internationale Standards setzen und dort ergänzen, wo diese nicht vorliegen oder ausreichen.

Einheitlichkeit von Qualitätsstandards: Grundsätzlich ergeben Industriestandards oder gelebte Best-Practises der Industrie eine gute Grundlage für bundesweite Standards. Eine landesspezifische Ausgestaltung lässt Freiheiten bzgl. bestehende Lösungen. Daher sollten vorerst Leitlinien angestrebt werden, die später in Mindeststandard gewandelt werden können.

Kooperationsgrad (Autarkie der Länder): Dort wo wirtschaftlich möglich, sollte eine bundesweite Service-orientierte Architektur angestrebt werden, um eine hohe Flexibilität zu erreichen.

Vertrauensmechanismen: Regler beim Zero-Trust-Ansatz, um im Kontext sensibler Antragsdaten das Risiko von Datenverlusten und Sicherheitsverletzungen zu minimieren.

Zugang zum Ökosystem: Der Zugang zum Ökosystem muss für qualifizierte Marktteilnehmende attraktiv gehalten werden, um Innovations- und Umsetzungskraft erhöhen zu können. Eine Akkreditierung muss so gestaltet sein, dass die Qualifikation sichergestellt wird ohne geeignete Marktteilnehmende abzuschrecken.

Digitale Souveränität: Mit dem Ziel der digitalen Souveränität erscheint der Regler bei alternativen Systemen zu aktuell vorhandenen Lösungen sinnvoll, um den Trend einzuschlagen. Damit ist die Tendenz stärker als bei der generischen Leitplanke Transformationsgrad. Neben den angegebenen Ausprägungen ("alternative Systeme") könnten auch noch alternative Kooperationsmodelle bzgl. vorhandener Lösungen aufgenommen werden.

Offenheit und Transparenz: So offen wie möglich, so geschlossen wie nötig.

Beschreibung und Bewertung relevanter Szenarien aus unserer Perspektive

Unsere Perspektive: Dienstleister IT-Softwareentwicklung aus der Privatwirtschaft

Relevante Szenarien

Neuentwicklungen: Im Rahmen der Entwicklung einer neuen Lösung geben die Leitplanken Orientierungshilfe bei Entscheidungen. Wirtschaftliche Gründe oder deutliche zeitliche Verzögerungen können mitunter das Ausreizen einer Leitplanke begründen (z.B. das Abweichen von einem eigentlich passenden aber zum Zeitpunkt nicht ausreichenden Standard) . Die Leitplanken haben zum einen Einfluss auf die Umsetzung, indem hoch integrierbare Lösungen (Interoperabilität, Standards, Zero-Trust-Architektur) angestrebt werden. Zum anderen werden Lösungen angestrebt, bei denen die digitale Souveränität gewährleistet wird.

Bestehende Lösungen: Bei der Weiterentwicklung oder bei der Entscheidung über die Weiterverwendung einer bestehenden Lösung geben die Leitplanken Orientierungshilfe. Je nachdem mit welchem Grad eine bestehende Lösung gegen Leitplanken verstößt, kann es interessant sein die Disruption zu priorisieren.

F.K - original vom 05.01.2024

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen:

Transformationsgrad: Wir empfehlen den Regler etwas weiter nach rechts Richtung Disruption zu schieben. Da in OZG häufig sehr viele profitieren, sollten nicht alle unter veralteten Lösungen leiden sondern schnell von Weiterentwicklungen profitieren können.

Vertrauensmechanismen: Wir unterstützen prinzipiell den Zero Trust Ansatz. Es könnte in manchen sehr kleinen, spezialisierten und abgeschlossenen Systemen allerdings nicht notwendig sein einen vollständigen Zero Trust-Ansatz zu wählen.

D.T.OZG.S - original vom 05.01.2024

In der nachstehenden Tabelle sind die Ausprägungen der Leitplanken aus Sicht der Deutschen Telekom bewertet. Zudem werden die Folgen der strategischen Leitplanke dargestellt.

Leitplanke

Wert (gem. Unterlage vom 13.12.2023)

Bewertung DTAG

Folgen

Transformationsgrad Disruption priorisieren sinnvoll Aufwänden bei Inanspruchnahme von Verwaltungsleistungen (bspw. Glasfaserausbau) würden reduziert. Transformation muss insbesondere durch die Fachlichkeit gewollt und getrieben werden.

Grad der Standardisierung Übergreifende Standardisierung Sinnvoll (Tendenz zu einer vollständigen Standardisierung) Grundsätzlich müssen übergreifende Standards gelten. Hierdurch können Aufwands- und Kostenreduzierung durch (teilweise) Wiederverwendung von anderen Projekten realisiert werden und gleichzeitig individuelle Anforderungen von Organisationen berücksichtigt werden.

Herkunft der Standards Nutzung internationaler Standards + nationale Standards wo notwendig sinnvoll Aufwands- und Kosten können durch Wiederverwendung von internationalen Projekten reduziert werden. Gleichzeitig können notwendige Individualleistungen umgesetzt werden. Die Etablierung von nationalen Standards sollte beschleunigt / optimiert werden.

Einheitlichkeit von Qualität-standards Bundesweite Qualitäts-standards sinnvoll Aufwands- und Kosten können durch Verzicht individueller Qualitätsanforderungen reduziert werden. Zudem schaffen (ggf. höhere) bundeseinheitliche Standards bessere Akzeptanz.

Kooperationsgrad Einsatz eigener fachübergreifender Module möglich sinnvoll Markt für querschnittliche Themen bleibt bestehen. Umstellungsaufwände „aus Prinzip“ werden vermieden.

Vertrauensmechanismen Zero Trust Ansatz sinnvoll

Zugang zum Ökosystem Offen für alle

nicht sinnvoll

Aufgrund der Anforderungen des öffentlichen Sektors sollten ausschließlich Marktteilnehmer:innen mit der notwendigen Fachkunde und Leistungsfähigkeit Zugang zum Ökosystem besitzen.
Die Fachkunde / Leistungsfähigkeit wird im Rahmen der Vergabeverfahren bereits in Form der Eignungsprüfung durchgeführt. Zu begrüßen wäre jedoch eine Standardisierung der Eignungsprüfung.

Digitale Souveränität Alternative Systeme zu aktuell vorhandenen Lösungen Die Ausprägungen lassen großen Interpretationsspielraum zu und sind aus unserer Sicht missverständlich. Wir verzichten daher auf eine Bewertung der Ausprägung.

Transparenz Offenlegung des Quellcodes

nicht sinnvoll

Bei Individualentwicklungen ist die Ausprägung sinnvoll. Ob allerdings Hersteller von Standardsoftware den Quellcode offenlegen, darf bezweifelt werden.
Fraglich ist, inwieweit die (Standard-) Fachverfahren innerhalb eines Ende-zu-Ende-Prozesses in der OZG-Rahmenarchitektur berücksichtigt sind. Die Ausprägung der Leitplanke muss für alle (Funktions-) Bausteine gleichermaßen gelten.

J.P.S - original vom 06.01.2024

Materna und Infora

Für uns sind die Leitplanken sinnvoll gewählt. Wir möchten zu bedenken geben, dass das Wort „Disruption“ durchaus positiv konnotiert ist. Es kann jedoch in manchen Fällen auch negativ konnotiert sein. Aus diesem Grund empfehlen wir, die Wahl des Wortes zu überdenken. Bei der Anwendung der Rahmenarchitektur und im gesamten Verwaltungsumfeld sollte eine Offenheit gegenüber primär digitalen Lösungen und Prozessen gefördert werden, die auch disruptive Entwicklungen beachtet und nicht ausschließt. Die Gesetzgebung muss eine (primär)digitale Umsetzung von Verwaltungsaufgaben immer beachten und fördern. Bei bundesweiten Qualitätsstandards ist zu bedenken, dass Länder und Kommunen beteiligt sind. Aufgrund der Vielzahl der Beteiligten in einem föderalen System kann es schwierig sein, hier zu einer Einheitlichkeit zu gelangen. Grundsätzlich ist ein hoher Grad an Transparenz zu begrüßen, da dieser nicht nur Akzeptanz fördert, dadurch dass jeder sich beteiligen kann, sondern es auch einfacher macht, Anbindungen an Systeme zu bauen. Hier sollte jedoch bedacht werden, dass ggf. nicht der Quellcode aller Komponenten überhaupt veröffentlicht werden kann mit Verweis auf das Urheberrecht. Ein pauschales vollständig offenes Ökosystem ist je nach Anwendung kritisch zu betrachten. Hier müssen die jeweiligen Sicherheitsanforderungen der jeweiligen Behörden beachtet und ggf. geschützt werden. Einen Vorschlag der Regler halten wir für die Leitplanken „Grad der Standardisierung“, „Herkunft der Standards“, „Einheitlichkeit von Qualitätsstandards“ und „Vertrauensmechanismen“ grundsätzlich sinnvoll. Für die weiteren strategischen Leitplanken sind vielfältige zum Teil verfahrensspezifische Aspekte relevant, die einer Vorgabe im Sinne der “Regler” entgegenstehen. Wir empfehlen dies im Einzelnen zu prüfen.

E.S - original vom 08.01.2024

Für den Bitkom e.V.

Welche ausgewählte Ausprägung halten Sie für sinnvoll?

Es ist fraglich, ob „Marktführerschaft“ und „etablierte Lösungen“ tatsächlich die beiden Extreme eines Kontinuums der digitalen Souveränität darstellen können. Kann eine etablierte Lösung nicht marktführend sein? Unserem Verständnis nach ordnet sich ein digital souverän agierender Staat auf einem Kontinuum mit den Extremen „digitale Autarkie“ und „(vollständige) digitale Abhängigkeit“ ein.

Rückfrage zur neuen strategischen Leitplanke „Transparenz“: Impliziert die Wahl der Reglereinstellung, dass zukünftig keinerlei proprietäre Software im OZG-Kontext eingesetzt werden soll oder bezieht sich die Offenlegung wie z.B. der Quellcodes, Integrationsleitfäden und Schnittstellen v.a. auf die Auftragsentwicklung neuer Komponenten?

Jede Ausprägung hat unterschiedliche Folgen für die einzelnen Stakeholdergruppen (hier vertreten im Konsultationsprozess). Bitte beschreiben und bewerten Sie die relevanten Szenarien aus Ihrer Perspektive.

Transformationsgrad: Disruption um zu Standardisieren und Eigenentwicklungen zu ersetzen.

Herkunft der Standards: Zu empfehlen aus Sicht der Anbieter ist die Nutzung von internationalen Standards, wenn es diese bereits gibt. Sind neue Standrads zu beschließen, kann dies ggf. direkt auf EU-Ebene erfolgen und im nächsten Schritt auf internationaler Ebene eingebracht werden.

Vertrauensmechanismen: Es sollten Sicherheitsstufen entsprechend der Kritikalität der Dienste und Daten definiert werden. Gleichzeitig gilt es einen pragmatischen Ansatz zu wählen, der erlaubt, bereits bestehende und etablierte Identitätslösungen zu berücksichtigen und - soweit vom Sicherheits-/Vertrauensniveau notwendig – zu integrieren.

S.L.B - original vom 08.01.2024

Sowohl die Kategorisierung (Ausprägung), als auch die konkrete Ableitung der Einstellungen kann die Bundessteuerberaterkammer grundsätzlich nicht genau nachvollziehen. Daher regen wir an, dass die Bewertungs- und Erstellungsmethodik offengelegt wird, um den Entscheidungsprozess besser zu verstehen.

Unter Zugrundelegung des Verständnisses der Bundessteuerberaterkammer sind die dargestellten Ausprägungen grundsätzlich sinnvoll, wobei sicherlich erst die weiteren Konkretisierungen im Detail zeigen werden, welche Auswirkungen diese auf die Fachverfahren haben können.

Die Ausprägungen im Bereich Vertrauensmechanismen sollten zum eindeutigen Verständnis näher erläutert werden. Der aus dem IT-Security-Bereich stammende Begriff „Zero Trust“ darf nicht dazu verleiten, einige der in Deutschland etablierten und rechtlich definierten elektronischen Identitäten (wie z.B. im Rahmen des elektronischen Rechtsverkehres definiert) außer Acht zu lassen oder gar abzuerkennen. Das Gegenteil muss der Fall sein, um einen niedrigschwelligen und nachhaltigen Ansatz zu entwickeln und vorhandene, nach eIDAS hohem Sicherheitsniveau entsprechende, Identitäten nachzunutzen.

R.F - editiert am 08.01.2024

Für die Cassini Consulting:

Grundsätzlich sind die verschieden gewählten Ausprägungen je strategischer Leitplanke verständlich und nachvollziehbar. Generell stellt sich uns die Frage, warum im Update vom 13.12. die bedeutsame Komponente "Nachhaltigkeit" entfernt wurde. Unter der Annahme, dass in dieser Dimension immer eine Maximalausprägung verfolgt werden sollte, wäre zu eruieren, inwiefern dieses Querschnittsthema (verpflichtend) in die OZG-Rahmenarchitektur einfließen kann.

Strategische Leitplanke Transparenz: Die Ausprägung "Offenlegung des Quellcodes" ist nicht für alle Lösungen erstrebenswert, insb. für Lösungen, die in den Bereich der Justiz- und Sicherheitsbehörden fallen. Hier sollten Daten- und IT-Sicherheit über der transparenten Offenlegung des Quellcodes stehen. Daher ist zumindest für bestimmte Fachbereiche die Ausprägung „Offenlegung von Architekturdokumentation“ zu befürworten und ausreichend.

Strategische Leitplanke Digitale Souveränität: Die Abstufungen sind teilweise deckungsgleich, bspw. sind die Ausprägungen "Marktführer" und "etablierte Lösungen" keine Gegenpole, da etablierte Lösungen die entsprechenden Anbieter oft zu Marktführern machen. Unser Vorschlag für eine Schärfung der Ausprägungen sind (von links nach rechts) - "Setzen auf Marktführer/ etablierte Lösungen" - "Setzen auf Customizing von etablierten Lösungen" - "Setzen auf eigene Lösungen unter Verwendung von Basissoftware" - "Setzen auf eigene Lösungen"

Auch hier gibt es verschiedene Abwägungen bzgl. der Ausprägungen zu treffen, wir empfehlen im Sinne der digitalen Souveränität bei fachspezifischen Anwendungen die 3. Ausprägung von links, bei „Standardanwendungen“ (z.B. Office-Pakete, Personalakte, Reisemanagement, u.v.m.) die 2. Ausprägung von links.

N.L - original vom 08.01.2024

Der dargestellten Ausprägung der vorgestellten Architekturprinzipien stimmen wir in weiten Teilen zu.

Bei der Leitplanke „Herkunft der Standards“ sehen wir eine Berücksichtigung und auch tatsächliche Einhaltung internationaler Standards als dringend notwendig an. Eine schnelle Anpassungsfähigkeit an sich ändernde Standards sollte daher mitgedacht werden (vgl. FHIR Standard im Gesundheitswesen).

In Bezug auf die Leitplanke ist uns die Logik der Skalenausprägung unklar. Marktführer stellen zumeist die etablierten Lösungen bereit. Deshalb sollte die Skala von „Marktführer mit etablierten Lösungen sind zu nutzen“ bis zu „Alternative Systeme werden vorrangig genutzt“ dargestellt werden.

Farina Owusu und Nico Lück (GovStack Initiative)

E.H - original vom 08.01.2024

Antwort von Bundesamt für Migration und Flüchtline (BAMF):

Kritisch sehen wir, dass keine der strategischen Leitplanken explizit auf das Prinzip der Sicherheit und des Datenschutzes abzielt. Unser Vorschlag: "Security und Privacy by Design und by Default" zusätzlich als strategische Leitplanke aufnehmen. Mit dem Begriff "Vertrauensmechanismen" können die Themen Sicherheit und Datenschutz hingegen nicht abgedeckt werden. Vertrauensmechanismen sind Maßnahmen, die dazu beitragen, Vertrauen zwischen zwei oder mehreren Parteien aufzubauen; dieser Ansatz findet sich bspw. im Vertrauensniveau für Signaturen und Nachweisdokumente wieder. Hingegen geht es im Kontext von IT-Sicherheit in erster Linie um die Sicherheitsfunktionen laut BSI IT-Grundschutz in IT-Systemen und -Infrastrukturen.

Bzgl. der strategischen Leitplanke "Einheitlichkeit von Qualitätsstandards" erscheint uns die Ausprägung/Reglereinstellung "Mindeststandards mit landesspezifischer Ausprägung" nicht ausreichend, da sie voraussichtlich eine bundesweite Einführung faktisch verhindern würde.

Bzgl. der strategischen Leitplanke "Digitale Souverenität" sollte das dritte Feld lauten "Alternative Systeme zu aktuell vorhandenen Lösungen sind realisierbar" und der Regler sollte dorthin geschoben werden. Denn "denkbar" ist vieles, zu dessen Vermeidung sich dann immer das Fehlen einer Alternativimplementierung (wer hätte sie zahlen sollen?) als Argument anbietet. Hingegen sind realisierbare alternative Systeme erstrebenswert.

Den genannten strategischen Leitplanken und Architekturprinzipien können wir ansonsten weitgehend folgen. Allerdings erschien aus unserer Sicht ein erneutes Formulieren von strategischen Leitplanken und Architekturprinzipien nicht unbedingt erforderlich; eine 1:1 -Referenzierung auf die Architekturprinzipien der FITKO hätte ebenfalls stattfinden können. Außerdem empfinden wir die Kernanforderungen, wie sie im Evaluierungsbericht zum FMD (Fördermanagement, Element der Dienstekonsolidierung des Bundes) dargestellt wurden, ebenfalls für die OZG-Rahmenarchitektur ganz passend:

J.P - original vom 09.01.2024

Antwort Team PwC:

•Bzgl. „Ausprägung“: Der Grad der Interoperabilität sollte möglichst auf „Vollständige Standardisierung“ setzen, insb. bei jenen Leistungen, denen bundesrechtliche Bestimmungen zu Grund liegen. Gleiches gilt für bundesweite Qualitätsstandards.

AS - editiert am 09.01.2024

Transformationsgrad

Regler: Disruption priorisieren*

Mit dem Beginn der OZG-Umsetzung hätte eine vollständige Disruption zu Einheitlichkeit führen können (siehe BundID vs. Länder-Nutzerkonten). Aktuell hängt es auch von Fall zu Fall bzw. von Behörden/Projekttyp ab. Ein vollständiger Investitionsschutz führt in vielen Fällen zu mehr Steuergeldverschwendung.\ Disruption ist dann notwendig, wenn sie zu den bestehenden Systemen einen deutlichen Mehrwert bietet.

*Begriff-Kritik: Der Begriff der Disruption wird in letzter Zeit gerne benutzt, um innovativen Technologien mehr Durchsetzungskraft zuzuschreiben. Es ist fraglich, ob dieser Begriff im Kontext des OZG verwendet werden sollte oder besser in „schnelle Transformation“ umbenannt werden sollte. Sicher wird es u.U. auch disruptive Innovationen wie z.B. KI-Integration geben, als Ausprägungsbezeichnung erscheint der Begriff Disruption als wenig sinnvoll, da kein häufiger Anwendungsfall.

Grad der Interoperabilität

Regler: Übergreifende Standardisierung (Zustimmung zur bisherigen Einschätzung)

Grundsätzlich sollte eine möglichst umfassende Standardisierung v.a. im Sinne gemeinsamer Datenaustausch-Formate (XÖV, etc.) angestrebt werden. Dabei darf der Zwang zur Standardisierung nicht zu einer unnötigen Hürde in einzelnen Umsetzungsprojekten werden. Aus der Sicht eines Beratungs- und IT-Dienstleistungsunternehmens bietet eine solche Entwicklung die Möglichkeit, schneller neue Lösungen für die Kunden der Verwaltungen realisieren und integrieren zu können. Zudem wird die Gefahr von Monopol-Bildung und Lock-Ins verringert.

Regulierungsstrategie

Regler: Nutzung internationaler Standards

Die Nutzung internationaler Standard sollte - sofern verfügbar - das Ziel sein. Das Beispiel EU-OOTS/NOOTS zeigt, dass beim Sprung in den int./europ. Kontext enorme Aufwände entstehen, um die intermediären Systeme zu bauen und zu integrieren. Das Beispiel XRoad zeigt, dass Datenautobahnen bzw. IT-Architekturen, durchaus länderübergreifend etabliert werden können. Hier arbeiten z.B. kolumbianische, estnische und isländische Entwickler:Innen zusammen an der offenen Struktur. Andererseits wird auch deutlich, dass es von Vorteil sein kann, wenn zunächst an nationalen Lösungen und Standards gearbeitet wird, solange die Lösungen auf höherer Ebene noch nicht verfügbar sind, aber dennoch Lösungen benötigt werden.

Kooperationsgrad

Regler: Einsatz eigener Module nach Akkr. möglich

Ähnlich zu den Überlegungen unter "Regulierungsstrategie". Vorzug stets für die maximale Standardisierung. Ausweichen nur in zwingenden, begründeten Fällen. Grundsätzlich sollten, aufbauend auf einer klaren Compliance, Themen wie Interoperabilität, Sicherheit, Datenkonsistenz und z.B. Governance, beim Einsatz eigener fachübergreifender Module, betrachtet werden. Sinnvoll könnte z.B. ein Modell sein, indem sehr wohl eigene, fachübergreifende Module entwickelt werden, dies aber in Abstimmung mit einer zentralen Instanz wie der KOSIT geschieht, die die Pflege der Standards überwacht und das letzte Wort hat. Hierzu gibt es ja schon eine Reihe von Ideen, in dem vom IT-Planungsrat, im Januar 2021 veröffentlichten Dokument “Registermodernisierung: Zielbild und Umsetzungsplanung” https://www.it-planungsrat.de/fileadmin/beschluesse/2021/Beschluss2021-05_Registermodernisierung.pdf

Vertrauensmechanismen

Regler: Moderater Zero-Trust-Ansatz

Hier fragt sich, über welche Mechanismen die Vertrauensstellung realisiert wird und was aus ihr folgt. Vertrauen kann z.B. durch Zertifizierungen, Pen-Tests durch externen unabhängiger Anbieter usw. geschaffen werden (Moderater Zero Trust Ansatz). Letztlich handelt es sich um einen Trade-Off, bei dem abgewogen werden muss, welcher Kompromiss gewählt werden soll. Eine Zero-Trust-Umgebung bedeutet deutliche größere Sicherheit, aber auch einen um (vermutlich) mehrere Größenordnungen höheren Realisierungs-Aufwand. Am ehesten muss abgewogen werden, ob mit fortschreitender Vernetzung und Komplexität der Landschaften eine Vertrauensstellung noch mit der nötigen Sicherheit aufrechterhalten werden kann. Sollte dies nicht der Fall sein, sollte schrittweise zu einem ZT-Ansatz verschoben werden.

Zugang zum Ökosystem

Regler: Offen für interne und externe, akkreditierte Marktteilnehmende (Zustimmung zur bisherigen Einschätzung)

Wir unterstützen einen möglichst offenen Zugang zum Ökosystem, um Synergien zu nutzen und Innovationen zu fördern. Die Verwaltung sollte aber die letztinstanzliche Hoheit über die Akteure mittels Akkreditierung behalten. Grundsätzlich sollte diskutiert werden, wie man möglichst viele und diverse Nutzergruppen für die Ökosystem generieren und aktivieren kann.

Digitale Souveränität

Regler: Alternative zu aktuell vorh. Lösungen

Es sollte Unabhängigkeit von einzelnen Herstellern angestrebt werden, um besser auf den Markt und Innovationen reagieren zu können. Veraltete Fachverfahren sollten schrittweise abgelöst und Beschaffungsverbünde gebildet werden. Standard-Software großer Hersteller sollte nur dort eingesetzt werden, wo dies alternativlos und/oder ohne das Risiko eines Lock-Ins möglich ist. Beim Einsatz von Software und öffentlich beauftragten Software-Entwicklungen sollten Open-Source-Lösungen priorisiert werden. Durch Standardisierung wird allen Markt-Teilnehmern die Möglichkeit zur Entwicklung eigener Angebote gegeben.

Offenheit und Transparenz

Regler: Moderate Offenheit

Wir werben hinsichtlich dieses Punktes für ein leicht verständliches System bzw. eine leicht verständliche Architektur, um Nutzerzahlen und Usability zu erhöhen. Im Grundsatz sehen wir einen “Transparenz first”-Ansatz als sinnvoll. Da sowohl die Prozesse als auch die Datenbestände mit Steuermitteln aufgebaut bzw. gepflegt werden, sollte als Grundsatz gelten: “Transparenz wo möglich, eingeschränkte Transparenz wo nötig.” Einschränkungen sind sehr offensichtlich in vielen Bereichen nötig. Datenschutz und Persönlichkeitsrechte sollten aber nicht genutzt werden, um die Nutzung von Datenbeständen der Verwaltung in Form von open-data in jedweder Form abzulehnen. Der “Default-Zustand” sollte daher das Streben nach einer offenen und transparenten Verwaltung einschließlich offener Datenbestände sein. Hierdurch kann auch die Akzeptanz der Demokratie gesteigert werden. Zusätzlich sollte man darüber diskutieren, welchen Stellenwert Offenheit und Transparenz bei der E-Partizipation bekommt. Wir sehen hier einen großen Mehrwert bei der Legitimation der Systeme z.B. über Beteiligungsformate. Auch läßt sich feststellen, dass offene Schnittstellen und z.B. open-source- oder open-data-Standards, Innovation fördern.

Trotzdem sollte :

Sicherheit an höchste Stelle liegen: kein offener Code für alle zugänglich, sondern nur durch registrierte und zugelassenen User (GitHub)

Eine zentrale Verwaltung (Product Owner), der die Fragen/Wünsche usw. abfängt, steuert und einordnet, um eine chaotische Fortentwicklung zu vermeiden

A.S - original vom 09.01.2024

Aus Sicht der DigitalService GmbH des Bundes:

Grundsätzlich:

Es fehlt der Aspekt der Nutzerfreundlichkeit und Entwicklereffektivität? Beim Thema Vertrauensmechanismen fällt auf: Sicherheit und Datenschutz dürfen nicht auf Kosten der Nutzerfreundlichkeit gehen (siehe beispielsweise aktuelle Probleme mit PIN-Zurücksetzungen oder die Umsetzung gesetzlicher und EU-Vorschriften wie die nationalen Feedback- und Statistik-Komponenten).

Zu den Ausprägungen:

Transformationsgrad:

Priorisierung von Disruption - Es bedarf einer stärkeren Disruption als bisher. Vor allem veraltete Lizenz- und Finanzierungsmodelle bremsen derzeit Innovationen.

Grad der Interoperabilität / Regulierungsstrategie / Einheitlichkeit von Qualitätsstandards:

Fokus auf Standardisierung - Die Unterscheidung zwischen Interoperabilitäts- und Qualitätsstandards ist sinnvoll. Besonders wichtig ist die Durchsetzung moderner Qualitätsstandards und Praktiken in der Softwareentwicklung. Hohe Interoperabilität ist wesentlich, doch wie diese erreicht wird - durch Standardisierung oder Marktmechanismen - bleibt offen. (Etablierte) Industriestandards sollten gegenüber landes- und bundesspezifischen Standards bevorzugt werden, da sie die Interoperabilität eher fördern, anstelle diese bremsen.

Kooperationsgrad:

Kann unser Erachtens durch den Einsatz einheitlicher Interoperabilität und Qualitätsstandard insgesamt als Leitplanke geschwächt werden.

Ein zentraler Ansatz ist dennoch erstrebenswert. Setzen alle auf Einheitlichkeit und Interoperabilität, stehen Effizienz und Kostenreduktion im Vordergrund (da sollte es auch im Sinne der Länder sein, zu kollaborieren bzw. nachzunutzen; wie das Beispiel BundID zeigt: Hauptmotivation der Länder ist die Kostenersparnis).

Vertrauensmechanismen:

Zero-Trust-Ansatz.

Zusätzlicher Hinweis: Als Gegengewicht fehlt der Aspekt Nutzungsfreundlichkeit und Developer Effectiveness als Leitplanke. Wenn vor allem Sicherheit, Datenschutz etc. priorisiert werden, fällt ggf. Nutzungsfreundlichkeit runter (siehe z.B. auch PIN-Rücksetzeienst aktuell oder dass Dinge umgesetzt werden, um Gesetze und EU-Verordnungen zu erfüllen, wie z.B. die Nationalen Feedback und Statistik Komponenten).

Zugang zum Ökosystem:

Offenheit für Akteure im öffentlichen Sektor.

Die Regelung sollte nicht auf Konditionalprogrammen basieren (Zugang nur unter spezifischen Bedingungen), sondern auf Zweckprogrammen (Zugang bei Digitalisierung von Dienstleistungen für Bürger).

Zusätzlicher Hinweis: Wird bei hoher Offenheit und Transparenz hinfällig.

Digitale Souveränität:

Förderung alternativer Systeme zu bestehenden Lösungen durch offene Governance-Strukturen und Open-Source-Lösungen sowie deren Betrieb. Dies erhöht die Transparenz und ermöglicht Ländern, eigene Lösungen zu entwickeln bzw. Auf bestehenden entwicklungen aufzubauen und zu diese selbst zu betreiben.

Offenheit und Transparenz:

Nicht pauschalisierbar - verschiedene Aspekte sind unterschiedlich zu bewerten. Förderung offener Governance-Strukturen (transparente, klare Prozesse) und Open Source („Public money, public code;“ von OpenCode bis aktives Community Management dazu) sowie Zugang zu öffentlichen, teilbaren Daten (ggf. mit strengerer Akkreditierung).

Nachhaltigkeit:

Transparenz hinsichtlich Energieverbrauch und CO2-Ausstoß sowie anderen Nachhaltigkeitsaspekten, Förderung des Ressourcenverbrauchs und Einsatz grüner Infrastruktur sowie Kompensation offener Posten.

T.K - original vom 16.01.2024

Sammlung CDO-MID Sachsen-Anhalt und Vertreter von Kommunen des Landes:

Auf den ersten Blick erscheint die Vorauswahl sinnvoll. Bei der Digitalen Souveränität könnte der Regler weiter in Richtung Unabhängigkeit (also nach links) geschoben werden. Möglicherweise ergeben sich noch Änderungen im Rahmen der Erarbeitung des Zielbildes.

D.S - original vom 17.01.2024

Transparenz sollte besser in Form von Offenlegung der Schnittstellen definiert werden, da eine Offenlegung von Quellcodes bei beschaffter Software nicht gewährleistet werden kann. Für die Interoperabilität von Lösungen wäre aber eine Offenlegung von Schnittstellen essenziell. Diese ist ein guter gemeinsamer Nenner, dessen Einhalteung sowohl von Lizenz- als auch OpenSource-Software gefordert werden kann.

M.N.AKDB - original vom 18.01.2024

Die fluide Einwertung der jeweiligen Ausprägungen hilft, die Tendenzen und Richtungen des Auslebens der Architekturprinzipien besser zu greifen und zu antizipieren. Gleichzeitig erfüllen sie dadurch die ihnen zugedachte Rolle als Leitplanken entsprechend weniger. Positiv einzuschätzen ist, dass sie Widersprüche bzw. Defizite verdeutlichen. So ist die starke Ausprägung beim Zero-Trust-Ansatz im Widerspruch zur Verwaltungspraxis, nach der die Verwaltung regelmäßig die Garantenstellung für die Integrität und Datensicherheit kodifiziert. Ein Zero-Trust-Ansatz würde deswegen primär gegen die Stakeholder in der Verwaltung arbeiten und die dafür notwendigen Authentifizierungen, Sicherheitsvorkehrungen etc. einer permanenten Überprüfung aussetzen. Die bestehenden und in absehbarer Zeit vorhandenen Infrastrukturen sind dafür nicht ausgelegt. Gleichwohl wäre der Ansatz begrüßenswert und perspektivisch als Inkrement zu verfolgen.

Der offene "Zugang zum Ökosystem" ist grundsätzlich zu begrüßen und favorisiert tendenziell Marktplatzlösungen. Wichtig ist zur Verwirklichung dieses Architekturprinzips die Synchronisation mit bei öffentlichen Vergaben, welche stärker auf die Leistungsfähigkeit und die Erfahrung in relevanten Marktsegmenten abstellen müsste und sich weniger an einzelnen, quantitativen Zuschlagkriterien orientieren müsse. Auch die gezielte Förderung von Startups wäre hier wohlmeinend mitzudenken.

Bei der Ausprägung "Transformationsgrad: Disruption priorisieren“ besteht die Gefahrt, dass hier bewährte Strukturen, Policies und Applikationen zugunsten einer sich selbst genügenden und favorisierenden Innovationspolitik zurückgewiesen werden. Damit stehen Investionen, lauffähige IT-Infrastrukturen in Ländern und Kommunen potenziell ohne Not am Pranger, nur weil ihnen der Zauber des Neuanfangs oder überschätzter Effekte aus Zentralisierung fehlt. Die damit verbundenen Risiken müssen deshalb sehr sorgsam mitigiert und abgewogen werden. Wirksam kann der disruptive Transformationsgrad deshalb nur dann werden, wenn er Anschluss in die bewährte Welt findet und diese sinnvoll erweitert und ergänzt.

Eine übergreifende Standardisierung beim Architekturprinzip "Grad der Interoperabilität" ist zu begrüßen und eine regelmäßige Forderung. Effektiv ist dieses Architekturprinzip insbesondere dann, wenn die Interoperabilität konkreter Bestandteil der Anforderungen an IT-Infrastrukturen wird. Normgebende Institutionen sind deshalb in ihrer Arbeit zu unterstützen.

Zu betonen ist, dass die Nutzung von portalagnostischen Online-Diensten auf Microservice-Basis eine wesentliche Rolle dabei spielen. Diese ermöglichen Digitalisierung als einen selbsttragenden und gewinnbringenden Prozess in allen denkbaren IT-Umgebungen, welche sowohl für die öffentliche Verwaltung als auch für die Gesellschaft insgesamt von großem Nutzen wären.

K.G - original vom 23.01.2024

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister:

Die fluide Einwertung der jeweiligen Ausprägungen hilft, die Tendenzen und Rich-tungen des Auslebens der Architekturprinzipien besser zu greifen und zu antizi-pieren. Gleichzeitig erfüllen sie dadurch die ihnen zugedachte Rolle als Leitplanken entsprechend weniger. Positiv einzuschätzen ist, dass sie Widersprüche bzw. Defi-zite verdeutlichen Transformationsgrad Ein ausgewogenes Verhältnis zwischen Investitionsschutz und Disruption wird als sinnvoll erachtet. Es sollte die Strategie „Investitionsschutz priorisieren“ verfolgt werden, wo wir be-reits gut aufgestellt sind. In allen anderen Bereichen wird „Disruption priorisieren“ notwendig sein. Weder Technologisch noch organisatorisch sind wir bisher so schlecht aufgestellt, das „Vollständige Disruption“ notwendig wäre. Eine der tief-greifendsten Änderungen findet sich im Folgepunkt bzgl. einer neuen Aufgaben-verteilung. Es besteht die Gefahr, dass hier bewährte Strukturen, Policies und Applikationen zugunsten einer sich selbst genügenden und favorisierenden Innovationspolitik zurückgewiesen werden. Die damit verbundenen Risiken müssen deshalb sehr sorgsam mitigiert und abgewogen werden. Wirksam kann der disruptive Trans-formationsgrad deshalb nur dann werden, wenn er Anschluss in die bewährte Welt findet und diese sinnvoll erweitert und ergänzt. Neue Entwicklungen / Lösungen sollten dann bevorzugt werden, wenn sie bereits vorhandenen Lösungen (getätigten Investitionen) überlegen sind. Fallzahlen sind zu berücksichtigen und Priorisierungen vornehmen. Grad der Interoperabilität Aus Sicht eines kommunalen IT-Dienstleisters, der im Wesentlichen IT-Anwendungen einkauft und diese sowohl im eigenen Rechenzentrum als auch in lokalen Infrastrukturen bei Kommunen einsetzt, ist ein hoher Grad an Standardi-sierung erforderlich. Verfahren unterschiedlicher Softwarehersteller müssen über standardisierte Schnittstellen miteinander verknüpft werden können. Auch bei der Nutzung von Online-Diensten aus der (Public-) Cloud ist eine Standardisierung zwingend erforderlich. Insofern kann der Schieberegler Standardisierung noch et-was weiter in Richtung vollständige Standardisierung verschoben werden. Effektiv ist dieses Architekturprinzip insbesondere dann, wenn die Interoperabilität konkreter Bestandteil der Anforderungen an IT-Infrastrukturen wird. Normgeben-de Institutionen sind deshalb in ihrer Arbeit zu unterstützen. Darüber hinaus erzeugt ein hoher Grad an Standardisierung Skaleneffekte und vereinfacht und beschleunigt die Implementierung. Daher sollte mit der „Übergreifenden Standardisierung“ begonnen werden. Ohne ausreichende Standards gibt es keine Kommunikation, weder technisch noch fach-lich. Mit dem zunehmenden Grad der Vernetzung muss zwingend die „Vollständige Standardisierung“ erreicht werden. Zur Zielerreichung ist die Überführung von fachlichen Anforderungen in technische Artefakte (Nachrichtenformate, Schnitt-stellen, …) der Zuständigkeit der klassischen Fachlichkeit zu entziehen. Diese Auf-gabe muss von einer neuen Fachlichkeit „Infrastruktur“ übernommen werden. Die Definition der fachlichen und nicht-fachlichen Vorgaben muss weiterhin bei der klassischen Fachlichkeit verbleiben. Diese neue Aufgabenverteilung bezieht sich ausschließlich auf die technische Realisierung der fachlichen Vorgaben und nicht auf die fachlichen Vorgaben selbst. Damit stellt sie keine Einschränkung der ge-setzlich vorgesehenen Autonomie dar und die erfolgreichen E-Government Län-der sind grade auf Grund dieser Aufgabentrennung erfolgreich. (Zitat aus Däne-mark: „Die Digitalisierung ist zu wichtig, als dass man sie den Politikern überlassen darf.“) Regulationsstrategie Hier sollte die Strategie „Nutzung intern. Standards mit Erweiterung & nationale Standards wo notwendig“ verfolgt werden. Die intern. Standards berücksichtigen bisher nicht alle nationalen Anforderungen, nach und nach werden die nationalen Verwaltungen zunehmend digital interagieren, was eine Verwendung nationaler Standards immer problematischer machen würde. Ein ausgewogenes Verhältnis zwischen nationalen und internationalen Standards ist anzustreben Einheitlichkeit der Qualitätsstandards Nationale Besonderheiten sind weiterhin zu berücksichtigen. Dies auch im Hinblick auf die unterschiedlichen Strukturen in der Kommunalverwaltung und bei der Er-bringung von IT-Dienstleistungen für Kommunen. Hier wird man nur mit „Bundesweite Qualitätsstandards“ zu einer ausreichenden Interoperabilität und digitalen Souveränität und Nachhaltigkeit kommen können. Eine Interaktion oder Kommunikation muss immer auf einem gemeinsamen Ver-ständnis der Daten und Prozesse beruhen und immer ein Mindestniveau an Quali-tät erreichen müssen. Ein mehr an Qualität ist nicht förderlich, bringt aber Kosten mit sich. Daraus ergibt sich die Forderung nach dem einheitlichen Niveau der Qua-litätsstandards. Außerdem sorgen bundesweite Qualitätsstandards für mehr Akzeptanz bei den Kommunen für notwendige Architekturvorgaben. Kooperationsgrad Ergibt sich aus dem Transformationsgrad und der Standardisierung – so standardi-siert wie möglich, eigene Lösungen wo nötig (fachlich, monetär). Fachübergreifende Module haben fachübergreifende Auswirkungen. Das gilt auch für Fehler und Sicherheitslücken. Gleichzeitig bedeutet das „fachübergreifende“ auch, dass Module „fremder“ Herkunft zur Anwendung kommen. Das dafür not-wendige Vertrauen wird durch eine Akkreditierung erreicht – vermutlich nach ei-nem Reifegradmodell. So kommt in der Summe „Einsatz fachübergreifender Module nach Akkreditierung“ in Frage, aus Kostengründen sollte aber „Kein Einsatz eigener fachübergreifender Module“ angestrebt werden. Der Sinn eigener solcher Module würde wohl in einer Abweichung fachlicher Eigenschaften begründet sein, was dem Ziel der Interope-rabilität und der Standardisierung widerspräche.

Vertrauensmechanismus Nach einem Ausbau der bestehenden Identitätsverzeichnisse kann das fernere Ziel „Zero Trust Ansatz“ ange-strebt werden, wobei berücksichtigt werden muss, dass die bestehenden und in absehbarer Zeit vorhandenen Verwaltungsinfrastrukturen dafür nicht ausgelegt sind. Gleichwohl wäre der Ansatz begrüßenswert und per-spektivisch als Inkrement zu verfolgen.

Digitale Souveränität „Alternative Systeme zu aktuell vorhandenen Lösungen“ ist anzustreben. Es wird immer (Rand-) Themen geben, bei denen Systeme auch globaler Marktführer sinnvoll sind. Bei der Verarbeitung personenbezogener Daten muss das weitge-hend verhindert werden. Wenn es alternative Lösungen gibt wird es auch Wettbewerb zur Erreichung guter bzw. optimaler Lösungen geben. Dies ist zu begrüßen. Einseitige Abhängigkeiten müssen reduziert sowie durch eine vielfältige Anbieter-landschaft und die vorrangige Verwendung von Open-Source-Lösungen die öf-fentlichen IT-Infrastrukturen gestärkt werden.

**Offenheit und Transparenz ** Wegen der angestrebten hohen Standardisierung und des großen Kreises an Marktteilnehmern und der Notwendigkeit der Interaktion von Behörden mit Un-ternehmen ergibt die Ausprägung „Offenlegung des Quellcodes“ oder „Maximale Offenheit“ einen Sinn.

G.B - editiert am 29.01.2024

Die im Rahmen der 5. Arbeitssitzung des Arbeitspaketes „Zielbild OZG-Rahmenarchitektur“ Stand 13.12.2023 scheint aus unserer Sicht grundlegend zielführend aber unvollständig: https://gitlab.opencode.de/bmi/ozg-rahmenarchitektur/zielbild-ozg-rahmenarchitektur/uploads/f95a99a3f0f5b16203b57d1470a20e52/Leitfrage_09_Zusatzmaterial_Update_13.12..pdf

Wir vermissen: - Leitplanke Marktgestaltung Die Einführung einer strategischen Leitplanke die sich mit der Fragestellung der Marktgestaltung für IT-Anbieter der öffentlichen Hand beschäftigt.

Leitplanke Befähigung Weder die Befähigung der Endnutzerinnen noch der zuständigen Verwaltungsbeamtinnen digital Sourverän zu agieren schlägt sich in den Leitplanken nieder.

Leitplanke Adaptierbarkeit Im Rahmen der OZG Umsetzung scheint es bisher keine Anforderung zu sein, dass digitale Umsertzung Verfahren im Rahmen der Änderung gesetzlicher Anforderungen im geringen Maße entsprechend Adaptierbar sind. Dies sollte bei der Änderung bloßer Parameter wie bspw. der Änderung von zu zahlenden Summen kurzfristig möglich sein.

Leitplanke Technische Aktualität Die bisherigen Leitplanken berücksichtigen weder in wie weit die entwickleten Lösungen dem Stand der Technik entsprechen noch, dass diese mit Hinblick auf technische Schulden nachhaltig zu entwickeln sind.

Das Fehlen der Leitplanken Marktgestaltung und technische Aktualität erlaubt nach unserem Verständnis ein Fortbestehen von marktoffenen Modellen mit einem Anbieter im Bereich der einzelnen Fachverfahren aufgrund der hohen Einstiegshürde in den stark regulierten Markt, bei einem gleichzeitig geringem Marktvolumen.

Die Leitplanken Befähigung, Adaptierbarkeit und Technische Aktualität wären nach unserem Verständnis notwendig um der Bevölkerung und anderen Nutzer*innen Lösungen anzubieten die mit dem Stand der Technik übereinstimmen. Ein überdeutliches Zurückstehen der Verwendeten Lösungen hinter dem Stand der Technik im Bereich der Digitalen Daseinsvorsorge schwächt das Vertrauen der Bevölkerung in die Handlungsfähigkeit des Staates und seiner Institutionen. Dies zeigt beispielhaft die Verschiebung der Halbierung der Ersatzfreiheitsstrafe nach $43 StGB, siehe: https://www.lto.de/recht/hintergruende/h/ersatzfreiheitsstrafe-haft-gefaengnis-geldstrafe-umrechnung-it-software-bund-laender-bayern-linke/

07. Grundprinzipien „European Interoperability Framework“

Datum der Veröffentlichung: 09.11.2023
Anzahl eingegangener Antworten: 26
Issue # in GitLab: #143
Leitfrage 07

Bei der Erstellung der strategischen Leitplanken wurden die zwölf Grundprinzipien „European Interoperability Framework“ (EIF) berücksichtigt. Halten Sie dies für sinnvoll oder würden Sie weitere Prinzipien ergänzen?

Link zum EIF

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

T.G - original vom 14.11.2023

IBM empfiehlt das Leitprinzip 6 “ user centricity“ um den Gedanken des Ende-zu-Ende Geschäftsprozesses zu erweitern.

Nur durch eine ganzheitliche Betrachtung der Geschäftsprozesse können alle prozessrelevanten Rollen, deren zugehörigen Prozessaktivitäten, sowie zeitliche und dynamische Abhängigkeiten strukturiert erhoben und betrachtet werden.

M.N.AKDB - original vom 17.11.2023

Das EIF bzw. EIF4SCC wird als geeignet angesehen. Es sollte überprüft werden, ob es vor diesem Hintergrund einer Ableitung auf ein nationales Rahmenwerk bedarf, so wie es die Verordnung vorsieht und bspw. in Österreich erfolgreich praktiziert wurde? Die Berücksichtigung des föderalen Staatsaufbaus und die Beachtung der kommunalen Interessen kann hier einen notwendigen Abweichungsgrund darstellen.

Insbesondere die Betrachtungsweise nach technischen, semantischen, organisatorischen und rechtlichen Aspekten ermöglicht eine holistische Betrachtungsweise.

Allerdings datiert der EIF zuletzt aus dem Jahr 2010. Deshalb sollte im Konsultationsprozess bereits auf das "Gesetz für ein interoperables Europa" (Interoperable Europe Act Proposal; https://commission.europa.eu/publications/interoperable-europe-act-proposal_de) - 2022/0379 - abgestellt werden. Dieses hat kürzlich den EU-Rat und das EU-Parlament passiert.

Darin hat sich die EU auf die Verbesserung der grenzübergreifenden Zusammenarbeit im öffentlichen Sektor geeinigt. Es soll Verwaltungsvorgänge in verschiedenen Bereichen effizienter gestalten und wiederholte Informationsanforderungen an Bürger und Unternehmen reduzieren. Es zielt darauf ab, vollständig automatisierte und digitalisierte Verwaltungsprozesse zu etablieren. Die Interoperabilität, die über technische Aspekte hinausgeht, soll Datenschutz und Barrierefreiheit berücksichtigen. Die Verordnung muss noch offiziell angenommen werden, um wirksam zu werden.

Damit ist der Konnex zu der Registermodernisierung angelegt. Somit ist das OOTS und das NOOTS ebenfalls in die Betrachtung der relevanten Leitplanken mit einzubeziehen und die OZG-Rahmenarchitektur als Nationalen Interoperabilitätsrahmen (NIF) zu verstehen.

D.T.OZG.S - original vom 17.11.2023

Die Prinzipien des EIF sind aus Sicht der Deutschen Telekom geeignet, um innerhalb der OZG-Rahmenarchitektur Anwendung zu finden.

Ergänzende Prinzipien wurden bereits im Rahmen der Leitfrage 06 aufgeführt und erläutert.

Es empfiehlt sich, im Rahmen der Entwicklung und Umsetzung einer OZG-Rahmenarchitektur konkrete Maßnahmen zu ergreifen, welche die Implementierung der Prinzipien unterstützt bzw. die Einhaltung der Prinzipien ermöglicht.

Für die Etablierung einer Architektur wie der OZG-Rahmenarchitektur ist erforderlich, dass Eindeutigkeit bzgl. der bestehenden Prinzipien gelten muss. Insofern sollte vor dem Hintergrund bestehender Redundanzen zwischen EIF, föderaler IT-Architekturrichtlinie und Leitplanken der OZG-Rahmenarchitektur die Abhängigkeiten / Koexistenz überprüft und beseitigt werden.

Frage07_OZGRahmenArchitektur_Konsultationsprozess

D.K - original vom 19.11.2023

Die Einbeziehung der zwölf Grundprinzipien des European Interoperability Framework (EIF) ist sinnvoll, da sie bewährte Leitlinien für die Interoperabilität bieten. Diese Herangehensweise gewährleistet nicht nur eine wirkungsvolle und durchdachte Interoperabilität auf europäischer Ebene, sondern mindert auch erheblich die Komplexität für alle Umsetzenden. In diesem Sinne plädieren wir dafür, auf nationaler Ebene keine Zugeständnisse zu machen, die potenziell zu Verschlechterungen führen könnten. Eine strikte und unveränderte Anwendung der EIF-Prinzipien ermöglicht eine konsequente Umsetzung, ohne Abweichungen. Dieser Ansatz sichert, dass die Interoperabilität auf einem einheitlichen Standard beruht und erleichtert somit die Zusammenarbeit und den Austausch von Daten zwischen den Mitgliedstaaten. Eine konsequente Umsetzung der zwölf Grundprinzipien fördert die Harmonisierung und trägt maßgeblich dazu bei, die Digitalisierung im öffentlichen Sektor auf effiziente und transparente Weise voranzutreiben.

D.S - original vom 19.11.2023

Die Grundprinzipien EIF erscheinen grundsätzlich sinnvoll. Allerdings fehlt uns als Leitplanke die Souveränität der geschaffenen Lösungen. Dabei ist diese noch zu definieren, da es keine einheitliche Definition für digitale Souveränität gibt. Diese kann sich nicht nur auf OpenSource beschränken, sondern muss alle möglichen Lösungen einschließen.

M.D - original vom 20.11.2023

Ich halte das EIF grundsätzlich für eine gute Vorlage, um daraus ableitend verbindliche Vorgaben für die öffentliche Hand zu erstellen. Im EIF fehlen allerdings Empfehlungen bzgl. Authentifizierung als auch zur Datenhaltung (Stichwort assume breach-Architekturen). Der Scope "OZG" wäre aber für solche Vorgaben zu klein gedacht.

S.M - original vom 20.11.2023

Bundesagentur für Arbeit: Die genannten Leitplanken sind eine gute Ergänzung zu den erwähnten Servicestandards zum OZG.

E.S - original vom 20.11.2023

Bitkom e.V.

In unseren Augen sind die Grundprinzipen sinnvoll und sie decken relevante Prinzipien ab. Allerdings enthalten sie keine wesentlichen Neuerungen, gehen nicht sonderlich in die Tiefe und stellen eher eine Zusammenfassung gängiger Standards dar, die in Deutschland bereits teilweise durch die eingeführten Servicestandards abgedeckt werden. Zudem sehen wir eine zentrale Herausforderung in der Frage der Operationalisierung der Prinzipien. Bei der Entwicklung weiterer Prinzipien sollte die Nachnutzung und Wiederverwendbarkeit der Module bedacht werden. Dazu gehört generell eine modulare Erstellung von Lösungen (auch mit LowCode-Ansätzen) und die Möglichkeit der Einbeziehung und Entwicklung unter Citizen Developern.

J.E - original vom 20.11.2023

Wir halten die Prinzipien des EIF für sinnvoll und und umfassend. Aus ihnen sollten verbindliche Vorgaben für die Umsetzung entwickelt werden.

S.G - original vom 20.11.2023

Aus Sicht der VISION Consulting GmbH ist die Berücksichtigung der zwölf Grundprinzipien sinnvoll. Die Grundprinzipien sollten einer Validierung unterzogen, sowie übersetzt, in deutsche Rahmenwerke übernommen und aktiv verbreitet werden.

S.L.B - original vom 20.11.2023

Die Orientierung an europäischen Standards, wie dem European Interoperability Framework, wird von der Bundessteuerberaterkammer begrüßt. Zu beachten ist, dass unterschiedliche und teils konkurrierende Methoden zu widersprüchlichen Zielen führen können. So wird (mit Referenz auf Leitfrage 4) im bisherigen Entwurf der föderalen IT-Architekturrichtlinien bereits ein Architekturframework verwendet. Die in TOGAF definierten Leitfragen eignen sich ebenso zur Diskussion von strategischen Leitplanken.

Sofern beide Frameworks parallel im Konsultationsprozess Anwendung finden, muss die Abgrenzung eben dieser sichergestellt werden. Bestenfalls aber wird eine führende Methodik gewählt.

M.P - original vom 20.11.2023

Zusätzlich zu den Grundprinzipien der EIF halten wir diese Guidelines für sinnvoll:

Erleichterung von Grenz- und sektorübergreifender Interaktion zwischen europäischen Verwaltungen

Ermöglichung elektronischer Dienstleistungen

Zusammenarbeit unterstüstzen

Sicherstellung von Governance, Koordination und Austausch von Interoperabilitätsinitiativen

Entwicklung organisatorischer Interoperabilitätslösungen

M.M - original vom 21.11.2023

wichtig sind

Offenheit, Wiederverwendbarkeit und Transparenz

Nutzerzentrierung ist ebenfalls ein wichtiges Thema für die Akzeptanz

was fehlt

ist die Lesbarkeit. In 2.12 steht was von "Informationen aufbewahren, um sie zu bewahren". Was hier fehlt ist die Zugänglichkeit, ich muss also auch dafür sorgen, dass Fileformate bzw Software zum Zugriff passend mitgepflegt werden, damit ich noch an die Infos rankomme.

von Maschinenlesbarkeit wird gesprochen, aber nicht von Maschineninterpretierbarkeit. Alle Prinzipien hier sind erfüllbar, auch wenn immer ein Mensch dasitzen muss und vieles manuell macht. Ich würde stark dafür plädieren, dass die Daten auch so dokumentiert und verfügbar sein müssen, dass man damit etwas automatisch anfangen kann.

man müsste drauf achten, dass hier keine eigene Interpretation der Prinzipien gebastelt wird sondern dieser Text eingesetzt wird. "Berücksichtigen" klingt eher nach Wunschkonzert.

Klare Zuständigkeiten. Wer ist für was der Ansprechpartner bzw. wer wäre verantwortlich, wenn es irgendwo Probleme gibt oder ich sonst Feedback habe. Auf der anderen Seite sollte hier auch ein Zuständigkeitsgerangel verhindert werden, wie wir es derzeit ja immermal wieder sehen (ggf hier auch die Abwägung zwischen Länder, Bundes oder EU-Zuständigkeiten)

A.S - editiert am 21.11.2023

Aus Sicht der DigitalService GmbH des Bundes:

Im Großen und Ganzen sind diese strategischen Leitplanken sinnvoll. Allerdings ist es entscheidend zu verstehen, was die einzelnen Punkte im Detail beinhalten und wie stark ihre Ausprägung reguliert ist.

Bei den Interoperabilitäts-Standards beispielsweise sollten diese so umfassend innerhalb der Rahmenarchitektur gestaltet sein, dass sie technische, rechtliche und wirtschaftliche Aspekte abdecken. Es geht darum, dass Systeme verschiedener Art effizient interagieren und Daten austauschen können. Hierbei ist die Integration von einheitlichen Schnittstellen, Protokollen und Formaten in spezifischen Systemen denkbar, während in offenen Systemen die Existenz solcher Schnittstellen allgemein vorausgesetzt wird. Ein rein technischer Fokus, unabhängig davon, wie eng er gefasst ist, könnte jedoch zu kurz greifen. Diese Standards sollten daher auch Lizenzmodelle, mit den rechtlichen und wirtschaftlichen Aspekten, berücksichtigen. Aktuell wird bemängelt, dass die jetzigen gängigen Lizenzmodelle, die den Status Quo stärken, die Weiterentwicklung und die Interoperabilität einschränken. Ebenso unerlässlich ist es, die notwendigen Fähigkeiten für die Implementierung und Weiterentwicklung von Interoperabilitätspolitiken zu entwickeln und anzuerkennen, dass Interoperabilität ein multidimensionales Thema ist, das ein Bewusstsein und Fähigkeiten in verschiedenen Bereichen erfordert (u.a. die generelle Governance).

Das "European Interoperability Framework" (wie auch bei Frage 7 erwähnt) geht in diesen Punkten noch detaillierter vor. Welche Aspekte sind davon konkret in diese Leitplanke eingeflossen?

Und wie sind die anderen Leitplanken im Detail gestaltet? Wie sehen die jeweiligen Ziel- und Erfolgskriterien aus?

J.P - original vom 21.11.2023

Antworten Team PwC: - Framework greift strategisch wichtige Punkte/ Leitplanken auf, aber es benötigt einen konkreten Praxisbezug mit dem Ziel die Verwaltungsdigitalisierung zu ermöglichen. - Use-Cases und Best-Practices aus der Verwaltungsdigitalisierung sollten genutzt werden, um ein Framework zu entwickeln, welches sich an der praktischen Umsetzung/ Implementierung orientiert. - Ein Austauschformat auf europäischer Ebene würde das Framework sinnvoll ergänzen (Vorstellung von Best Practices, Diskussion zu gemeinsamen Herausforderungen und Lösungen) - Seine Grundsätze und Konzepte reichen nicht aus, um Interoperabilitätsprobleme vollständig zu lösen, aber das EIF ist ein nützlicher Rahmen, um ein Problem anzugehen.

T.K - editiert am 27.11.2023

Sammlung CDO-MID Sachsen-Anhalt und Vertreter von Kommunen des Landes:

Ökosysteme der Länder und ihrer Kommunen mit dem jeweiligen Partnermanagement in die das Bundes-Ökosystem aufnehmen. Marktplatz der öffentlcihen DL muss entstehen, so dass über MArktmechanismen eine Preisreduktion der Angebote gegenüber dem Bund, der Länder und Kommunen entstehen kann.

Am Modell Sachsen-Anhalt erklärt: Das Land und die Kommunen unterstützen die KITU beim Aufbau eines Partnermanagements auf Basis der eigenen Anforderungen und Erfahrungen. Startups, private und öffentliche ITDienstleister sind Teil der beteiligten Dienstleister, welche durch die KITU gesteuert und betreut werden.

Hier könnte die Schnittstelle dann GovDigital oder Vitako sein.

Subsidiarität und Verhältnismäßigkeit: Ermöglichung und Freiwilligkeit sind sehr wichtig. Blinde Verpflichtungen sind nicht zielführend. Allerdings dürfen Subsidiarität und Verhältnismäßigkeit nicht dazu führen, dass Digitalisierung kompliziert und ineffizient wird.

Open Data / Open Source: Ist sehr unterstützenswert und wichtig für die herstellerunabhängige Nachnutzung. Allerdings haben Kommunen wenig Ressourcen, um eigenständig offene Daten und Software pflegen zu können und nutzen daher leider viel zu oft herstellerabhängige, proprietäre Formate (keine Lösung in Sicht).

Nutzerfreundlichkeit: Bitte nicht nur die Bürger als Nutzer identifizieren, sondern auch die Mitarbeiter in den Verwaltungen. Auch das Backend muss einfach und nutzerfreundlich zu bedienen sein, denn in Zeiten von Fachkräftemangel und hoher Mitarbeiterfluktuation ist es notwendig, schnelle Einarbeitungen und langfristige Nutzung zu ermöglichen. Weiterhin ist es wichtig, dass „digital first“ gilt (Siehe auch Prinzip 10). Denn so wichtig die Erreichbarkeit über verschiedene Kanäle ist (Multi-Channel), die Zugänge müssen auch für die Verwaltungen bedienbar sein, damit die Bürger eine gute Customer Journey haben und mit der Leistung zufrieden sind. Dies trägt zur Demokratiezufriedenheit bei (siehe: eGovernment Monitor 2023).

Inklusion and Barrierefreiheit: siehe Anmerkungen unter 6.: Barrierefreiheit muss auch seitens der Verwaltung finanzierbar und umsetzbar sein (weitere Infos gerne mündlich, falls für Sie interessant).

Mehrsprachigkeit: siehe 7.) und: Für die EU ist hier vor allem Mehrsprachigkeit (in Schriftform) am relevantesten. Hierfür brauchen Kommunen definitiv noch Hilfe, da die Amtssprache Deutsch ist und viele Verwaltungsmitarbeiter ausschließlich Deutsch sprechen. Für Übersetzungen mithilfe von Vorlesefunktionen haben die Zielgruppen bereits ihre Tools. Auch kommunale Websites bieten bereits mehrsprachige Vorlesefunktionen an.

*Generell wird das Framework als sinnvoll erachtet.

*Betonung wird nochmal auf die Ergebnisse des CIO-Projekts in Sachsen-Anhalt gelegt. Für die Funktionsfähigkeit der bundesdeutschen Verwaltung mit Ihren unterschiedlichsten Arbeitsständen wird es für notwendig erachtet, dass bundesintern erst einmal Einigung erzielt wird, bevor wir uns dann noch mit anderen Ländern zusammenschalten.

*Schlussendlich entscheiden die starken Player, die weiterentwickelt sind immer ein Stück weit für alle anderen mit, obwohl deren Stand nicht zwingend für alle anderen gleich gut sein muss.

M.H - original vom 24.11.2023

Universtität Duisburg-Essen, HISinOne-Cm.nrw: Diese Prinzipien und Richtlinien sind grundsätzlich positiv und decken wichtige Aspekte wie Offenheit, Transparenz, Sicherheit, Nutzerzentrierung und Effizienz ab. In Anbetracht dessen kann das EIF für sinnvoll erachtet werden und es besteht keinen unmittelbaren Bedarf für zusätzliche Prinzipien.

F.K - editiert am 28.11.2023

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen:

-Sustainability / Nachhaltigkeit: Digitalisierung nicht kurzfristig, sondern mittel- bis langfristig denken; Berücksichtigung bestehender (Sonder-) Strukturen wie bei den eher dezentral organisierten Hochschulen
- User-centricity / Nutzendenorientierung: nicht nur Endnutzer im Blick haben, sondern alle am Prozess Beteiligten als Nutzer verstehen, d.h. auch Wertsteigerung durch Digitalisierung für z.B. Sachbearbeiter-Ebene - Gesamtprozess-Betrachtung: entspricht in anderer Weise dem Punkt User-centricity / Nutzendenorientierung: Nicht nur das Front-End betrachten/berücksichtigen, sondern den Gesamtprozess inkl. Back-End - Weitere mögliche Prinzipien: - Reusability: entspricht dem deutschen EfA – Einer für Alle-Ansatz - Der Einer-Für-Alle Ansatz ist in Deutschland ein gutes Prinzip, dass auf Zusammenarbeit und Synergien deutschlandweit setzt. Bei den Hochschulen müssen dafür die dezentralen und umfangreich vorhandenen Strukturen und digitalen Lösungen berücksichtigt werden.

D.H - original vom 28.11.2023

Die Prinzipien sind eine gute Grundlage und finden sich in ähnlicher Form auch bei Gaia-X (https://gaia-x.eu/wp-content/uploads/2021/12/Vision-Strategy.pdf), OSBA (https://osb-alliance.de/ueber-uns/leitlinien-der-osb-alliance-2022), SHIELD (https://www.shield24.de/manifest.html) und nicht zuletzt bei Mozilla (https://www.mozilla.org/de/about/manifesto/).

D.U - original vom 04.12.2023

Als Materna SE/Infora GmbH empfehlen wir, Komponenten zur Umsetzung von Barrierefreiheit in der Architektur explizit zu berücksichtigen. Deshalb sollte dies als weiterer Punkt mit bedacht werden. Diese Anforderung ist dann entsprechend in der OZG-Rahmenarchitektur fortzusetzen.

S.L - original vom 05.12.2023

Demokratiefördernd/schützend

K.G - original vom 08.12.2023

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister:

Die Berücksichtigung der zwölf Grundprinzipien des "European Interoperability Framework" (EIF) bei der Erstellung der strategischen Leitplanken für die OZG-Rahmenarchitektur ist aus Sicht der VITAKO sinnvoll, da das EIF eine umfassende und bewährte Grundlage für die Förderung von Interoperabilität in der öffentlichen Verwaltung bietet. Zusätzlich zu den EIF-Grundprinzipien könnten auch weitere Prinzipien in die strategischen Leitplanken aufgenommen werden, insbesondere solche, die spezifisch auf die Anforderungen und Ziele des OZG und der deutschen Verwaltung zugeschnitten sind. Dazu könnten beispielsweise Aspekte wie Barrierefreiheit, Datensicherheit, Bürgerbeteiligung und Innovation gehören. Darüber hinaus sollte die Registermodernisierung mit der Anbindung an das OOTS bzw. NOOTS ebenfalls in der OZG-Rahmenarchitektur berücksichtigt werden.

G.B - original vom 28.01.2024

Grundsätzlich ja. Bisher besteht keine Möglichkeit für die Vertretungen von Berechtigten Nutzer*innen sich in den Prozess einzubringen, da die Diskusion die erwarteten Implikationen nicht aufgreift. Die bisherigen Ansätze scheinen nicht hinreichend um bspw. Interessenvertretungen im Sinne der im OZG Kontext üblichen Lebenslagen anzusprechen.

06. Strategische Leitplanken

Datum der Veröffentlichung: 09.11.2023
Anzahl eingegangener Antworten: 33
Issue # in GitLab: #142
Leitfrage 06

Welche strategischen Leitplanken sollen bei der Erstellung der OZG-Rahmenarchitektur zugrunde gelegt werden? Würden Sie zu den bisher berücksichtigten Leitplanken weitere hinzufügen?

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

231205_Strategische_Leitplanken

F.S - editiert am 15.11.2023

Aus meiner kommunalen Sicht wäre es sinnvoll, den Aspekt "Autarkie der Länder" nicht in die föderale und kommunale Ebene durchzureichen. Es bedarf zwingender Nutzungs- und Verfahrens-Vorgaben sowie technischer Standards, Förderalismus und kommunale Selbstverwaltung machen im Kontext der handwerklichen Ausführung der (ansonsten zuständigkeitsmäßig unangetasteten) Aufgaben schlicht keinen Sinn (und sind m.E. auch nicht rechtlich zwingend) und sind im Licht der Grundsätze von Wirtschaftlichkeit und Sparsamkeit fatal.

A.B - original vom 14.11.2023

Aus Sicht der bayrischen IHKs könnten die Leitplanken um die Betriebsumgebung ergänzt werden. dezentral in z.B. Landratsämtern bis hin zu zentral in (nicht-)öffentlichen Cloudumgebungen

M.N.AKDB - original vom 17.11.2023

Die Leitplanken sollen zunächst einmal homogen zu den grundlegenden Prinzipien des Staatsaufbaus kompatibel sein und diese nicht konterkarieren. Deshalb ist grundsätzlich die Vereinbarkeit mit dem föderalen Staatsaufbau als Eigungsmaßstab anzuführen - und weiterhin die Berücksichtigung der kommunalen Gegebenheiten.

Neben den sieben formulieren strategischen Leitplanken (Zuschnitt der Architekturbausteine, Transformationsgrad ...) erscheinen insbesondere folgende Dimensionen als notwendig:

Digitale Selbstbestimmung Bürger/Unternehmen (u.a. Digital first/only), siehe auch Art. 10 BayDiG Digitale Handlungsfähigkeit: Grad und Transparenz der Interaktionsmöglichkeiten des Bürgers (u.a. one-stop-shopping vs. Push Government)

Automatisierungsgrad

Nachhaltigkeit

Open Source

Nachnutzung Europäische Standards

Multilingualität

Datenschutz

D.T.OZG.S - original vom 17.11.2023

Die bisher berücksichtigten Leitplanken, welche auf den Grundprinzipien des Europäischen Interoperabilitätsrahmens (EIF) basieren:

•       Zuschnitt der Architekturbausteine

•       Transformationsgrad

•       Interoperabilitäts-Standards

•       Qualitätsstandards

•       Autarkie der Länder

•       Größe des Ökosystems

•       Digitale Souveränität

werden von Seiten der Deutschen Telekom im Grundsatz unterstützt.

Für die strategische Leitplanke „Autarkie der Länder“ würde wir eine Umbenennung in „Autarkie“ vorschlagen. Dieses vor dem Hintergrund das alle drei Ebenen (Bund, Land und Kommunen) einbezogen werden sollten.

Folgende Leitplanken bzw. Aspekte, die innerhalb der Leitplanken behandelt werden sollten, sind uns darüber hinaus wichtig und sollten Berücksichtigung finden:

•       Skalierbarkeit

•       Einfachheit, Ergonomie in der Nutzung für Service Provider und Bürger

•       Offener Zugang und Barrierefreiheit ohne Diskriminierung

•       Cyber-Security / ID-Security

•       Datenschutz nach DSGVO und GDPR

•       Selbst-Souveränität des Bürgers im Mittelpunkt

•       Internationale und Europäische Kompatibilität (z.B. zur European Digital Identity)

•       Open Source

•       Aufgabenkritik / Prozessoptimierung vor Digitalisierung

In der weiteren Entwicklung des Zielbildes der OZG-Rahmenarchitektur kommt es aus unserer Sicht entscheidend darauf an, welche konkrete Ausgestaltungsformen die einzelnen Leitplanken annehmen bzw. welche Freiheitgrade gegeben sind, bzw. welche zentralen Vorgaben gesetzt werden.

Anhand der strategischen Leitplanke „Autarkie“ lässt sich diese Herausforderung sehr gut exemplarisch darstellen. Hier besteht grundsätzlich die Bandbreite von einer „Vollständigen Autarkie“ bis hin zu „Keiner Autarkie“ also der ausschließlichen Nutzung von zentral bereitgestellten Systemen. Beide Extremfälle sind in der Praxis zwar in ihrer Reinform unrealistische Szenarien, jedoch kann eine OZG-Rahmenarchitektur entscheidende Auswirkungen auf den „Ausschlag des Pendels“ haben. Wir begrüßen vor diesem Hintergrund ausdrücklich die aktuelle Plattformdiskussion und unterstützen die in der NEGZ-Kurzstudie (vgl. NEGZ-Kurzstudie „Government as a Platform in Deutschland“ - https://negz.org/publikation/government-as-a-platform/) gegebenen Handlungsempfehlungen:

1. Architektur: Klare Benennung und Definition der Infrastruktur

2. Leadership: Eindeutige Zuordnung der Rollen, insbesondere eines Infrastruktur-Owners

3. Ko-Kreation: Förderung des Ökosystems durch Öffnung der Infrastruktur

4. Personal: Plattformprofis an der Spitze und in der Breite

Vor dem Hintergrund dieser Empfehlungen wäre die Überlegung auch valide die Leitplanke „Autarkie“ in eine Leitplanke „Etablierung des Plattformansatzes“ umzubenennen.

Im Rahmen des Plattformansatzes müssen jedoch immer beide Seiten, also der zentrale und der dezentrale Bereich betrachtet werden. Deutschland ist föderal organisiert, und jede Verwaltung, mag sie noch so groß oder klein sein, muss in der Lage sein, eigenständig Behördendienste anzubieten. Wenn wir dieses Prinzip auf digitale Dienste übertragen, sollte ebenfalls das Grundprinzip der dezentralen und verteilten Architektur verankert werden – das, was auch den Erfolg des Internets ausmacht. Jede Partei sollte in der Lage sein, ihre eigenen Services selbstsouverän ins Netz zu stellen. Ohne eine ergänzende Richtlinie zur 'Dezentralen Architekturvorgabe' besteht die Gefahr, dass wenige zentrale Dienste von einzelnen Organisationen als „Monopol“ aufgebaut werden, was das Risiko birgt, eine träge Architektur mit geringer Innovationskraft zu schaffen.

Neben dem dezentralen Hosten von OZG-Diensten bedeutet "Dezentralität” auch, dass keine zentral kontrollierten Benutzerkonten vorgegeben werden dürfen und kein zentrales Identitätsmanagement (IdM) existieren darf, welches vom Staat oder einer Organisation kontrolliert wird. Es sollte eine Richtlinie geben, die sowohl selbst gehostete Benutzerkonten als auch die selbstsouveräne Auswahl von vertrauenswürdigen Kontenanbietern, staatlichen als auch nichtstaatlichen, berücksichtigt. Die Schnittstellen und Protokolle werden dabei umso wichtiger, da sie automatisiert und medienbruchfrei funktionieren müssen (übergreifend mit einer gültigen und vertrauenswürdigen Identität).

E-Mail dient als Informationskanal und wird heutzutage bedauerlicherweise in nahezu jedem Prozess zur Kommunikation und Datenaustausch genutzt, wodurch auch vertrauliche Informationen der OZG-Prozesse, selbst wenn es sich nur um Metainformationen handelt, darüber ausgetauscht werden. Öffentliche E-Mail-Kontenanbieter wie Google, WebDE, Microsoft, etc. (nahezu jeder Bürger verwendet diese) verwenden diese Informationen zu ihren Zwecken, was dazu führt, dass jede Behördenkommunikation nicht mehr privat ist. Es ist notwendig, eine Richtlinie aufzustellen, die E-Mails als Kommunikationsmittel in OZGProzessen ausschließt, dabei jedoch die User-Experience (UX - Benutzererfahrung), einschließlich Push-Nachrichten, nicht verloren geht.

Die oben als zusätzliche Empfehlung aufgeführt Leitplanke „Aufgabenkritik / Prozessoptimierung vor Digitalisierung“ möchten wir an dieser Stelle nochmal besonders herausstellen.

Qualitative Gewinne durch eine moderne IT-gestützte Softwarearchitektur bedürfen immer eines konsequenten Hinterfragens bestehender Verwaltungsprozesse. Ohne eine Verpflichtung zur Prüfung und anschließenden Vereinfachung dieser Prozesse wird es zu einer 1:1-Abbildung der aktuellen papiergestützten Prozesse kommen, ohne die möglichen Synergien zu nutzen, die modernisierte Register, Fachverfahren und Bürgerplattformen bieten. Eine Verpflichtung auf Prinzipien wie "digital first" unter Berücksichtigung eines "multi-channel-Ansatzes“ können hier wichtige Ansatzpunkte bieten.

Frage06_OZGRahmenArchitektur_Konsultationsprozess

D.K - editiert am 28.11.2023

Bei der Erstellung der strategischen Leitplanken sollten die folgenden Punkte berücksichtigt werden:

Interoperabilität: Gewährleistung einer nahtlosen Zusammenarbeit zwischen verschiedenen Verwaltungsebenen und –systemen.

Nutzerzentrierung: Fokus auf die Bedürfnisse der Bürgerinnen und Bürger, der Verwaltungsmitarbeitenden für eine benutzerfreundliche Gestaltung der digitalen Angebote.

Sicherheit und Datenschutz: Integration von robusten Sicherheitsmaßnahmen und die Einhaltung hoher Sicherheitsstandards.

Open Source: Der Einsatz von Open-Source-Lösungen verbessert die Transparenz, Flexibilität und Zusammenarbeit in der öffentlichen Verwaltung.

Open Documentation: Eine klare und offene Dokumentation bietet allen Beteiligten Transparenz und Nachvollziehbarkeit in die offene Software.

Open Standards: Sicherung einer interoperable IT-Landschaft im öffentlichen Sektor und die Vermeidung von Abhängigkeiten für den Staat.

Open API: Offene Schnittstellen sind der Schlüssel zur Integration und zur Schaffung einer nahtlosen, benutzerfreundlichen Verwaltung, die im Sinne des Einer-für-Alle-Prinzips die Möglichkeit zur effektiven Nachnutzung ökonomisch sinnvoll nutzen kann.

Open Data: Die Bereitstellung von offenen Daten ist der Schlüssel zur Schaffung eines datengetriebenen, effektiven Verwaltungssystems.

Das Leitbild der OZG-Rahmenarchitektur sollte ein offenes Ökosystem erstreben, das nicht nur die Entstehung, sondern auch die Förderung der OZG-Rahmenarchitektur in den Fokus rückt. Wir befürworten eine Abkehr von einem geschlossenen System, das sich aus einer Aneinanderreihung proprietärer Lösungen und Komponenten zusammensetzt – eine Art von Monokultur aus Exklusivprodukten, die in den vergangenen zwei Jahrzehnten als Flickenteppich fungierte.

D.S - original vom 19.11.2023

Die Leitplanken sollten möglichst allgemein aber doch konkret formuliert werden: – Kommunikation muss vertrauenswürdig sein – Datenschutz muss gewährleistet sein – Daten müsse sicher sein – Betrieb von Software muss sicher sein – die Infrastruktur muss souverän sein - alle Komponenten (Soft- und Hardware) müssen dafür aus Europa kommen – Das digitale Leistungsangebot muss barrierefrei sein – die Transport-Infrastruktur muss für Wirtschaft und Organisationen zugänglich sein – Gemeinsame Querschnitts-Infrastruktur muss geschaffen und genutzt werden (BundID, Payment, OSCI/XTA, ...) – zu berücksichtigende Standards müssen transparent an einem Ort bereitgestellt werden

TSA.S.W - original vom 20.11.2023

Ergänzend zu den bestehenden Leitplanken sind wir als TSA Public Service GmbH der Ansicht, dass folgende Punkte zusätzlich notwendig sind, um der Verwaltung auf allen föderalen Ebenen freie, offen und souveräne Entscheidungen bezüglich des Einsatzes von Anwendungen zu ermöglichen.

die Berücksichtigung von offenen technischen Standards

freie Entscheidung für Hersteller und Lizenzen

Sicherheits- und Datenschutzstandards

S.M - original vom 20.11.2023

Bundesagentur für Arbeit: Unter https://www.digitale-verwaltung.de/Webs/DV/DE/onlinezugangsgesetz/servicestandard/servicestandard-node.html sind bereits Servicestandards zum OZG veröffentlicht, die als Prinzipien definiert wurden. Darüber hinaus sieht die BA keine Notwendigkeit weitere Regularien zu erlassen.

E.S - original vom 20.11.2023

Als Bitkom ergänzen wir die Aufzählung um die folgenden Punkte:

EfA-Prinzip

Servicestandards

Reifegradbetrachtung

Dresdner Forderungen

B.S - original vom 20.11.2023

Für die GKV:

Aufgrund der zur Verfügung stehenden Infor-mationen ist nicht klar erkennbar, wie die Leitplanken zukünftig umgesetzt werden sol-len. Gelten die Leitplanken generell oder für Leistungen / Gruppen von Leistungen. Zusätz-lich ist nicht ersichtlich, unter welcher Leit-planke die Themen IT-Sicherheit / Daten-schutz verortet werden.

Hier wären weitere Informationen im weiteren Konsultationsprozess hilfreich, die jeweils im Vorfeld weiterer Beantwortungsanfragen zur Verfügung gestellt werden sollten.

Die Formulierung der Leitplanken ist für die GKV nicht passend. In der Leitplanke „Quali-tätssicherung“ wird ausschließlich auf landes- oder bundesspezifische Standards abgestellt. Für die GKV sind aber auch fachspezifische Vorgaben durch Gesetze oder Richtlinien ver-bindlich.

Die Leitplanke „ Autarkie der Länder“ sollte neutraler in „Autarkie der Umsetzenden“ um-benannt werden.

S.W - original vom 20.11.2023

"Strategische Leitplanken" bedeuten hier vor allem aus kommunaler Sicht:

Voller Fokus auf ein einfach zu bedienendes Backend mit allen Basics, die von der operativen Seite benötigt werden.

Digitalisierung als Unendlichkeitsaufgabe.

100%ige Mittelbereitstellung des Bundes für die Länder und die Kommunen, damit Digitalisierung auch in den kleinsten Kommunen ein Kinderspiel wird und auch mit wenig Personal durchgeführt werden kann.

Technologieoffenheit für Zukunftstechnologien, damit Verwaltungen in Deutschland maximal agil werden können.

Anbindung aller 11.000 Kommunen an den Sicherheitsverbund des Bundes (über die Länder), um Cyberangriffen ohne Angst vor dem Kontrollverlust der Kommunen entgegenzusehen.

Beendigung dieser elendigen Diskussion über die förderale Hoheit in der Digitalisierung: Diese wird nur in einer gemeinsamen Kraftanstrengung aller Bundesländer umgesetzt werden können!

Bundesländerübergreifende Task-Forces von Experten-Praktiker_innen für eine zügige Umsetzung aller OZG-Leistungen

S.G - original vom 20.11.2023

Aus Sicht der VISION Consulting GmbH sollten folgende strategische Leitplanken bei der Erstellung der OZG-Rahmenarchitektur zugrunde gelegt werden: - Nutzerzentrierung sowie Einfachheit, Ergonomie in der Nutzung - Offener Zugang und Barrierefreiheit ohne Diskriminierung - Zuschnitt der Architekturbausteine - Prozessoptimierung vor Digitalisierung - Interoperabilitäts-Standards - Qualitätsstandards - Digitale Souveränität - Cyber-Security / ID-Security - Datenschutz nach DSGVO und GDPR - Eindeutige Zuordnung der Rollen bei Entwicklung und Betrieb

S.L.B - original vom 20.11.2023

Die Bundessteuerberaterkammer empfiehlt den Aspekt „Sicherheit“ mit zu berücksichtigen, sofern dieser nicht durch die Leitplanke „Qualitätsstandards“ abgedeckt ist.

Aus Sicht der Bundessteuerberaterkammer hängt die Akzeptanz der Unternehmens- und Bürgerportale grundsätzlich auch vom erreichten Sicherheitsniveau ab. Ebenso wie die genannten Leitplanken sollte dieser Aspekte von einem Ende bis zum anderen diskutiert werden. Zum einen muss sichergestellt werden, dass Unternehmen / Organisationen und Bürger mit einem hohen Maß an Sicherheit bzgl. der verarbeitenden Daten rechnen können. Andererseits dürfen die technischen Hürden und Prozesse nicht zu komplex ausgestaltet sein, da ansonsten die Akzeptanz stark leidet.

E.H - editiert am 27.01.2024

Antwort von Bundesamt für Migration und Flüchtlinge (BAMF):

Im Kontext der strategischen Leitplanken möchten wir Folgendes besonders betonen:

Resilienz: Die OZG-Leistungen anbietende Behörde muss krisenfest sein → das erfordert u.a. auch die dezentrale Bereitstellung von Schnittstellen und Systemkomponenten sowie die Möglichkeit zur Behörden-eigenen Bearbeitung des Quellcodes und eigene Deployment-Zyklen

Souveränität

Interoperabilität

Siehe auch unsere Antwort zu Leitfrage 01

M.P - original vom 20.11.2023

Diese strategischen Leitplanken sollen zugrunde gelegt werden:

Einigung auf verbindliche Standards

Definition einheitlicher Schnittstellen

Bereitstellung zentraler Basisdienste- und Komponenten

Fokus auf Nutzerorientierung

Klare Definition der Aufgabenteilung in Bund, Ländern und Kommunen

Klare Beschreibung des Geltungsbereiches

Qualitätssicherung von IT Architekturen

Verwaltung als Plattform schaffen

M.M - original vom 21.11.2023

wichtig:

Zuschnitt der Architekturbausteine

der Mircroservices-Aspekt macht die Architektur Variabler und leichter Erweiterbar

Interoperabilität

Gewährleistet Wiederverwendung auf Europäischer Ebene

Wiederverwendung passender bzw. bereits verwendeter Standards ^

"Echte" Interoperabilität, d.h., frei verfügbare Dokumentationen, Quellcodes usw. ohne künstliche Barrieren oder Kontrollen.

Transformationsgrad sollte keine Leitplanke mehr darstellen, da das OZG bereits gilt. "Investitionsschutz" und "Disruption" gegeneinander auszuspielen hilft da wenig.

J.P - original vom 21.11.2023

Antworten Team PwC: - Weitere Leitplanke: Einbezug aller föderalen Ebenen inkl. Kommunen bei der Erstellung der OZG-Rahmenarchitektur (bspw. zentrale Steuerungsmöglichkeiten Bund) - Weitere Leitplanke: Leitplanke zur Nutzendenzentrierung

M.K - editiert am 28.11.2023

Antworten des Programmbereichs OZG-EU-OOTS der Gesamtsteuerung Registermodernisierung

Fraglich erscheint auf einen ersten Blick, in welcher Abhängigkeit die "Leitplanken" zu den "Grundprinzipien" stehen. Sollten die Leitplanken auf den Grundprinzipien basieren, decken diese nicht alle ab. Hinzugefügt werden sollte eine Leitplanke Nutzerfreundlichkeit sowie eine Leitplanke zu Cloud, welche auf die Cloudstrategie referenziert. Weitere Anmerkungen die sich auf die Ausprägungen beziehen sind nachfolgender Grafik zu entnehmen:

T.K - editiert am 27.11.2023

Sammlung CDO-MID Sachsen-Anhalt und Vertreter von Kommunen des Landes:

*Ein Fokus sollte auf der Wissensvermittlung und Zugang zu dem vorhandenen Wissen liegen. Bis dato wirkt es sehr so, dass die bis dato stark vertretenen Player (Hamburg, Bayern etc.) ihre Ziele vorantreiben und der Rest staunend stehend gelassen wird.

*Die Transparenz muss fokussiert werden, so dass jede Kommune zu jeder Zeit in den Prozess und die Meetings hineinzoomen kann und sich dort notwendige Informationen herausziehen kann.

*Bestenfalls sogar mit der Möglichkeit Bedarfe zu melden, welche von zentraler Stelle konsolidiert und priorisiert wird.

*Ein Beispiel hierfür ist Open CoDE: Mir war bis dato nicht bewusst, dass das ein so zentraler Bezugspunkt für diesen Prozess ist.

*Ich wäre auch sehr dafür, wenn neben dem SGSA tatsächliche Kommunen partizipieren, weil der SGSA auch wieder ein höheres Abstraktionslevel vertritt.

*Für Sachsen-Anhalt sollten an diesem Prozess gut vernetzte Kommunen partizipieren, die diesen Prozess auch in die Breite der Kommunen tragen.

*Wir bieten uns gern an. Dieses auf ministerialer Ebene abzuhandeln brächte den Nachteil des Unwissens (nicht beleidigend gemeint) der kommunalen Wirklichkeit.

*Ich kann mir auch vorstellen, dass gemeinsame Konsultationstermine zwischen LSA und Kommunen einen Mehrwert bringen für diesen Prozess.

*So könnte LSA zeigen, dass hier wirklich Land und Kommunen mit einer abgesprochenen Stimme sprechen.

*Ausbau datenschutzkonforme Mehrsprachigkeit - Dienste/Dienstleistungsbeschreibungen - auch unter Berücksichtigung der leichten Sprache

*Feedbackkomponente - Weiterentwicklung im Hinblick auf Abfragen zu Funktionalitäten/Problemen - Nutzerzentrierung erhöhen & Statistiktool - Zugriffe über die Nutzungen/Statistiken allen angeschlossenen Verwaltungen bereitstellen und als Open Data publizieren

Klare Kommunikation, wo Antragsprozesse stocken auf allen Verwaltungsebenen - Stichwort wo bricht der Bürger ab (z. B. Nutzung Identifizierung MUK/BundID, Nutzung Bezahlung, ....) - Nutzungsprobleme und Feedback fortlaufend prüfen, um Dienste und Komponenten weiter zu entwickeln.

*Efa-Mindestanforderungen entwickeln zu bundesweiten Anforderungen

*Cloudstrategie berücksichtigen, z. B. Souveränität und Bereitstellung der EfA-Dienstleistungen über Container

*generelle Ende-zu-Ende Digitalisierung

*Dienste nicht nur für bestimmte Fallkonstellationen erstellen - von Anfang an ganzheitlich denken und Varianten umsetzen

*Die Prinzipen sind sehr gut. Daher füge ich unter Leitfrage 07 nur Ergänzungen ein. Insbesondere Grundprinzip 10 „Administrative Vereinfachung“ hat viel Potential die Digitalisierung der Verwaltung zu beschleunigen – sofern es eine gesetzliche Verpflichtung auch für Kommunen untermauert.

M.H - original vom 24.11.2023

Universtität Duisburg-Essen, HISinOne-Cm.nrw:

Bei der Erstellung der OZG-Rahmenarchitektur sollten die bereits diskutierten strategischen Leitplanken wie Nutzerzentrierung, Interoperabilität, Datensicherheit und Datenschutz, Barrierefreiheit, Standardisierung sowie Effizienz und Effektivität im Vordergrund stehen. Diese Prinzipien gewährleisten, dass die digitalen Dienste und Prozesse der öffentlichen Verwaltung den Bedürfnissen der Nutzer:innen entsprechen und sicher, zugänglich und effektiv sind. Vorangestellt muss aber die Kultur bzw. Bereitschaft zur jeweiligen Prozesstransformation sein. Darüber hinaus könnten weitere Aspekte wie Nachhaltigkeit und kontinuierliches Feedback hinzugefügt werden, um die digitale Transformation umweltfreundlich und anpassungsfähig zu gestalten. Eine wichtige, ergänzende Leitplanke ist, dass digitale Dienste den Bürger:innen kostenfrei zur Verfügung stehen. Die Nutzung digitaler Dienste im Kontext Digitaler Identitäten, dem digitalen Austausch von Bildungsnachweisen etc. darf nicht zum Geschäftsmodell werden.

F.K - original vom 28.11.2023

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen:

Digitale Souveränität (möglichst nur Anbieter aus dem EU-Bereich, etc. Dienstleister (Datenschutzproblematik)

Maximale Interoperabilität

Weitere Leitplanken:

Urheberrecht (von komplett Open Source, zu komplett proprietär)

Transparenz

D.H - original vom 28.11.2023

Die 10 Gaia-X-Prinzipien (siehe https://gaia-x.eu/wp-content/uploads/2021/12/Vision-Strategy.pdf) würden dem deutschen E-Government gut tun: - Open - Transparent - Sovereign - Fair - Independent - Inclusive - Free - Federated - Innovative - Evolutionary

D.U - original vom 04.12.2023

Als Materna SE/Infora GmbH schlagen wir folgende Ergänzung der Leitplanken vor. Diese sind alternativ auch als Teil einer Präambel geeignet:

Fokus auf E2E-Digitalisierung des gesamten Verwaltungsprozesses

Automatisierungsfähigkeit 

Was bedeutet das konkret?

E2E-Digitalisierung des gesamten Verwaltungsprozesses

Die vollständig digitale Durchführung des Gesamtprozesses von der Antragstellung über die Zuordnung, die Sachbearbeitung und Mitzeichnung bis zur Bescheidübermittlung sollte in den Mittelpunkt rücken.

Häufig haben Prozesse, welche im Rahmen von OZG1.0 umgesetzt wurden, Bruchstellen, an denen keine elektronische Verarbeitung gegeben ist. Dies ist z. B. der Fall, wenn die Sachbearbeitung Anträge ausdrucken muss, aber auch, wenn bestimmte Nachweise nicht digital eingereicht werden dürfen, sondern eine papierbasierte Form erforderlich ist.

IT-Lösungen und Komponenten sollten möglichst breit nutzbar sein (vgl. EfA-Prinzip). Zugleich sollte die Lösung flexibel sein, so dass verschiedene Systeme angeschlossen werden können. Aufgrund der sehr heterogenen IT-Landschaft bei Bund, Ländern und Kommunen muss es einfach möglich sein, Fachverfahren oder eine E-Akte-Komponente anzubinden. 

Automatisierungsfähigkeit

Im digitalen E2E-Prozess sind Automatisierungsmöglichkeiten zu berücksichtigen, u.a. mit Blick auf Integration von KI und weiteren Technologien. Dazu sollte berücksichtigt werden, dass die Architektur Raum für Automatisierungskomponenten vorsieht und die Systeme die Fähigkeit zur Integration in und Steuerung durch Automatisierung mitbringen. Dies halten wir vor dem Hintergrund des zu erwartenden demographischen Wandels für wichtig. Dies ist auch in Bezug auf die Strategie, Low-Code Plattformen zu nutzen, von Bedeutung.

S.L - original vom 05.12.2023

Sprache/Kommunikation

Standardisierung und Ausrichtung an einem gemeinsamen standardisierten Prozess in der Verwaltung. An diesem richten Sich Funktionen und technische Lösungen zu einem durchgehenden abgestimmten Service aus. Services können dann große Synergien erzielen

K.G - original vom 08.12.2023

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister:

Bei der Erstellung der OZG-Rahmenarchitektur sollten aus Sicht der VITAKO die folgenden strategischen Leitplanken (ebenfalls) zugrunde gelegt werden: 1. Kunden- bzw. Nutzerorientierung 2. Interoperabilität 3. Open Source 4. Automatisierungsgrad 5. Nachnutzung Europäischer Standards 6. Sicherheit und Datenschutz 7. Flexibilität und Skalierbarkeit 8. Nachhaltigkeit 9. Multilingualität

G.B - original vom 28.01.2024

Die Antwort auf diese Frage findet sich in der Antwort auf Frage 9 wieder, siehe: https://gitlab.opencode.de/bmi/ozg-rahmenarchitektur/zielbild-ozg-rahmenarchitektur/-/issues/146note_107403

Zielbild

14. Nächste Schritte Konsultationsprozesses

Datum der Veröffentlichung: 17.01.2024
Anzahl eingegangener Antworten: 11
Issue # in GitLab: #153
Leitfrage 14: Nächste Schritte Konsultationsprozesses

Teilen Sie Ihre Erfahrung und Verbesserungsvorschläge in den dafür vorgesehenen Kommentarbereichen hinsichtlich folgender Themen:

Zielbilder pro Funktionsbaustein: Im nächsten Schritt werden aus den Architekturprinzipien und den Funktionsbausteinen langfristige und messbare "Zielbilder pro Funktionsbaustein" durch das Arbeitspaket des Föderalen IT-Architekturboards erstellt. Haben Sie konkrete Vorschläge für ein methodisches Vorgehen zur Zielbildererstellung? https://gitlab.opencode.de/bmi/ozg-rahmenarchitektur/zielbild-ozg-rahmenarchitektur/-/issues/153note_105865

Format Konsultationsprozess: Halten Sie das aktuelle Format des Konsultationsprozesses für geeignet, um weitere zukünftige Arbeitsergebnisse auf etwaige blinde Flecken zu prüfen? https://gitlab.opencode.de/bmi/ozg-rahmenarchitektur/zielbild-ozg-rahmenarchitektur/-/issues/153note_105868

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

OZG.R - editiert am 26.01.2024

Zielbilder pro Funktionsbaustein

Im nächsten Schritt werden aus den Architekturprinzipien und den Funktionsbausteinen langfristige und messbare "Zielbilder pro Funktionsbaustein" durch das Arbeitspaket des Föderalen IT-Architekturboards erstellt. Haben Sie konkrete Vorschläge für ein methodisches Vorgehen zur Zielbildererstellung?

Teilen Sie Ihre Erfahrung und Verbesserungsvorschläge unter diesen Kommentar.

SEITENBAU - original vom 26.01.2024

Wie gehen davon aus, dass es für jeden Funktionsbausteine bereits Lösungen gibt, die mehr oder weniger den Architekturprinzipien entsprechen. Ausgehend von Vorbedingungen, Randbedingungen und den bestehenden Lösungen sowie den Architekturprinzipien lassen sich Zielbilder pro Funktionsbaustein ableiten.

Vorab sollte bewertet werden, ob für einen Funktionsbaustein ein oder mehrere Zielbilder zulässig sind?

Ein grob skizziertes methodisches Vorgehen:

Feststellung der Ausgangslage: Welche rechtlichen, funktionalen und organisatorischen Vorbedingungen bestehen? Wie wurden die Funktionsbausteine bisher umgesetzt? Welche Stakeholder gibt es zu dem Funktionsbaustein?

Feststellung der Problemstellung: Wie lösen die bisherigen Funktionsbausteine die Vorbedingungen und wie halten diese die Architekturprinzipien ein? Welche Abweichungen gibt es und was sind die Hintergründe dazu?

Bewertung: Gibt es Lösungen, die bereits langfristige und messbare Zielbilder darstellen? Welche Gemeinsamkeiten haben diese? Warum sind diese langfristig und wie messbar? Warum sind andere Lösungen weniger geeignet und was müsste angepasst werden, damit diese geeignet sind?

Definition Zielbild des Funktionsbausteins: Aufbauend auf den erzielten Erkenntnissen, wird das Zielbild/Zielbilder entwickelt.

I.S - editiert am 26.01.2024

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister e.V.: Wir schlagen folgende Punkte für das methodische Vorgehen vor:

1. Analyse der Ausgangssituation: Wie ist es um die Funktionsbausteine derzeit bestellt? Analyse von Stärken, Schwächen, Zukunftsfähigkeit und Risiken.

2. Stakeholder-Analyse: Wer ist für den jeweiligen Funktionsbaustein verantwortlich? Gibt es Eigeninteressen, die einer Weiterentwicklung/Anpassung des FB u.U. im Wege stehen. Berücksichtigung von Erwartungen und Bedürfnissen der Stakeholder bei der Zieldefinition.

3. Vision und Mission entwickeln: Formulierung einer klaren Vision, die beschreibt, wie die Zukunft aussehen soll. Entwicklung einer Mission, die den Zweck und die grundlegenden Werte des Projekts festlegt.

4. SMART-Ziele setzen: Definition konkreter, messbarer, erreichbarer, relevanter und zeitgebundener Ziele (SMART-Kriterien). Berücksichtigung kurzfristiger und langfristiger Aspekte (Deutschland - Europa)

5. Strategische Schwerpunkte festlegen: Priorisierung von Handlungsfeldern, die zur Erreichung der Ziele notwendig sind. Festlegung strategischer Schwerpunkte, die die Richtung für zukünftige Aktivitäten vorgeben.

6. Szenario-Analyse durchführen: Berücksichtigung von sich möglicherweise ändernden Rahmenbedingungen (Szenario-Analysen) und Unsicherheiten.

7. Partizipative Prozesse einbinden: Involvement Stakeholder in den Prozess. Fortlaufender Konsultationsprozess, UAG, Lenkungskreise etc.

8. Ressourcenplanung: Welche Ressourcen (finanziell, personell, technisch) werden für die Umsetzung der Ziele benötigt.

9. Monitoring und Evaluierung einplanen: Definieren von Indikatoren, um den Fortschritt in Richtung der Ziele zu messen. Regelmäßiges Monitoring und Evaluierung, um Anpassungen vornehmen zu können.

10. Kommunikationsplan entwickeln: Interne und externe Kommunikation der Zielbilder entwickeln, Transparenz: Informieren aller relevanten Interessengruppen über die festgelegten Ziele und den Weg dorthin.

S.L.B - original vom 27.01.2024

Die Bundessteuerberaterkammer schlägt vor, dass sich jeweils Expertengruppen zusammenfinden, die sich analog der Beteiligtenstruktur des OZG-Konsultationsprozesses auch mit Teilnehmern der Wirtschaft und Verbänden, die in dem jeweiligen Bereich federführend Wissen beisteuern können, zu einzelnen Funktionsbausteinen und Leitplanken austauschen. Die Zielbilder können dann deutlich konkreter und praxisnah entwickelt werden. Durch den transparenten Ansatz hätten weiterhin alle Teilnehmer die Möglichkeit Rückfragen zu stellen oder Änderungsbedürfnisse mitzuteilen.

Für den Funktionsbaustein Identitätsmanagement und die strategische Leitplanke Vertrauensmechanismen bringt sich die Bundessteuerberaterkammer für eine solche Expertengruppe gern ein.

E.H - editiert am 29.01.2024

Antwort von Bundesamt für Migration und Flüchtlinge (BAMF):

Neben den Funktionsbausteinen sind die Anforderungen unter Berücksichtigung verschiedener Nutzendenwege der unterschiedlichen Nutzendengruppen zu definieren. Anhand einer User Journey Map sind die gewünschten Interaktionen mit den unterschiedlichen Zielgruppen (mobile Nutzende, eingeschränkte Nutzende, Experten/-innen, automatisierte Maschinennutzung) ganzheitlich zu betrachten. Die User Journey Map vermittelt ein einheitliches Verständnis und unterstützt die Konkretisierung der Anforderungen des Zielbilds.

Zudem sollte für die Beschreibung der Zielbilder eine einheitliche Struktur genutzt werden. Ähnlich einem System Context Canvas oder Business Model Canvas. Inhalte sollten die Ziele und Funktionen des Bausteins, die Qualitätskriterien, Nutzer, Schnittstellen etc. sein.

Pro Zielbild eines Funktionsbausteins kann es auch mehrere Reifegrade der Umsetzung geben, die man definieren kann. Z.B. hinsichtlich der automatisierten Integration zu anderen Funktionsbausteinen, Einhaltung von Kommunikations-/Datenstruktur-Standards, Abdeckung der zugeordneten Funktionen.

Zudem verweisen wir auf unsere Antwort zu Leitfrage 8 bzgl. der Capability Analyse (Capability Mapping).

Eine weitere Anmerkung bzw. Frage betrifft die "Messbarkeit". Sie verlangt nach einem vereinbarten Maßstab; existiert dieser, oder ist er noch zu vereinbaren? Da die Zielbilder der Kommunikation dienen, sollten verwendete Termini einem abgestimmten Glossar entnommen werden.

G.B - original vom 28.01.2024

Hier scheinen messbare Ziele für die Rahmenarchitektur nicht berücksichtig zu werden, dies in sämtlichen Dimensionen sog. Ethical, Legal Social Implications sowie einer langfristigen technsichen Planung die Fragen wie Codepflege berücksichtigt.

D.K - original vom 29.01.2024

Aus unserer Erfahrung ist ein methodisches Vorgehen zur Erstellung von Zielbildern pro Funktionsbaustein zentral, um Klarheit und Messbarkeit zu gewährleisten. Wir schlagen vor, im ersten Schritt eine klare Definition und Abgrenzung der einzelnen Funktionsbausteine zu erarbeiten. Darauf aufbauend sollten spezifische, messbare, erreichbare, relevante und terminierte (SMART) Ziele formuliert werden. Ein iteratives Vorgehen mit regelmäßigen Review-Zyklen könnte sicherstellen, dass die Zielbilder an sich ändernde Rahmenbedingungen angepasst werden können. Gut wäre auch die Integration eines Feedback-Mechanismus, der sicherstellt, dass Rückmeldungen aus der Praxis kontinuierlich eingebunden werden können.

- Frühzeitige PoC (technisch), um die Machbarkeit/Passung der Gedanken zu prüfen

- Interatives Vorgehen, dass die Erfahrungen der PoC einbezieht

S.M - original vom 30.01.2024

Bundesagentur für Arbeit: Wie bereits bei Leitfrage 13 / 5 geschrieben: Es empfiehlt sich Expertenzirkel zur inhaltlichen Fokussierung zu bilden und diese punktuell zu beteiligen. Dies würde den Aufwand insgesamt minimieren.

C.R - original vom 30.01.2024

Aus Sicht von BearingPoint halten wir es für wichtig, dass bei der Erstellung von Zielbildern, insbesondere bei einer weiteren Phase eines Konsultationsprozesses, auf eine kollaborative Zusammenarbeit geachtet wird. Anmerkungen an Zielbildern lassen sich direkt am Bild leichter hinzufügen und verstehen als in Kommentarsektionen als umfassender Text. Hierbei ist zu beachten, dass sich auf einen Standard in Hinblick auf Form und Semantik geeinigt wird (bspw. der XML-Austauschstandard von Archimate, welcher u.a. auch vom European Interoperability Framework genutzt wird) und dieser allen kommuniziert wird. So lassen sich bei interner Bearbeitung durch die Konsultationsteilnehmer auch Modelle leicht untereinander austauschen. Im Idealfall wird auf ein Kollaborationstool, zum Beispiel MEGA HOPEX, zurückgegriffen.

OZG.R - editiert am 23.01.2024

Format Konsultationsprozess

Halten Sie das aktuelle Format des Konsultationsprozesses für geeignet, um weitere zukünftige Arbeitsergebnisse auf etwaige blinde Flecken zu prüfen?

Teilen Sie Ihre Erfahrung und Verbesserungsvorschläge unter diesen Kommentar.

P.S - editiert am 25.01.2024

Ja, wir halten die Konsultationsprozess für geeignet, um konkrete Arbeitsergebnisse (bspw. erste Entwürfe der OZG-Rahmenarchitektur) in Phase 2 auf blinde Flecken zu überprüfen – siehe unseren Kommentar zu Thema 4 in Leitfrage 13.

F.K - original vom 25.01.2024

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen: -Ergebnistransperenz: Damit meine ich, dass wir nicht erst am Ende erfahren was aus den Beiträge geworden ist sondern schon zwischendurch was die Blackbox "Arbeitspaket" der Fitko mit unseren Beiträgen macht. Das finde ich wichtig, um das Engagement über solch einen langen Zeitraum aufrecht zu erhalten. Auch die Argumentation was das Arbeitspaket darüber denkt, finde ich für das Engagement wichtig. -Wäre eine Zusammenarbeit bei der Prozesssgestaltung mit https://next-netz.de/netzwerk/ und ähnlichen Netzwerken denkbar? -Breite Zustimmung der verschiedenen repräsentierenden Verbände von zukünftigen Nutzern der Architekturrichtlinie hilft als Commitment bei der Umsetzung.

SEITENBAU - original vom 26.01.2024

Um einen Bund- und Stakeholder-übergreifenden Blick zu haben, ist ein Konsultationsprozess aus unserer Sicht schon geeignet. Dieser kann abhängig vom betrachteten Funktionsbaustein, auf jeweils dessen Stakeholderkreis eingegrenzt werden.

I.S - original vom 26.01.2024

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister e.V.: Anhand des breit gefächerten Feldes der Teilnehmenden und den vorhandenen Expertisen zu den genannten Funktionsbausteinen wird das Format des Konsultationsprozesses als geeignet empfunden. Aus den Antworten zu Frage 13 und aus den Beiträgen, die im Rahmen des Webseminars 3 gesammelt wurden, ergeben sich Verbesserungsvorschläge, die das Potential haben, den Konsultationsprozess noch zu vertiefen.

E.S - original vom 26.01.2024

Für den Bitkom e.V.

Wir begrüßen sehr, dass vermehrt Konsultationen stattfinden und zur Co-Creation aufgerufen wird. Allerdings hat man im Laufe des Prozesses gemerkt, dass das Interesse und das Involvement doch über die Zeit nachließen. Das kann verschiedene Gründe haben, aber einer ist vielleicht, dass wir nur einzelne Informationen zur Arbeit des Arbeitspakets bekommen haben und nicht ersichtlich war, ob unsere Eingaben Anklang fanden.

Aus unserer Sicht sollte es die Möglichkeit geben, „blinde Flecken“ jederzeit formell melden zu können. Denkbar wäre eine zentrale Stelle, die für die Entgegennahme solcher Anmerkungen verantwortlich ist und entsprechend damit weiterverfährt.

D.S - original vom 27.01.2024

DATABUND e.V. Bundesverband der mittelständischen IT-Dienstleister und Softwarehersteller für den öffentlichen Sektor e. V.: Die vermehrten Konsultationen begrüßen wir als Verband sehr und befürworten auch weitere solche Prozesse, da es wichtig ist, den Input der Fachwelt in die Strategieentwicklung einzubeziehen, um realistischere Planungen und schnellere Umsetzungen zu ermöglichen. Allerdings darf dies keine Alibi-Veranstaltung sein, sondern sollte tatsächlichen Einfluss auf die Projekte nehmen, sonst wird die Motivation der Akteure schnell nachlassen und die Konsultationen versanden. Das wäre sehr schade für den eigentlich guten Ansatz. Grundsätzlich ist der Beteiligungsansatz auch weiter ausbaubar gemäß den Ansätzen von Humble Government aus Skandinavien, wo durch Beteiligung auch Einfluss auf politische Entscheidungen genommen wird. Mehr Fach- und Sachkompetenz in der Politik wären auch in Deutschland zu begrüßen.

S.L.B - original vom 27.01.2024

Mit der bisherigen Arbeitsweise wird ein hohes Maß an Transparenz angestrebt. Dies begrüßt die Bundessteuerberaterkammer sehr. Dieser Ansatz sollte in der Detaildiskussion nicht nur weitergeführt, sondern ausgebaut werden. Werden beispielsweise in Form von Zwischenberichten transparent gemacht, welche Antworten berücksichtigt wurden und welche blinden Flecken dadurch aufgedeckt wurden, hätten die Beteiligten eine Möglichkeit, diese Ergebnisse zu sichten und auf weiterhin unberücksichtigte Aspekte aufmerksam zu machen. Das Risiko, blinde Flecken zu übersehen sollte dadurch stark abnehmen.

Der Ansatz der Zusammenarbeit in diesem bisherigen Format und die Ausweitung der Beteiligung zu einigen Fragestellungen wäre demnach Erfolg versprechend.

G.B - editiert am 29.01.2024

Nein, sowohl aufgrund der fehlenden Transparenz wie auch der Verkürzung der Debatte auf formale Anforderungen an eine technische Umsetzung die ökonomische Fragestellungen wie die der Marktgestaltung, einer nachhaltigen Technologieentwicklung im Sinne der Adaptierbarkeit und technischer Schulden sowie soziale Aspekte in Form einer Technikfolgenabschätzungen sind nach unserem Verständnis nicht Berücksichtigt.

Wir raten dringend an in einer Weiterentwicklung des Formates eine entsprechende Transparenz über die Eingaben, deren Auswertung und die entsprechenden Schlussfolgerungen herzustellen.

Wir bitten in diesem Rahmen die Stellungnahme des Innovationsverbund Öffentliche Gesundheit e.V. zur Änderung des Online Zugangsgesetzes zu vom 9. Oktober 2023 im Innenausschuss des Bundestages zu Berücksichtigen:

https://www.bundestag.de/resource/blob/970002/1d724ec34e15fc226488b13c866afdf2/20-4-303-A-data.pdf

D.K - original vom 29.01.2024

Das aktuelle Format des Konsultationsprozesses bietet bereits eine gute Grundlage für einen transparenten und inklusiven Austausch. Um jedoch eine noch umfassendere Prüfung auf blinde Flecken zu ermöglichen, empfehlen wir die Dauer der Konsultation zu verlängern. Zudem wäre die Nutzung der Open Code Plattform zum weiteren Austausch und zur Diskussion, die mit dem dann verlängerten Konsultationsprozess einhergeht, eine Möglichkeit, die Partizipation zu stärken und eine kontinuierliche Einbindung zu fördern.

E.H - original vom 29.01.2024

Antwort von Bundesamt für Migration und Flüchtlinge (BAMF):

Hand- oder Drehbücher für die Erstellung eines Zielbilds können helfen, bei identifizierten Qualitätsschwächen zurück zu verfolgen, wo in der Erstellung eines Zielbilds Fehler/Unterlassungen passiert sind, um den Erstellenden den Lernprozess zu erleichtern und damit die Qualität bausteinübergreifend anzuheben.

S.M - original vom 30.01.2024

Bundesagentur für Arbeit: Das aktuelle Format ist aufgrund der Menge an Teilnehmer und der dadurch eingeschränkten Möglichkeit zur Diskussion nur bedingt geeignet. Es wird empfohlen den Konsultationsprozess zu einem „Expertenzirkel“ weiter zu entwickeln, in dem nur noch jeder nach seiner Kompetenz einbezogen wird und es damit möglich wird die Fragen und Lösungen in einem kleinen Kreis wirklich zu diskutieren.

B.S - original vom 28.01.2024

GKV-Spitzenverband

| Das bisher gewählte Format kann dazu dienen, blinde Flecken bei der Ausgestaltung von Prozessen zu finden. Allerdings sollte zukünftig Wert darauf gelegt werden, die Fragen präziser zu stellen und Hintergrundinformationen zur Verfügung zu stellen. Mit größeren Verfahrensbeteiligten (bspw. Verbände) sollten die Vorschläge in kleinerer Runde bewertet und ggf. offene Punkte zu geklärt werden.

13. Erfahrung Konsultationsprozess

Datum der Veröffentlichung: 16.01.2024
Anzahl eingegangener Antworten: 13
Issue # in GitLab: #152
Leitfrage 13 Erfahrung & Verbesserungsvorschläge Konsultationsprozess

Wie könnte der Konsultationsprozess für die Zukunft verbessert werden?

Teilen Sie Ihre Erfahrung und Verbesserungsvorschläge in den dafür vorgesehenen Kommentarbereichen hinsichtlich folgender Themen:

Austauschformate: Bspw. Zugang zu relevanten Informationen, DIskussionsanteil: https://gitlab.opencode.de/bmi/ozg-rahmenarchitektur/zielbild-ozg-rahmenarchitektur/-/issues/152note_105390

Bewerbung: Bspw. Umfang Motivationsschreiben; Wie sind Sie auf den Prozess aufmerksam geworden? https://gitlab.opencode.de/bmi/ozg-rahmenarchitektur/zielbild-ozg-rahmenarchitektur/-/issues/152note_105391

Plattform: Bspw. technische Umsetzung, Funktionalität https://gitlab.opencode.de/bmi/ozg-rahmenarchitektur/zielbild-ozg-rahmenarchitektur/-/issues/152note_105392

Teilnahme & Mitgestaltung am Zielbild: Bspw. Verständnis Zusammenarbeit Zielbilderarbeitungs- und Konsultationsprozess, Wirksamkeit des Konsultationsprozesses https://gitlab.opencode.de/bmi/ozg-rahmenarchitektur/zielbild-ozg-rahmenarchitektur/-/issues/152note_105393

Weitere wichtige Themen https://gitlab.opencode.de/bmi/ozg-rahmenarchitektur/zielbild-ozg-rahmenarchitektur/-/issues/152note_105394

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

OZG.R - editiert am 25.01.2024

Austauschformate

Teilen Sie Ihre Erfahrung und Verbesserungsvorschläge zu dem Thema Austauschformate (Bspw. Zugang zu relevanten Informationen, DIskussionsanteil) unter diesen Kommentar.

F.K - editiert am 25.01.2024

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen: -Wir halten Chatfokusgruppen für eine intensive und interaktive Diskussion für denkbar, allerdings als Chat damit später der Text nachlesbar und kommentierbar ist. -Auch denkbar wären Fokus-Breakout-Rooms. -Die Aufteilung der Frage in Themenbereiche wie hier macht die gemeinsame, aufbauende Kommentierung denke ich einfacher und empfinden wir als gut.

I.S - original vom 26.01.2024

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister e.V.: Wünschenswert wären Webseminare, um über Gesamtfortschritte zu unterrichten, Newsletter mit Fortschrittsmeldungen (Release-updates zu den Funktionsbausteinen) sowie Fokusgruppen zur Konsultation zu einzelnen Funktionsbausteinen.

SEITENBAU - original vom 26.01.2024

Leitfragen und gemeinsame Plattform: Angenehm ist es, alle Informationen und die Beiträge an einem Ort zu finden. Das Ziel möglichst vielen und vielfältigen Stakeholdern die Konsolidierung zu ermöglichen, konnte so m.E. erreicht werden. Die Transparenz hat geholfen, die Perspektiven der unterschiedlichen Beteiligten nachzuvollziehen.

Diskussion: Mehrheitlich wurden die Leitfragen beantwortet, die Antworten dann aber nicht mehr kommentiert oder konsolidiert. Teilweise waren die Leitfragen zu offen und abstrakt formuliert, was eine inhaltliche Breite und Unschärfe der Antworten verursacht haben dürfte. An einigen Stellen (z.B. Leitfrage 8 - Funktionsbausteine) hätten eine Definition oder Begriffsabgrenzung enorm geholfen.

E.S - original vom 26.01.2024

Für den Bitkom e.V

Der Diskussionsanteil war wie weiter oben schon angedeutet sehr gering. Die Austauschformate boten keinen Platz dafür und die Anreize auf OpenCoDe gemeinsam zu diskutieren waren zu gering.

Die Austauschformate hätten ebenfalls dazu genutzt werden können, um mit weiteren Personen des Arbeitspakets in den Austausch zu kommen. Sie hätten ihre Arbeit vorstellen können und selbst Fragen an die Konsultationsteilnehmenden stellen können. Gleichzeitig hätten weitere konkrete Arbeitsstände präsentiert werden können.

D.S - original vom 27.01.2024

DATABUND e.V. Bundesverband der mittelständischen IT-Dienstleister und Softwarehersteller für den öffentlichen Sektor e. V.: Wir würden gerade bei längeren Konsultationsprozessen auch ein persönliches Treffen befürworten. Gerade für Erkenntnisse wie zur Frage 12 wäre dies aus unserer Sicht hilfreich. Ansonsten ist das hybride Format mit Online-Workshops und asychroner Kommentierung gut.

S.L.B - original vom 27.01.2024

Für die Bundessteuerberaterkammer gestaltete sich der Zugang zu den Informationen und Teilnahme an den Diskussionsrunden problemlos. Da es sich um eine öffentliche Konsultation handelt, wäre anzuregen, dass die Beiträge (Issues) ohne vorherige Berechtigung im Open CoDE Bereich zu kommentieren sind. Insbesondere für Organisationen mit mehreren beteiligten Mitarbeitern könnte so der Organisationsaufwand reduziert werden.

G.B - original vom 28.01.2024

Wie von DIHK im Rahmen von Frage 5 angemerkt [1] wäre es mit einer Betrachtung auf die Effizienz des Austausches hilfreich gewesen wenn die relevanten Materialien wie im Rahmen der Hoschullehre üblich als Syllabus zur Verfügung gestellt worden wären. So hätte die Liste durch die Teilnehmer*innen des Konsultationsprozesses ergänzt werden können und eine einheitliche Referenzgrundlage geschaffen werden können.

[1] https://gitlab.opencode.de/bmi/ozg-rahmenarchitektur/zielbild-ozg-rahmenarchitektur/-/issues/141note_93470

D.K - original vom 29.01.2024

Wir sehen eine große Bedeutung darin, den Zugang zu relevanten Informationen transparent und einfach zu gestalten. Vielfach könnten Informationspakete oder Hintergrundmaterialien in einem vorstrukturierten Format als Grundlage für den Austausch dienen. Darüber hinaus würde ein Mix aus synchronen (z.B. Webinare, Roundtable-Diskussionen) und asynchronen Diskussionsanteilen (Online-Foren, Kommentarfunktionen) verschiedenen Akteuren die Beteiligung erleichtern und den Austausch vertiefen. Für künftige Prozesse wäre, auch in Anbetracht der knappen Zeit, zumindest ein einmaliges physisches Treffen aller involvierten Akteure sicherlich von großem Gewinn für alle Seiten.

S.M - original vom 30.01.2024

Bundesagentur für Arbeit: Die Austauschformate als Verbreitungskanal von Informationen über den Prozessstand / über die relevanten Informationen werden als positiv eingeschätzt. Allerdings wäre es gut, wenn hier der Teilnehmerkreis auch auf die in der jeweiligen Behörde mitarbeitenden Personen er-weitert werden könnte. Zudem wäre es hilfreich, wenn die gezeigten Präsentationen vorab zur Verfügung gestellt werden könnten, solange noch kein Videokonferenzsystem vorhanden ist, das von allen friktionsfrei genutzt werden kann.

OZG.R - editiert am 26.01.2024

Bewerbung

Teilen Sie Ihre Erfahrung und Verbesserungsvorschläge zu dem Thema Bewerbung (Bspw. Umfang Motivationsschreiben; Wie sind Sie auf den Prozess aufmerksam geworden?) unter diesen Kommentar.

SEITENBAU - original vom 26.01.2024

Über unterschiedliche Kanäle u.a. Newsletter Digitale Verwaltung

E.S - original vom 26.01.2024

Für den Bitkom e.V.

Im Zuge der Bewerbung war nicht klar, nach welchen Kriterien Bewerber ausgewählt werden. Das hätte vorher aus Transparenzgründen veröffentlicht werden sollen. Aus diesem Grund war auch nicht klar, ob der Kreis der Teilnehmenden eher klein gehalten werden soll, ob Verbände oder Unternehmen die präferierte Zielgruppe sind und welche (Expertise)Hintergründe wünschenswert und notwendig sind. Das sind Faktoren, die die Entscheidung für oder gegen eine Bewerbung beeinflussen.

Im Allgemeinen stellt sich so auch die Frage, ob eine Bewerbungsphase überhaupt notwendig ist oder ob nicht eine Interessensbekundung/Einschreiben auf der Plattform ausreichend gewesen wäre, um auch noch im laufendem Prozess Teilnehmende zuzulassen.

D.S - editiert am 27.01.2024

DATABUND e.V. Bundesverband der mittelständischen IT-Dienstleister und Softwarehersteller für den öffentlichen Sektor e. V.: Es wäre gut, hier die adressierte Zielgruppe des Prozesses zu benennen. Der Aufwand für das Bewerbungsschreiben war dagegen in Ordnung.

S.L.B - original vom 27.01.2024

Art und erwarteter Umfang des Motivationsschreiben sind aus Sicht der Bundessteuerberaterkammer angemessen.

E.H - original vom 27.01.2024

Antwort von Bundesamt für Migration und Flüchtlinge (BAMF):

Teilnahme/Bewerbungsprozess hätte stärker beworben werden können

G.B - original vom 28.01.2024

Wir sind aufgrund eines bestehenden Austauschs mit dem BMI aus dem Kontext des EUid-Wallet Konsultationsprozesses auf den Konsultationsprozess aufmerksam geworden. Der Umfang des Motivationsschreibens war zumutbar, wünschenswert wäre es gewesen wen dieses Berücksichtigung gefunden hätte oder Nichtberücksichtigung zu Rückfragen geführt hätte um evtl. offene Punkte zu klären. Weiterhin wünschenswert wäre gewesen wenn die Motivationsschreiben öffentlich einsehbar und referenzierbar geblieben wären.

Auch wäre eine aktive Ansprache der bestehenden Civi-Tech Organisationen, bspw. Code for DE oder im Rahmen allfälliger Kommuniaktionsformate in Zusammenarbeit mit bspw. dem Digitale Gesellschaft e.V. im Rahmen des Netzpolitischen Abends eine Möglichkeit gewesen.

D.K - original vom 29.01.2024

Für das Motivationsschreiben halten wir eine klare Struktur und Richtlinien bezüglich des Umfangs für vorteilhaft, um den Bewerbungsprozess effektiv und zweckgerichtet zu gestalten. Uns wurde der Prozess durch professionelle Netzwerk und Branchennachrichten bekannt.

S.M - original vom 30.01.2024

Bundesagentur für Arbeit: Anscheinend hat das eingereichte Motivationsschreiben und die darin enthaltene Aussagekraft in seinem Umfang für die Aufnahme gereicht. Mehr kann die BA dazu nicht bewerten. Die BA hat von diesem Konsultationsverfahren über ihre Netzwerke erfahren. Da nicht sichergestellt ist, dass man selbst und diese Netzwerke immer von allen Aktivitäten des BMI erfahren und diese entsprechend weitertragen, wäre es wünschenswert, wenn seitens des BMI hier ein besserer Prozess gefunden werden würde, als nur eine Veröffentlichung auf einer Internetseite. Vielleicht können auch Newsletter usw. für die Bekanntgabe solcher Aktivitäten herangezogen werden.

OZG.R - editiert am 19.01.2024

Plattform

Teilen Sie Ihre Erfahrung und Verbesserungsvorschläge zu dem Thema Plattform (Bspw. technische Umsetzung, Funktionalität) unter diesen Kommentar.

P.S - editiert am 19.01.2024

Da in der Regel mehrere Personen pro Organisation am Konsultationsprozess beteiligt sind, sollte die Möglichkeit existieren, dass pro Organisation mehrere Teilnehmende Zugriff auf die Plattform (die Issues) erhalten.

I.S - original vom 26.01.2024

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister e.V.: Die Plattform OpenCode eignet sich gut. Die Einrichtung von Unterarbeitsgrupen zu einzelnen Themenbereichen wäre hilfreich. Auch wäre es schön, wenn es die Möglichkeit gäbe, dass mehrere Personen pro Organisation Zugriff auf die Plattform erhalten.

SEITENBAU - original vom 26.01.2024

Für das angestrebte Ziel, möglichst viele Rückmeldungen unterschiedlicher Stakeholder einzuholen, war die OpenCode-Plattform mit den Kommentarfunktionen und der Möglichkeit, die Rückmeldungen allen transparent zu machen aus unserer Sicht eine gute Wahl.

Ob die Lösung für mögliche weitere Konsolidierungs-Etappen sich ebenso gut anbietet, hängt von der gewählten Konsolidierungsform ab.

E.S - editiert am 26.01.2024

Für den Bitkom e.V.

Die OpenCoDe-Plattform ist eine gute Möglichkeit, um solche Konsultation durchzuführen und sollte vermehrt genutzt werden. Allerdings sind die Issues nur für mittelbar Beteiligte einsehbar, was der gewünschten Transparenz nicht förderlich ist. Bei der eIDAS-Konsultation ist dies anders. Hier sind sämtliche Informationen für jedermann einsehbar.

S.L.B - original vom 27.01.2024

Die Verwendung von Open CoDE (bzw. GitLab) als Plattform zur allgemeinen Zusammenarbeit empfand die Bundessteuerberaterkammer als äußerst produktiv und sinnvoll. Durch die Möglichkeit der Kommentierung und der einfachen Nachvollziehbarkeit von Informationen (z.B. durch Bereitstellung der Dokumente über ein Repository) wird wesentlich zur Transparenz beigetragen, die in einem solchen Konsultationsprozess besonders wichtig ist.

E.H - original vom 27.01.2024

Antwort von Bundesamt für Migration und Flüchtlinge (BAMF):

Die OpenCoDE GIT-Plattform ist für den Informationsaustausch in agilen Umfeldern gut geeignet und wird auch von uns in vielen Projekten eingesetzt. Um jedoch die Vorteile der Plattform zu nutzen, müssen die bereitgestellten Funktionen sachgerecht eingesetzt werden. Es ist der Eindruck entstanden, dass die falschen Features der Plattform gewählt wurden, um die Rückmeldungen zu organisieren, was den Prozess etwas umständlich und nicht nachvollziehbar gemacht hat. Ein Wechsel auf eine andere Plattform, wie SharePoint oder Confluence, würde das Problem nicht wirklich lösen. Vielmehr ist es erforderlich, sich mit Experten zusammenzusetzen und zu prüfen, welche Funktionen der Plattform für welchen Zweck besser geeignet wären. So gibt es beispielsweise Funktionen für Feature-Branches, für das Review mit Kommentarfunktion, das Zusammenführen von Inhalten per Merge und die Veröffentlichung von PDF- oder Webseiten-Dateien, womit alle Informationen zentral gehalten werden. Diese Funktionen wurden aus unserer Betrachtung nicht ausreichend verwendet. Hätten wir (mehrere Mitarbeitende des BAMF) kollaborativ in einem eigenen Feature-Branch die Fragen selbst bearbeiten können und diese dann als Pull-Request zurückspielen können, wäre kein Medienbruch und Zusatzaufwand entstanden.

Die Veröffentlichung der Leitfragen und Ergebnisse auf den Internet-Webseiten ist nicht synchron mit denen im GIT-Repository und erfolgt zudem nur verstreut. Dies wirft die Frage auf, welche Plattform die führende ist. Würden alle Informationen im GIT-Repository gehalten und daraus eine automatisierte Veröffentlichung implementiert, könnte die Konsistenz und Aktualität der Informationen mithilfe der Versionierung besser gewährleistet werden.

G.B - original vom 28.01.2024

Als gitlab Instanz bietet OpenCoDE umfassende Möglichkeiten zur Transparenz wie sie bspw. nach den Leitlinien der Apache Foundation [1] angeraten wird. Ein Contributer Licence Agreement welches eine Veröffentlichung der Eingaben unter freien Lizenzen bspw. CC-BY-SA 4.0 nach dem Vorbild der Wikipedia ermöglicht hätte fehlt leider. Entsprechend bleibt dieser Konsultationsprozess leider hinter den durch den EUdi-Wallet gesetzten Konsultationsprozess zurück.

[1] https://apache.org/foundation/governance/

D.K - original vom 29.01.2024

Die technische Umsetzung und Funktionalität der Konsultationsplattform sollte eine intuitive Nutzbarkeit gewährleisten. Eine benutzerfreundliche Oberfläche, klare Anweisungen und die Bereitstellung von nützlichen Tools für das Einreichen von Kommentaren und das Teilen von Dokumenten sind essenziell, um die Teilnahme zu erleichtern und die Barrierefreiheit sicherzustellen. Für uns hat sich die Plattform Open Code dabei als gut nutzbar herausgestellt und wir unterstützen die Nutzung der Plattform Open Code.

S.M - original vom 30.01.2024

Bundesagentur für Arbeit: Die OpenCode Plattform für die Beantwortung der Leitfragen wird als hilfreich eingestuft. Allerdings ist die Benachrichtigungsfunktion, sobald neue Kommentare zu einem Issue abgegeben werden nur wenig zielführend. Einerseits gibt es diese Benachrichtigungsfunktion erst, sobald man selbst einen Kommentar abgegeben hat und andererseits ist aufgrund der Menge eine Bearbeitung bzw. ein Ansehen der Kommentare nicht möglich.

OZG.R - editiert am 23.01.2024

Teilnahme & Mitgestaltung am Zielbild

Teilen Sie Ihre Erfahrung und Verbesserungsvorschläge zu dem Thema Teilnahme & Mitgestaltung am Zielbild (Bspw. Verständnis Zusammenarbeit Zielbilderarbeitungs- und Konsultationsprozess, Wirksamkeit) des Konsultationsprozesses unter diesen Kommentar.

P.S - editiert am 23.01.2024

Wir begrüßen die frühzeitige Einbindung unterschiedlicher Bedarfsträger in ein so wichtiges Thema wie die OZG-Rahmenarchitektur. Der gewählte Konsultationsprozess eignet sich unseres Erachtens eher zum Einholen von Feedback zu konkreten Konzepten – wie wir sie uns für den Konsultationsprozess „Phase 2“ wünschen. Die veröffentlichten Leitfragen der Phase 1 waren auf einem hohen Abstraktionsniveau mit viel Raum zur Interpretation. Unseres Erachtens wäre es zielführend gewesen, sich eher an Praktiken des Anforderungsmanagements zu orientieren und die Anforderungen an die OZG-Rahmenarchitektur anhand konkreter Use Cases / Epics / Stories zu diskutieren, die auch durch die Teilnehmenden zugeliefert werden könnten. Insgesamt empfanden wir den Prozess und insbesondere die gemeinsame Kommentierung mit allen Beteiligten als sehr angenehm und würden uns freuen, in Phase 2 Feedback zu Leitfragen zu liefern, die sich auf erste Entwürfe der OZG-Rahmenarchitektur beziehen.

Ergänzend: Zur Nachvollziehbarkeit wäre es sinnvoll, die Leitfragen zum „Due date“ für weitere Kommentare zu schließen und die vorhandenen Kommentare zusammenzufassen.

F.S - original vom 25.01.2024

Aus kommunaler Perspektive hätte der Konsultationsprozess stärker beworben / bekannt gemacht werden sollen. Die Tatsache, dass sich von den ca. 11.500 Kommunen nur eine Hand voll beworben haben, dürfte damit zusammenhängen.

I.S - original vom 26.01.2024

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister e.V.: Es ist begrüßenswert, ein breites Stakeholderfeld einzubinden, um verschiedene Bedürfnisse und Interessen zu hören, aufzunehmen und gegebenenfalls zu berücksichtigen. Ggf. hätte die Möglichkeit der Teilnahme hierfür noch präsenter beworben werden können.

E.S - original vom 26.01.2024

Für den Bitkom e.V.

Die Ergebnisse des Konsultationsprozesses sollten ausführlich und verständlich beschrieben sowie jedermann zur Verfügung gestellt werden. Es ist aktuell schwer nachvollziehbar, welche Veränderungen sich durch den umfangreichen Konsultationsprozess nunmehr ergeben haben, da auch nur einige der durch das Arbeitspaket bearbeiteten Aspekte im Konsultationsprozess Erwähnung fanden und kommentiert werden sollten. Es stellt sich die Frage, ob die Kosten der mit der Konsultation verbundene Arbeitsaufwand die Ergebnisse rechtfertigt. Dies vor allem in dem Hinblick darauf, dass die Konsultationsteilnehmenden Stand jetzt die dann aktuelle Beschlussvorlage für den IT-Planungsrat nicht noch einmal kommentieren können.

Die Antworten auf die Leitfragen werden in zu kurzer Zeit von den Teilnehmenden erwartet. Dies sorgt dafür, dass die Antworten unter Zeitdruck entstehen und gegebenenfalls neue „blinde Flecken“ entstehen. Es sollte dabei berücksichtigt werden, dass bei einer Mitwirkung über einen Verband auch eine verbandsinterne Abstimmung noch stattfinden muss. Auch die Veröffentlich von Fragen kurz vor der Weihnachtspause ist einer qualitativ guten Partizipation nicht förderlich, ebenso wie eine Frist zur Kommentierung auf einen Sonntag zu legen und danach keine Kommentare mehr zuzulassen.

D.S - original vom 27.01.2024

DATABUND e.V. Bundesverband der mittelständischen IT-Dienstleister und Softwarehersteller für den öffentlichen Sektor e. V.: Es wäre schön, im Nachgang auch zu erfahren, welche der Ergebnisse aus dem Konsultationsprozess für das Architekturboard hilfreich waren und welche tatsächlich Berücksichtigung finden. Dies steigert die Motivation und Fokussierung im Konsultationsprozess. Für die Beantwortung der Fragen steht gerade für Verbände oft zu wenig Zeit zur Verfügung, da diese gerne auch Feedback aus ihren Mitgliedern einholen möchten.

S.L.B - original vom 27.01.2024

Die Wirksamkeit der Teilnahme am Konsultationsprozess kann die Bundessteuerberaterkammer erst am finalen Konzept evaluieren. Es ist jedoch erkennbar, dass aus der Fülle der Rückmeldungen nachvollziehbarerweise nur einige Aspekte Berücksichtigung finden konnten, insbesondere auch deshalb, weil die Zielvorstellungen und Meinungen der Teilnehmer so heterogen auseinander gehen.

Mit Rückschau auf die Bearbeitung der Leitfragen wäre es wünschenswert, wenn detaillierter die zugrundeliegende Methodik erklärt und dargestellt werden würde. Für die Bundessteuerberaterkammer war es teilweise herausfordernd, die vorgeschlagenen strategischen Leitplanken und Funktionsbaustein zu interpretieren.

Insgesamt könnte der Austausch ggf. in separaten Runden intensiviert werden. So könnten beispielsweise einige Themen in größeren Gruppen abgestimmt und erst dann in den Prozess eingegeben werden. Dadurch würde sich der Auswertungsaufwand sicherlich deutlich reduzieren.

Wünschenswert aus Sicht der Bundessteuerberaterkammer wären auch Zwischenberichte nach Auswertung der jeweiligen Leitfragenblöcke. Dadurch würde der Konsultationsprozess transparenter, missverständliche Antworten auf Leitfragen, die ggf. Auswirkungen zeigen, könnten frühzeitig korrigiert werden.

E.H - editiert am 29.01.2024

Antwort von Bundesamt für Migration und Flüchtlinge (BAMF): - Verständnis Zusammenarbeit Zielbilderarbeitungs- und Konsultationsprozess: Das Verständnis, worauf die Frage abzielt, und damit, welchen Zweck sie verfolgt, war nicht immer transparent. Die stark abweichenden Antworten deuten auf die Verständnisprobleme/Interpretationsprobleme – über alle Teilnehmenden hinweg – hin. Dies könnte durch eine bessere Aufbereitung der Fragen (weshalb, wofür, für welchen Zweck und welche Zielstellung) und den Verweis auf Beispielantworten in vergleichbaren Prozessen verbessert werden. - Wirksamkeit des Konsultationsprozesses: Wir hatten In einigen Fällen den Eindruck, dass einige der Rückmeldungen von uns nicht wirklich verstanden und somit nicht hinreichend berücksichtigt wurden. U.a. weisen die fehlenden Rückfragen und fehlende Einarbeitung darauf hin. Dies könnte durch eine unmittelbare und interaktivere Abstimmung (z.B. BundesMessanger) zwischen den Teilnehmenden und dem Zielbilderarbeitungsprozess verbessert werden. Das Arbeiten an einer Quelle pro Frage und Übernahme per GIT Pull-Request (Git Standard Workflow) würde die Nachvollziehbarkeit stärken und besser reflektieren, welcher Input in welcher Form angenommen oder verworfen wurde.
- Kommentare hätten durch eine zentrale Stelle (Moderationsfunktion) besser konsolidiert werden können, bevor es eine weiterführende Frage oder die Diskussion einer neuen Leitfrage gab.

Beispiel: Veröffentlichung der ersten Fragen - Feedbackrunde - Konsolidierung – ggf. 2te Runde zu Frage 1- Konsolidierung - Frage 2 - Feedbackrunde - Konsolidierung – ggf. 2te Runde zu Frage 2 - Konsolidierung - ... .

Die empfehlenswerte Konsolidierung könnte auch durch eine Clusterung/ Zusammenfassung inhaltsgleicher Vorschläge erfolgen, über die dann jeweils unter allen Teilnehmenden des Konsultationsprozesses mit einer Umfrage abgestimmt wird (stimme zu, stimme teilweise zu,..., stimme nicht zu). Damit ist dann für das zentrale Gremium sowie für alle Teilnehmenden besser erkennbar, was nur "exotische" Einzelmeinungen sind oder doch auch eine Mehrheit überzeugt.

Zudem vermissen wir strategische Leitlinien für die non-funktionalen Aspekte der Zielbildgestaltung. Ein Beispiel: Im OZG/ABI-Prozess wurde die Struktur der Antragsdaten sicher nach bestem Wissen und Gewissen der Fachbereiche modelliert, jedoch fehlten Richtlinien, wie z. B. eine Orientierungspflicht nach XÖV oder anderer existenter Normen zur Ausgestaltung von Struktur, Attributen und Namensgebung. Das lässt für die Zukunft und weitere Prozesse befürchten, dass z. B. dieselben Namen mit unterschiedlicher Semantik belegt werden, die sich dann nur wieder im Kontext der jeweiligen Prozesse oder Rechtskreise erschließt und somit eine gemeinschaftliche Zielbildgestaltung erschwert.

G.B - original vom 28.01.2024

Während offene Fragestellungen im Bereich öffentlicher Diskussionen zu begrüßen sind lässt leider eine fehlende Transparenz der Ergebnisse keine Möglichkeit zur Mitgestaltung zur bewerten. Bereits in Motivationsschreiben angesprochene Punkte scheinen bisher im Konsultationsprozess keine Berücksichtigung gefunden zu haben, auch eine individuelle Ansprache hierzu fand nicht statt. Entsprechend ist nicht nachvollziehbar, ob diese im Rahmen des Konsultationsprozesses Berücksichtigung fanden und in wie weit diese dem IT-Planungsrat oder den entsprechenden vorgelagerten Gremien zur Kenntnis gelangt sind.

Dieser Punkt wurde bereits in der Kick-Off Veranstaltung angesprochen und scheint bisher nicht adressiert.

D.K - original vom 29.01.2024

Das Verständnis für den Zusammenhang zwischen Zielbilderarbeitung und dem Konsultationsprozess muss klar kommuniziert werden, damit die Wirksamkeit des Konsultationsprozesses deutlich wird. Es sollte für die Teilnehmenden transparent sein, wie ihr Input in die finale Entscheidungsfindung einfließt. Ebenso ist es gut, wenn gewährleistet ist, dass Rückmeldungen nicht nur gesammelt, sondern auch reflektiert und – wo möglich – integriert werden.

Zusammenfassend wünschen wir uns für die Beteiligten in dieser Gruppe einen Konsultationsprozess, der über eine formalistische Einbindung hinausgeht und somit als echtes, kollaboratives und wertschöpfendes Werkzeug wahrgenommen wird, welches die Expertise und die Bedürfnisse aller Stakeholder berücksichtigt.

S.M - original vom 30.01.2024

Bundesagentur für Arbeit: Es wurde erst im Laufe des Konsultationsprozesses klar, was man sich genau unter dem Be-griff der „OZG-Rahmenarchitektur“ vorstellt und welche Vision verfolgt wird. Aus den ersten Leitfragen ließ sich das nur schwer ableiten. Es ist nicht ausreichend transparent aus welchen Gründen regelmäßig Aktualisierungen an den Funktionsbausteinen oder den strategischen Leitplanken vorgenommen wurden. Zudem fehlte jeweils eine genaue Beschreibung zu den Überschriften / Schlagwörtern. Eine Bewertung allein anhand von Schlagwörtern bzw. Überschriften birgt immer die Gefahr einer falschen oder unzureichenden Interpretation. Zudem ist die Verbindlichkeit der erarbeiteten Ergebnisse noch unklar, vor allem wenn die eigene Einschätzung zu den Ausprägungen von der Einschätzung des FIT AB abweicht.

OZG.R - editiert am 25.01.2024

Weitere wichtige Themen

Teilen Sie Ihre Erfahrung und Verbesserungsvorschläge zu weiteren wichtigen organisatorischen Themen unter diesen Kommentar.

F.K - original vom 25.01.2024

Mich würde interessieren: Wie hoch ist der Ressourcen-Aufwand von Ihrer Seite für den Prozess? Wird das als angemessen betrachtet?

I.S - original vom 26.01.2024

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister e.V.: Potenzielle technische und politische Entwicklungen im Laufe des Prozesses sollten im Blick behalten werden und mögliche Einflüsse, die sich auf das Zielbild ergeben sollten eruiert und kommuniziert werden.

E.S - original vom 26.01.2024

Für den Bitkom e.V.

Wir begrüßen die Initative des BMI, verschiedene Stakeholder zu einem Thema zusammenzubringen und um Feedback zu aktuellen Arbeitsständen zu bitten. Wir würden uns freuen, wenn es weitere Konsultationen dieser Art geben würde und die Konsultation zur OZG-Rahmenarchitektur mit entsprechenden Anpassungen im Prozess weitergeführt werden würde und jetzt nicht während des Entwicklungsprozesses endet.

S.L.B - original vom 27.01.2024

Ergänzend zu den bisherigen Antworten auf diese Leitfrage regt die Bundessteuerberaterkammer einen längeren Vorlauf zur Beantwortung der Fragen an. Insbesondere größere Organisationen haben einen erhöhten internen Abstimmungsbedarf, der oft nicht kurzfristig erreicht werden kann.

Weiterhin wäre es zu begrüßen, wenn die gestellten Leitfragen nicht während der Beantwortungsphase geändert werden würden.

Grundsätzlich hätte sich die Bundessteuerberaterkammer gewünscht, dass bereits in der ersten Phase des Konsultationsprozesses Zielbilder und Inhalte weitaus konkreter ausgearbeitet und diskutiert werden. Es bleibt zu hoffen, dass dies durch Fortführung des Konsultationsprozesses ermöglich wird.

G.B - original vom 28.01.2024

Nach unserem Verständnis dienen offene öffentliche Konsultationsprozesse neben einer Qualitätssicherung der geplanten Umsetzung der Vertrauensbildung in der Bevölkerung. Dies wird durch eine öffentlichkeit der Eingaben sowie einer Dokumentation von deren Würdigung oder entsprechender Abwägungen sichergestellt. International kooperierende Open Source Project zeigen, dass gitlab Instanzen wie Open CoDE hierfür die Möglichkeit bieten. Die Tatsache, dass diese Diskussion, genauso wie die bisher bestehenden Zwischenstände der Schlussfolgerungen nicht öffentlich einsehbar und damit u.a. nicht für die Presse einsehbar sind verhindern, dass die Grundlage für einen Vertrauensbildung besteht. Wir stehen gerne für Gespräche zu Möglichkeiten der Umsetzung zur Verfügung.

Weiterhin scheint aus unserer Perspektive unklar in welche Rahmen die im Rahmen des Konsultationsprozesses angebrachten Punkte dauerhaft zu einem Know-How Aufbau im BMI Beitragen. Eine fehlende Transparenz über Anhand der Eingaben erstellten Zusammenfassungen die durch umsetzende Dritte erstellt werden lässt hier Fragen offen. In Kombination mit den Fragestellungen sowie den Veranstaltungen und den fehlenden Rückfragen auf relevante inhaltliche Punkte entsteht der Eindruck, dass es nicht zu einer nachhaltigen Kompetenzstärkung auf Seiten des zuständigen Referates des BMI kommt.

J.P - editiert am 29.01.2024

Antworten Team PwC:

• Viele Leitfragen befassten sich mit organisatorischen und/oder prozessualen Aspekten. Stattdessen wären mehr inhaltliche Leitfragen denkbar gewesen.

• Die Leitfragen waren teilweise sehr ähnlich bzw. wenig trennscharf formuliert. Dies zeigt sich auch darin, dass bei der Beantwortung häufig auf die Antwort zu einer anderen Leitfrage verwiesen wurde.

• Insb. die erste Version der Funktionsbausteine hatte kaum Bezug zum Ablauf von Verwaltungsverfahren und bestehenden IT-Komponenten. Zudem fehlten Beschreibungen der Funktionsbausteine. Hier wären weitergehende inhaltliche Vorbereitungen wünschenswert gewesen, bevor man eine Kommentierung einleitet.

S.M - original vom 30.01.2024

Bundesagentur für Arbeit: Zwar kann nachvollzogen werden, dass man, um möglichst jeden mitzunehmen bzw. jede Meinung / jeden Blickwinkel einzusammeln, viele Personen/Organisationen/Behörden beteiligen will. Allerdings erhöht sich ab einer bestimmten Größe nur noch die Anzahl der Teilnehmer, aber nicht mehr die Erkenntnisse. Daher wird die Anregung gegeben Expertenzirkel zu gründen und diese dann gezielten Fragestellungen zu involvieren.

B.S - original vom 28.01.2024

GKV-Spitzenverband

Die Etablierung eines Konsultationsprozesses ist grundsätzlich zu begrüßen. Aufgrund der Anzahl der Teilnehmenden ist der direkte Austausch allerdings schwierig. Darauf sollte zukünftig ein größerer Fokus liegen.

Inwieweit die Vorschläge in der späteren Ausgestaltung der Zielbilder berücksichtigt werden können, ist heute noch nicht absehbar, daher ist auch die Wirksamkeit noch nicht bewertbar.

05. Strategiepapiere, Gesetze, Beschlüsse

Datum der Veröffentlichung: 09.11.2023
Anzahl eingegangener Antworten: 34
Issue # in GitLab: #141
Leitfrage 05

Welche Strategiepapiere, Gesetze, Beschlüsse (EU- und DE) sind aus Ihrer Sicht richtungsweisend für die Digitalisierung der öffentlichen Verwaltung? Welche haben aus Ihrer Sicht (für Sie und für DE) größte Relevanz?

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

S.W - editiert am 17.11.2023

Einen sehr guten Überblick über die digitale Zukunft Europas zeigt die Übersicht auf der Webseite des Europäischen Rates dar: https://www.consilium.europa.eu/de/policies/a-digital-future-for-europe/

Dort kann man auch den Beschluss zum Politikprogramm „Der Weg in die digitale Dekade“ für den Zeitraum bis 2030 einsehen: https://data.consilium.europa.eu/doc/document/PE-50-2022-INIT/de/pdf.

Unter Nummer 9 steht: "Um dem Zielpfad der Union im Hinblick auf das Tempo des digitalen Wandels folgen zu können, sollten auf Unionsebene Digitalziele festgelegt werden. Diese Digitalziele sollten mit konkreten Bereichen verknüpft werden, in denen erwartet wird, dass Fortschritte gemeinsam in der Union erzielt werden. Die Digitalziele entsprechen den vier Kernpunkten, die in der Mitteilung über den digitalen Kompass als wesentliche Bereiche für den digitalen Wandel der Union benannt wurden: digitale Kompetenzen, digitale Infrastrukturen, Digitalisierung der Unternehmen und Digitalisierung der öffentlichen Dienste."

Das eine Ziel kann man nicht getrennt von den anderen Zielen betrachten. Nur durch eine gemeinsame Anstrengung aller Akteure, die Digitalisierung in den Themenbereichen voranzubringen, gelingt eine erfolgreiche Umsetzung.

Hierbei ist auch für die Fortentwicklung der Digitalisierung in Deutschland extrem wichtig, die Eigenbrötlereien weniger Bundesländer aus der Förderalismuspraxis in diesem Fall zu missachten. Das ständige Beharren auf der Subsidiarität ist diametral zu den eigentlichen Zielen des OZG 2.0. Es soll eine einheitliche Archetiktur geschaffen und darauf zurückgegriffen werden können, ohne auf lähmende und teils widerstrebende förderale Technologien zu achten. Hier sollte auf das Konnexitätsprinzip gesetzt werden: Bund und Länder zahlen für eine gemeinsame OZG-Architektur.

F.S - original vom 09.11.2023

Für die kommunale Ebene haben im Wesentlichen die landesrechtlichen Regelungen rechtliche Relevanz, z.B. für Niedersachsen das NDIG. Die daraus resultierende föderale Zerfaserung, die die sich aus Art. 28 GG ergebende Herausforderung der technisch-organisatorschen Eigenständigkeit von ca. 11.000 Kommunen weiter verkompliziert, muss eingefangen werden. Die neuerdings "straffer" gehandhabte Arbeit des IT-Planungsrates geht in die richtige Richtung, letztlich dürfte echte Wirkmacht aber nur durch bundesgesetzliche Vorgaben entstehen können (die in der notwendigen Detailtiefe allerdings eine Grundgesetzänderung erfordern). Sofern dies nicht gelingt, wird letztlich die EU entscheidender Steuerungs-Faktor werden.

DIHK.I.K - editiert am 17.11.2023

Die DIHK fragt sich, warum das BMI und das FITKO-Architekturboard, als an der Verwaltungsdigitalisierung und ihrer rechtlichen und strategischen Gestaltung ganz zentral beteiligte Kräfte, diese Frage stellen. Sollte es um Feinabwägungen der im BMI und im FITKO-Architekturboard sicherlich vorliegenden Gesamtschau gehen, schlagen wir vor, dass hier eine Liste mit zentralen Texten mit Nummerierung veröffentlicht wird, die von den hier Beteiligten in verschiedenen Dimensionen bewertet werden könnten, bspw. - welche dieser Grundlagen bestimmen gerade das operative Handeln bei Bund/Ländern/Kommunen? - welche dieser Grundlagen sollten eigentlich, d.h. inhaltlich gesehen, handlungsleitend seit, um eine schnelle Digitalisierung zu realisieren? - welche Grundlagen sind vielleicht überholt bzw bedürfen eines Updates? - welche Grundlagen stehen ggf im Widerspruch bzw stellen die Operative vor Zielkonflikte?

OZG.R - original vom 17.11.2023

Wir haben die Leitfragen bewusst entwickelt, um eine breite Vielfalt von Meinungen und Perspektiven der Teilnehmenden dieser Konsultation einzubeziehen. Unser Hauptziel besteht darin, die relevanten Strategiepapiere zu ermitteln, die Ihrer Meinung nach bei der Ableitung eines Zielbildes berücksichtigt werden sollten. Wir möchten sicherstellen, dass die Diskussion so offen wie möglich geführt wird und keine wichtigen Aspekte übersehen werden. Dies ist entscheidend, um mögliche "blinde Flecken" in unserer Betrachtung zu vermeiden und sicherzustellen, dass alle relevanten Informationen in den Prozess einfließen können.

A.S - original vom 14.11.2023

Welche Beschlüsse/Gesetze sind Richtungsweisend für die Digitalisierung der öV?

Klassiker: - Verwaltungsverfahrensgesetz - Fachgesetze mit Digitalisierungshemnissen - E-Governmentgesetze der Länder - BDSG, DSGVO und Länderdatenschutzgesetze - OZG

Die OZG-Umsetzung hat gerade in den Behörden, diese Themen zunächst auf die Tagesordnung geholt, weshalb es zunächst erst einmal eine intensivere Befassung mit den Themen gab und somit auch die Kompetenz für richtungsweisende Beschlüsse sowohl in den Behörden als auch in den die Behörden beratenden Unternehmen zugenommen hat. Demnach ist zukünftig mit zielführenden Beschlüssen zu rechnen, deren Wesentlichkeit auch ein Zielbild der OZG-Rahmenarchitektur gerecht werden sollte. Bspw. mit einem Ziel, diese Informationen institutionell zusammenefasst management- als auch analysefreundlich darzustellen.

Darüber hinaus sind wichtige Gremien zu beachten, wie die - Datenschützerkonferenzen - IT-Sicherheitskonferenzen - usw.

Besonderer Hinweis:

Die Verwaltungsverfahrensgesetze, die originär vom Rechtscharakter keine "Digitalgesetze" sind, betreffen dennoch auch grundsätzliche Entscheidungen der Digitalisierung in Bezug auf die OZG-Umsetzung. Dies sollte besondere Bachtung finden, da das ordentlichen Verwaltungsverfahren die rechtliche Basis und der rechtliche Rahmen für die OZG-Digitalisierung darstellt.

T.B - editiert am 28.11.2023

Onlinezugangsgesetz (OZG)

EU-Datenschutz-Grundverordnung (DSGVO)

Digitale Agenda der EU

eGovernment-Gesetz (EGovG) – Deutschland

EU-Strategie für einen digitalen Binnenmarkt

IT-Konsolidierung des Bundes (Deutschland)

Verwaltungsverfahrensgesetz

SDG-VO

Registermodernisierungsgesetz

Wachstumschancengesetz

D.H - editiert am 28.11.2023

Hier sollte man vielleicht noch eIDAS/eIDAS2, den Cyber Security Act und weitere Regularien im Umfeld von Daten (Data Governance Act, Data Act) sowie angrenzenden Bereichen (z.B. European Health Data Space) ergänzen.

M.N.AKDB - original vom 17.11.2023

Neben dem OZG, dem EGovG sind insbesondere die Digitalisierungsgesetze der Länder maßgebend (z.B. BayDiG, Bayer. EGovG u.a.). Das dynamische Momentum und die besondere Berücksichtigung der föderalen wie kommunalen Herausforderungen greift nach unserer Auffassung der Digitalplan Bayern in hervorhebenswerter Weise auf. Auf europäischer Ebene verdienen besondere Beachtung die Novellierung der eIDAS-Verordnung mit ihren weitreichenden Regelungen zur elektronischen Identität. Der überspannende Rahmen der Europäischen Digitalen Dekade (2030 Digital Compass - The European Way for the Digital Decade) sollte ebenso Berücksichtigung finden. Partikular sollte noch die Bedeutung von grenzüberschreitenden Interoperabilitäts-Rahmenwerken und Maßnahmen hervorgehoben werden (z.B. SDG, eID, EIF).

Abseits des nationalen Kontextes sind aus komparativer Perspektive die vergleichbaren Normen im europäischen Binnenraum relevant. Im Sinne eines Best-Practice-Ansatz sollten Gleichläufigkeiten und Unterschiede zu vergleichbaren Regelungsinhalten systematische aufgearbeitet, normiert und als Benchmark und Ideenpool herangezogen werden.

Im zivilgesellschaftlichen und gewerblichen Rahmen sollte Rekurs auf auf den eGovernment-Monitor der Initiative D21, auf den Deutschland-Index der Digitalisierung 2023 sowie die weiteren Veröffentlichungen des ÖFIT. Besondere Beachtung verdient auch die Studie "Wie sich die Informationssicherheit von deutschen Städten verbessern lässt" des Deutschen Städtetags und die Publikationen der Innovationsstiftung Bayerische Kommune. Weiterhin regen wir die Berücksichtigung der NEGZ-Kurzstudien an. Ebenfalls gute Zahlengrundlagen liefert das Statistische Bundesamt mit seinem Angebot amtlich-einfach.de. Auch das DIN Whitepaper „Normung und Standardisierung bei der Digitalisierung der öffentlichen Verwaltung“ und die dort formulierten Gedanken müssten gewürdigt werden.

Ansätze, welche auf die digitale Verlängerung von Akten (z.B. Elektronischer Akt - ELAK oder Elektronischer Akt im Bund - EIB in Österreich) abzielen, sind davon abzugrenzen, da sie nachweislich keine verbesserte Effizienz (Ziel der OZG-Rahmenarchitektur) generieren. Zudem greifen Aktenlage im europäischen Kontext (vgl. Frage 07) zu kurz, da sie nur schwer interoperabel darstellbar sind.

Insgesamt ist bei der Dimensionierung der Maßnahmen darauf zu achten, dass die Grundsätze der Verhältnismäßigkeit und Subsidiarität im föderalen Staatsaufbau beachtet und die durch das Online-Zugangsgesetz etablierte Bundeskompetenz nicht überdehnt wird. Verwaltungsdigitalisierung findet vor Ort, in den Kommunen, statt und dort entscheidet sich deren Erfolg und gesellschaftlicher Nutzen.

D.T.OZG.S - editiert am 28.11.2023

Im Kontext der Digitalisierung von Verwaltungsleistungen sind eine Vielzahl von rechtlichen Normen, Gremienbeschlüssen und Strategiepapieren wesentlich.

Aufgrund der Vielzahl der relevanten Regelungen sowie der bestehenden Abhängigkeiten ist es aus Sicht der Deutschen Telekom zielführend, wenn ein Verzeichnis der relevanten Regelungen Bestandteil der OZG-Rahmenarchitektur (im Sinne einer „Standard Library“ nach TOGAF) wird.

Die folgende Auflistung stellt die aus Sicht der Deutschen Telekom relevantesten generellen Maßgaben bereit. Abhängig vom jeweiligen Projektkontext entfalten weitere fachspezifische Regelungen Gültigkeit.

Art

Relevante Regelung

EU-VO / Gesetz / Verordnung SDG-VO, Single Digital Gateway VO (EU-VO 2018/1724)

EU-VO / Gesetz / Verordnung DSGVO, Datenschutzgrundverordnung (EU-VO 2016/679)

EU-VO / Gesetz / Verordnung eIDAS, Verordnung über elektronische Identifizierung und Vertrauensdienste (EU-VO 910/2014)

EU-VO / Gesetz / Verordnung BDSG, Bundesdatenschutzgesetz

EU-VO / Gesetz / Verordnung Datenschutzgesetze der Länder

EU-VO / Gesetz / Verordnung BSI-Gesetz sowie BSI Kritisverordnung

EU-VO / Gesetz / Verordnung OZG, Onlinezugangsgesetz

EU-VO / Gesetz / Verordnung ITSiV-PV, IT Sicherheitsverordnung Portalverbund

EU-VO / Gesetz / Verordnung EGovG Bund, E-Government Gesetz Bund

EU-VO / Gesetz / Verordnung E-Government Gesetze der Länder

EU-VO / Gesetz / Verordnung RegMoG, Registermodernisierungsgesetz

EU-VO / Gesetz / Verordnung Behindertengleichstellungsgesetze

EU-VO / Gesetz / Verordnung IT-NetzG, Gesetz über die Verbindung informationstechnischen Netze des Bundes und der Länder

EU-VO / Gesetz / Verordnung GDNG, Gesetz zur verbesserten Nutzung von Gesundheitsdaten

Beschlüsse und Standards

Beschlüsse von IT-Planungsrat und OZG-AL-Runde
(z. B.: IT-Architekturrichtlinie 2021/37, Support- und Betriebsorganisation von EfA-ODs 2023/07, Verfügbarkeiten von IT-Systemen im Portalverbund 2018/40, Responsive Design 2018/40, FitStore und GovDigital Marktplatz 2022/27, Leitlinie Informationssicherheit 2020/05 u.a., Anschlussbedingungen NdB-VN 2020/15, DVC-Strategie 2021/46, DVC-Koordinierungsstelle 2023/18 u.w., DVC-Zielarchitektur 2022/47, DVC-Architekturboard, MeinUK 2020/01 u.a.).

Beschlüsse und Standards Anwendungen des IT-Planungsrates (115, BFD, DVDV, FINK, FIT Connect, FIT-Store, Föderales Entwicklerportal, FIM, GovData, Governikus, GMM, OSiP, PVOG)

Beschlüsse und Standards Standards des IT Planungsrats (OSCI, XTA, String-Latin/DIN91379 XDomea, XRechnung, XVergabe, XBau, XPlanung, XDatenfelder, XZuFi, XProzess, DCAT-AP.de)

Beschlüsse und Standards BSI TR-03160 Servicekonten

Beschlüsse und Standards BSI TR-03147 Vertrauensniveaubewertung von Verfahren zu Identitätsprüfung natürlicher Personen

Beschlüsse und Standards BSI TR-03107 elektronische Identitäten und Vertrauensdienste

Beschlüsse und Standards BSI TR-03172 Portalverbund

Beschlüsse und Standards BSI Grundschutz

Beschlüsse und Standards ISO 20000 IT Servicemanagement

Beschlüsse und Standards ISO 22301 „Betriebliches Kontinuitätsmanagement“

Beschlüsse und Standards ISO 27001 "Informationssicherheit, Cybersicherheit und Datenschutz - Informationssicherheitsmanagementsysteme - Anforderungen"

Beschlüsse und Standards EVB-IT, einheitliche Vertragsbedingungen für IT-Leistungen

Beschlüsse und Standards NOOTS, Technical Design Document

Strategiepapier Digitalisierungsstrategien von Bund, Ländern und Kommunen

Strategiepapier Wahl- und Parteiprogramme der Parteien

Strategiepapier Gartner, Magic Quadrant und Technology Trends

Strategiepapier Deloitte, Tech Trends

Strategiepapier Aktuelle Studien und Veröffentlichungen von Wissenschaft, Beratungs- und Consultingunternehmen (z. B. NEGZ „Government as a Platform in Deutschland“)

Frage05_OZGRahmenArchitektur_Konsultationsprozess

D.K - original vom 19.11.2023

Als entscheidend für die Digitalisierung der öffentlichen Verwaltung erachten wir in erster Linie das Onlinezugangsgesetz (OZG). Es setzt klare Impulse für die Schaffung digitaler Wirtschaftsleistungen und treibt die Modernisierung der Verwaltung voran. Auf europäischer Ebene ist das European Interoperability Framework (EIF) von großer Bedeutung, da es interoperable Lösungen fördert. In diesem Kontext spielt die Single Digital Gateway Verordnung (SDG-VO) ebenfalls eine wichtige Rolle. Sie fördert die Interoperabilität von Systemen und setzt klare Standards für die Bereitstellung von Informationen und Verwaltungsverfahren online. Dies ist aus unserer Sicht wichtig, da die Verordnung eine Grundlage für die Entwicklung von innovativen digitalen Lösungen und Dienstleistungen im öffentlichen Sektor schafft. Die Harmonisierung auf europäischer Ebene würde nicht nur die länderübergreifende Zusammenarbeit erleichtern, sondern schafft auch Synergien für die Entwicklung von digitalen Lösungen. Die konsequente Umsetzung der nationalen Gesetze und Strategien gewährleistet, dass die Digitalisierung der öffentlichen Verwaltung in Deutschland auf einem soliden rechtlichen und organisatorischen Fundament basiert.

Insgesamt sind die SDG-VO sowie nationale Gesetze und Strategiepapiere entscheidende Wegweiser für die Digitalisierung der öffentlichen Verwaltung. Die publicplan empfiehlt daher, diese rechtlichen und strategischen Rahmenbedingungen aktiv in die eigene Planung und Umsetzung von digitalen Projekten einzubeziehen, um innovative und effiziente Lösungen für die Verwaltung und die Bürger bereitzustellen.

D.S - editiert am 20.11.2023

Für die Fachverfahrenshersteller und Antragsmanagement-Systemhersteller haben die XÖV-Standards klar die höchste Relevanz. An diesen arbeiten sie zumeist selbst mit und diese gewährleisten aktuell das Funktionieren von kommunalen Leistungen und den Datenaustausch zwischen den föderalen Ebenen. Weiterhin haben hohe Relevanz die Datenschutz-Gesetze und -Verordnungen von EU, Bund und Ländern, auch wenn diese zumeist behindernd bei der Modernisierung von Prozessen wirken. Eine mittlere Relevanz hat das OZG und dessen Nachfolgegesetz. Die Registermodernisierung im Zusammenspiel mit SDG gewinnt aktuell eine immer höhere Relevanz, da die Umsetzungsfrist des SDG bald ausläuft und die Planungen der Registermodernisierung laufen. Richtungsweisend sind Ansätze zur offenen Konsultation wie dieser, sofern die Antworten und Ergebnisse tatsächlich Berücksichtigung finden. Es geht nicht um den großen Wurf der alle Probleme lösenden Strategie, sondern um die Formulierung eines klaren Ziels und vieler kleiner gemeinsamer Schritte in die richtige Richtung.

J.E - original vom 20.11.2023

Neben dem OZG sind u.E. auch folgende weitere Gesetze, Richtlinien, Verordnungen (etc.) von Relevanz: • eIDAS Verordnung • EU-Zugangstor (Single Digital Gateway Verordnung) • Informationsfreiheitsgesetz (Bund und Länder) • E-Government-Gesetze (Bund, Länder) • Datenschutzgesetze (EU-DSGVO) • Verschiedene technische-Richtlinien des BSI (27001, C5, …) sind relevant für die Bereitstellung der IT-Infrastruktur für die Verwaltungsdigitalisierung.. • IT-Netzgesetz • Registermodernisierungsgesetz (RegMog) • Deutsche Verwaltungscloud Strategie • …

S.M - original vom 20.11.2023

Bundesagentur für Arbeit:

folgende nicht abschließende Aufzählung:

Gesetze: OZG, EGoVG, IDNrG (RegMod), Telemediengesetz Verordnungen: DSGVO, ITSiV-PV, BITV, EIDAS (EU), GDPR (EU), SDG-VO Strategiepapiere vom IT-Planungsrat z.B. bzgl. Open Source Strategie

S.H - original vom 20.11.2023

EU DSG-VO, SDG-VO, E-GovG, HE-GovG, OZG, RegMoG, UBRegG, eIDAS, KritisDachG/CER-Richtlinie, BSIG bzw. NIS2UmsuCG/NIS2-Richtlinie, BGG/BITV 2.0

(weitere, fachliche, gesetzl. Grundlagen natürlich alle eingeschlossen)

E.S - editiert am 20.11.2023

Wir als Bitkom e.V. ergänzen abgesehen vom OZG um die folgenden Punkte:

NEGS Nationale E-Government Strategie

E-Government Gesetz des Bundes und der Länder

Verwaltungsverfahrensgesetze (z.B. VwVfG, AO, VwZG)

EfA Mindestanforderungen

eIDAS

Registermodernisierungsgesetz & Unternehmensbasisdatenregistergesetz

EG-Dienstleistungsrichtlinie

Datenschutzgesetze (z.B. DSGVO, sozialrechtlicher Datenschutz nach SGB, behördlicher Datenschutz nach BDSG)

Gerichtliche Prozessordnungen (z.B. ZPO, VwGO)

Welche haben aus Ihrer Sicht (für Sie und für DE) größte Relevanz?

Alle Richtlinien haben je nach Kontext ihre Relevanz. Bspw. E-Government Gesetz des Bundes und der Länder:

Provozieren von Neudenken alter Prozesse bei der Einführung neuer Fachverfahren

Barrierefreiheit

Fokus auf die Nutzer

B.S - original vom 20.11.2023

Für die GKV:

Für die gesetzliche Krankenversicherung, die bereits seit mehreren Jahren die Digitalisierung Ihrer Verwaltungsleistungen vorantreibt sind insbesondere folgende Gesetze für die weitere Umsetzung relevant:

VERORDNUNG (EU) 2018/1724 über die Einrichtung eines einheitlichen digitalen Zugangstors zu Informationen, Verfahren, Hilfs- und Problemlösungsdiensten und zur Änderung der Verordnung (EU) Nr. 1024/2012

eIDAS 2.0

Verordnungsvorschlag zum Interoperable Europe Act

Verordnungsvorschlag zum Europäischen Gesundheitsdatenraum

Gesetz für schnellere Termine und bessere Versorgung (TSVG, 2019),

Gesetz für mehr Sicherheit in der Arzneimittelversorgung (GSAV, 2019),

Gesetz für eine bessere Versorgung durch Digitalisierung und Innovation (DVG, 2019),

Gesetz zum Schutz elektronischer Patientendaten in der Telematikinfrastruktur (PDSD, 2020),

Digitale–Versorgung–und–Pflege–Modernisierungs–Gesetz (DVPMG, 2021),

Gesetz zur Pflegepersonalbemessung im Krankenhaus sowie zur Anpassung weiterer Regelungen im Krankenhauswesen und in der Digitalisierung (KHPflEG, 2022),

Gesetz zur Beschleunigung der Digitalisierung des Gesundheitswesens (DigiG, 2023 in Arbeit),

Gesetz zur verbesserten Nutzung von Gesundheitsdaten (GDNG, 2023 in Arbeit)

R.W - original vom 20.11.2023

-          Registermodernisierungsgesetz

-          Single-Digital-Gateway der EU

-          eIDAS 2.0

-          GDPR/DSGVO

S.G - original vom 20.11.2023

Aus Sicht der VISION Consulting GmbH sollte hier grundsätzlich zuerst eine zentrale Übersicht mit sämtlichen für die Digitalisierung der öffentlichen Verwaltung geltenden Strategiepapiere, Gesetze, Beschlüsse, etc. erstellt werden, um hier für alle daran Beteiligten einheitliche und klare Informationsbasis zu erhalten. Diese Übersicht sollte mindestens folgende Informationen beinhalten:

Strategiepapiere, Gesetze, Beschlüsse (EU, Bund, Länder, Gemeinden) mit Datum und Wirkungskreis der Bestimmung sowie Verlinkung auf die aktuell gültigen Texte.

Vergleich der einzelnen Bestimmungen auf Widerspruchsfreiheit Im Anschluss sollten diese Bestimmungen in einem konsequent aufgabenkritischen Ansatz validiert und aktualisiert, sowie in möglichst wenige, zentrale Bestimmungen überführt werden.

Größte Relevanz für die Digitalisierung der öffentlichen Verwaltung haben aktuell:

Onlinezugangsgesetz (OZG)

E-Government-Gesetz (EGovG) – Deutschland

IT-Konsolidierung Bund

Registermodernisierungsgesetz (RegMoG)

Datenschutz-Grundverordnung (DSGVO)

Single Digital Gateway Verordnung (SDG-VO)

Digitale Agenda der EU

EU-Strategie für einen digitalen Binnenmarkt

S.L.B - original vom 20.11.2023

Die Bundessteuerberaterkammer begrüßt den Digitalcheck für Gesetze, der seit dem 1. Januar 2023 Gesetzgebende bei der Schaffung digitaltaugliche Regelungen unterstützt. Digitaltaugliche Regelungen und Gesetze bringen die Digitalisierung voran. Ebenso wichtig ist die stetige inhaltliche, methodische und strukturelle Fortentwicklung des Digitalchecks für Gesetze.

Für berufsständische Vertretungen werden diese Vorhaben immer wichtiger, denn die meisten neuen Gesetzesvorhaben und Verordnungen haben einen Bezug zu Digitalisierungsthemen. So sei beispielhaft die kürzliche Änderung des Steuerberatungsgesetzes (StBerG) und die Verordnung über die Steuerberaterplattform und die besonderen elektronischen Steuerberaterpostfächer (StBPPV) genannt, mit deren Beschluss die Voraussetzungen für die digitale Steuerberateridentität geschaffen wurden.

Die Weiterentwicklung der eIDAS-Verordnung sieht unter anderem den Ausbau europäisch einheitlicher Vertrauensdienste vor. Mit der Realisierung von sog. EUdi-Wallets werden weitere Möglichkeiten eröffnet, um sich gegenüber Online-Diensten sicher auszuweisen und die Datenweitergabe zweckgerichtet zu regeln. Mindestens im Rahmen der Authentifizierung ergeben sich daher Überschneidungen und gemeinsame Nutzendenreisen mit dem Onlinezugangsgesetz. Daher sollten beide Verfahren gemeinsam berücksichtigt bzw. harmonisiert werden.

E.H - editiert am 27.01.2024

Antwort von Bundesamt für Migration und Flüchtlinge (BAMF):

Neben den von anderen Konsultationsteilnehmenden bereits genannten, geltenen Gesetzen und Beschlüssen weisen wir zusätzlich auf Folgendes hin:

eIDAS 2.0 ist eine Schlüsselspezifikation, die im OZG-Umfeld Anwendung finden muss. Insbesondere die Version 2, die Erweiterung der Vertrauensdienste: Elektronische Zertifikate zur Authentifizierung, ID-Wallets .

DSGVO, als wesentlicher Standard zum Schutz von Personendaten, sollte im OZG Kontext Anwendung finden.

EUDI Nutzung zur Identifikation und das Verwalten von Nachweise und Bescheide wird laut Beschluss der EU von allen Mitgliedsstaaten genutzt. Das Benutzerkontobund stellt derzeit noch einen Gegenentwurf dar und muss mit dieser Verordnung harmonisiert werden. https://www.intesigroup.com/en/wp-content/uploads/sites/4/2023/02/ARF_v100_for_publication_SqMV8FwSeE3xg7teicYY4hFDY_93678.pdf

Die europäische Initiative GAIA-X, welche durch das Bundesministerium für Wirtschaft und Energie (BMWK) unterstützt wird, umfasst die Koordination verteilter Cloud-Dienste sowie die Bereitstellung einer Datenplattform (DataSpaces). Mit Blick auf ein Zusammenspiel der Ecosysteme mit medienbruchfreien und interoperable OZG Prozessen, sollten die in diesem Kontext definierten Standards und Architekturansätze mit betrachtet werden.

Beschlüsse des IT-Planungsrats, z.B. bzgl. Registermodernisierung, Einsatz von OSCI/XTA im Kontext OZG, siehe https://www.it-planungsrat.de/beschluss/beschluss-2023-38

Auf Bundesbehörden-Ebene: Dienstekonsolidierung, die auch zu einer höheren Form des Datenaustauschs und gemeinsamen Aktivitäten zur höheren Abdeckung an Digitalisierung führen kann.

T.K - editiert am 27.11.2023

Sammlung CDO-MID Sachsen-Anhalt und Vertreter von Kommunen des Landes:

Mehrere Meldungen zusammengefasst daher Dopplungen möglich:

Größte Relevanz für die Digitalisierung der öffentlichen Verwaltung haben aktuell:

Digitalstrategie Sachsen-Anhalt 2030

Handlungsempfehlungen aus dem CIO-Projekt 2023 des Landes Sachsen-Anhalt (Modell Sachsen-Anhalt)

EU: Single Digitale Gateway Verordnung, DSGVO – insbesondere relevant, weil sie direkt und für alle Behörden (auch Kommunen!) verpflichtend umzusetzen sind (schnell und eindeutig). Die Aktionspläne der EU haben meiner Meinung nach bisher nicht viel Wirkung entfaltet.

Deutschland: BITV 2.0 (ist verpflichtend),

eGovernementgesetze des Bundes und des Landes Sachsen-Anhalt, Verwaltungsverfahrensgesetz,

Onlinezugangsgesetz, Registermodernisierungsgesetz leider handelt es sich dabei größtenteils um Ermöglichungsgesetze. Insbesondere Kommunen werden als wichtige Umsetzer digitaler Verwaltungsdienstleistungen nicht adressiert und zur Umsetzung verpflichtet. Dies stellt ein Hindernis in den Haushaltsplanungen dar, insbesondere für Kommunen in der Konsolidierung. Die fehlende Verpflichtung zur ganzheitlichen Digitalisierung für Kommunen stellt eine starke Bremse für die Digitalisierungsbemühungen dar. Ganzheitliche Digitalisierung ist Pflichtaufgabe – das muss in die Gesetze.

GG/IT-Staatsvertrag, zum OZG, EGovernmentG, Gesetze zur Barrierefreiheit, Datenschutz DSGVO, IT-Sicherheit (KRITIS, PortalVO), RegistermodernisierungsG/IDNrG, Digitale-Familienleistungs-G, Entscheidungen/Beschlüsse/etc. Deutschland: XÖV-Rahmenwerk, FIM, Beschlüsse IT-Planungsrat (zur Interoperabiltät, Nutzerkonten Registermodernisierung, Einsatz XÖV,....), GDI.de, NEGS, Efa-Mindeststandards

*EU: SDG VO, EIDAS, AI Act, DGA, EIF Act, INSPIRE, NIS II,

*Unmittelbar richten wir uns nach dem OZG-Gesetz und vor allem nach den 16 Fokusleistungen. Hausintern wollen wir zudem die gemeinsame Arbeit digitalisieren und automatisieren (selbst gesetzte Ziele).

*Zudem sind bindende Sicherheitsrichtlinien wie NIS2 unser Fokus. Im Zuge dessen sollten der IT-Grundschutz nach BSI nicht vergessen werden.

*Weitere Fachamtsspezifische Regelungen (ÖDG, etc.) kommen hinzu.

M.P - original vom 20.11.2023

Diese Strategiepapiere, Beschlüsse und Gesetze haben in der aufgeführten Reihenfolge für uns die größte Relevanz:

Netzstrategie 2030 der öffentlichen Verwaltung

Digitale Verwaltung 2020

Gesamtarchitektur zur Dienste Konsolidierung des Bundes, Dienstekonsolidierung des Bundes zur Vereinfachung und Standardisierung von Softwareanwendungen durch Bereitstellung zentraler Lösungen

IT Architekturrichtlinie 2020

DVC

IT Sicherheitsgesetz

Kritische Infrasstrukutr KRITIS/NIS2

Strategie zur Stärkung der Digitalen Souveränität für die IT der Öffentlichen Verwaltung

Cybersicherheitsstrategie für Deutschland

Simpl, Data Exchange Architecture EU

https://digital-strategy.ec.europa.eu/en/news/simpl-streamlining-cloud-edge-federations-major-eu-dataspaces-updated-october-2023 11. Digital Services Act Paket 12. Digitale Agenda für Europa 2020 13. DSGVO 14. OpenData Strategie des Bundes 15. Datenstrategie der Bundesregierung 16. KI Strategie Deutschland 17. Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) 18. Green IT – nachhaltig für zukunftssichere IT-Lösungen

M.M - original vom 21.11.2023

EU Cyber Resilience Act bzw. der entsprechende Entwurf

Die Single-Digital-Gateway Verordnung

Once-Only Technical System

IT-Sicherheitsverordnung Portalverbund

BSI-Standards

Leitlinie für die Informationssicherheit in der öffentlichen Verwaltung

eIDAS Verordnung über die elektr. Identifizierung und Vertrauensdienste

Antragslose Verfahren nach §35a LAO, Verfahrensordnung

aber auch die Qualität der Daten sollte eingehalten werden, speziell in einem Verteilten System sollten diese beachtet werden

Data Quality Dimensions

Software Qualität

A.S - original vom 21.11.2023

Aus Sicht der DigitalService GmbH des Bundes:

Hier noch nicht genannt und aus unserer Sicht richtungsweisend (auch mit dem Blick auf die Erfolge im Ausland): der Servicestandard des Bundesministerium des Innern und für Heimat (BMI). Wie kann dieser mehr zur Anwendung und Durchsetzung kommen?

J.P - original vom 21.11.2023

Antworten Team PwC: - OZG 2.0 - Gemeinsame Länderposition zur Verwaltungsdigitalisierung (https://www.stmd.bayern.de/wp-content/uploads/2023/03/Gemeinsame-Laenderposition.pdf) - E-Government-Gesetze in Bund und Länder - Registermodernisierungsgesetz - EfA-Finanzierung des IT-Planungsrat (https://www.it-planungsrat.de/beschluss/beschluss-2023-35) - eIDAS-Verordnung (Novellierung andauernd) - Verwaltungsverfahrensgesetze in Bund und Länder - Datenschutzgesetze in Bund und Ländern - Fachrecht der jeweiligen Verwaltungsbereiche - Beschlüsse des IT-Planungsrates - Beschlüsse der Gremien im Umfeld des IT-Planungsrates - Technische Richtlinien des BSI

IT.E.B.S.S - original vom 22.11.2023

wir sind der Meinung, dass der Ausgangspunkt sämtlicher Überlegungen zu Datenaustauschen / Architekturen der Reifegrad D der OOTS sein sollte

M.K - original vom 22.11.2023

Antworten des Programmbereichs OZG-EU-OOTS der Gesamtsteuerung Registermodernisierung

Die nachfolgende Liste zeigt eine grob priorisierte Liste wichtigster richtungsweisender Dokumente. Anwendungen und Beschlüsse des IT-PLR sind nicht berücksichtigt, da sie über die Architekturrichtlinien abgedeckt sind. Für die BSI Richtlinien gilt es nur einige herauszugreifen. Aufgrund der kurzen Bearbeitungsfrist wurden, konnten diese nicht einzeln aufgeführt werden.

1 SDG-VO, Single Digital Gateway VO (EU-VO 2018/1724) 2 DSGVO, Datenschutzgrundverordnung (EU-VO 2016/679) 3 eIDAS, Verordnung über elektronische Identifizierung und Vertrauensdienste (EU-VO 910/2014) 4 BSI-Gesetz sowie BSI Kritisverordnung 5 EGovG Bund, E-Government Gesetz Bund 6 OZG, Onlinezugangsgesetz 7 Digitalisierungsstrategien von Bund, Ländern und Kommunen 8 NOOTS, Technical Design Document 9 ITSiV-PV, IT Sicherheitsverordnung Portalverbund 10 E-Government Gesetze der Länder 11 RegMoG, Registermodernierungsgesetz 12 Beschlüsse von IT-Planungsrat und OZG-AL-Runde (z. B.: IT-Architekturrichtlinie 2021/37, Support- und Betriebsorganisation von EfA-ODs 2023/07, Verfügbarkeiten von IT-Systemen im Portalverbund 2018/40, Responsive Design 2018/40, FitStore und GovDigital Marktplatz 2022/27, Leitlinie Informationssicherheit 2020/05 u.a.,Strategie 2021/46, DVC-Koordinierungsstelle 2023/18 u.w., DVC-Zielarchitektur 2022/47, DVC-Architekturboard, MeinUK 2020/01 u.a.). 13 BSI Richtlinien 14 ISO Normen 15 Wahl- und Parteiprogramme der Parteien

M.H - original vom 24.11.2023

Universtität Duisburg-Essen, HISinOne-Cm.nrw: Aus der Perspektive der Hochschulen sind für die Digitalisierung der öffentlichen Verwaltung insbesondere die E-Government-Gesetze (E-GovG) der Bundesländer und das OZG-Änderungsgesetz in Deutschland richtungsweisend. Die E-GovG der Länder fokussieren auf die End-to-End Digitalisierung und betonen die Nutzer:innenperspektive, was für die digitale Transformation im Hochschulbereich von großer Bedeutung ist. Das OZG-Änderungsgesetz trägt dazu bei, die bisherige Vielfalt im OZG zu reduzieren und somit Komplexität zu verringern.

Das E-Government-Gesetz (EGovG) spielt zentrale Rolle, da es die ganzheitliche und durchgehende digitale Transformation in der Verwaltung an Hochschulen durch die Einführung elektronischer Kommunikationskanäle, elektronischer Aktenführung, digitaler Nachweise und Bezahlmethoden sowie maschinenlesbarer Datenformate fördert

Die EU-Datenschutz-Grundverordnung (DSGVO)

Onlinezugangsgesetz (OZG) und Single-Digitale-Gateway Verordnung (SDG)

Die Digitale Agenda der EU und Deutschlands in Bezug zum EU-Aktionsplan für digitale Bildung bzw. die Vision vom europäische Bildungsraum unterstützt die EU-Mitgliedstaaten beim Aufbau krisenfester und inklusiver Bildungssysteme, was unmittelbar die Hochschulen beeinflusst. Der Aktionsplan zielt darauf ab, die digitale Bildungskompetenz zu stärken, den Einsatz digitaler Technologien für Lehrzwecke zu fördern und digitale Infrastrukturen und Konnektivität zu verbessern. Für Hochschulen bedeutet dies eine Förderung der Integration digitaler Technologien in den Lehrbetrieb, die Stärkung der digitalen Kompetenzen von Studierenden und Lehrenden und die Verbesserung der digitalen Infrastruktur. Dies unterstützt Hochschulen bei der Umsetzung innovativer Lehrmethoden und trägt zur Weiterentwicklung ihrer digitalen Transformationsstrategien bei. Die Initiative betont die Bedeutung von Bildung für persönliche Entfaltung und gesellschaftliche Teilhabe und setzt Schwerpunkte in Bereichen wie Chancengleichheit, Qualität in der Bildung, digitale Bildung und Bildung für den Klimaschutz.

F.K - editiert am 28.11.2023

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen: - Onlinezugangsgesetz – da die Hochschulen OZG-Leistungen umsetzen müssen - Single Digital Gateway-Verordnung der EU – da einige der OZG-Leistungen für Hochschulen auch SDGII-relevant sind - Registermodernisierungsgesetz inkl. Identifikationsnummerngesetz – da Hochschulen Register sind und somit unter das IDNrG fallen; die IDNr ist in den Campusmanagementsystemen zu integrieren
- E-Government Gesetze, sowohl Bundes- als auch Landesgesetze, insbesondere, wenn in diesen die FIM Systematik und Open Data Vorgaben gesetzlich verankert werden - Verwaltungsverfahrens Gesetze, Bundes- und Landesgesetz, vor allem der §3 a VwVfG (elektronische Form) - Sämtliche Gesetze, die die Schriftform fordern, Schriftformerfordernis sollte überall überprüft werden

S.L - original vom 05.12.2023

Welche Strategiepapiere, Gesetze, Beschlüsse (EU- und DE) sind aus Ihrer Sicht richtungsweisend für die Digitalisierung der öffentlichen Verwaltung?

EG Dienstleistungsrichtlinie EGDLR mit der Forderung Leistungen elektronisch und aus der Ferne erledigen zu können und des Einheitlichen Ansprechpartners als Berater und oder Mittler (Single Point of Contact - SPOC)

eIDAS zur Definition und Standardisierung von Vertrauensniveaus, sowie alles rund um Signaturen und der Einführung von Siegeln. Das Beinhaltet zahlreiche Gesetzesanpassungen sowie der Korrektur von technischen Richtlinien.

SDG als ganzheitlicher Ansatz für Verwaltungsleistungen, der sich auf die geschaffenen Werte der EGDLR und eIDAS abstützt und den Nutzer und seine Bedürfnisse in den Mittelpunkt stellt.

DSGVO

OZG als im Vergleich zur EU abgeschwächte Form der Verwaltungsdigitalisierung. Das Delta zur EU wird an den Betreffenden Stellen sukzessive Nachgezogen.

Welche haben aus Ihrer Sicht (für Sie und für DE) größte Relevanz? - eIDAS - SDG - EGDLR - DSGVO

K.G - original vom 08.12.2023

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister:

Auf nationaler Ebene sind von besonderer Relevanz:

Onlinezugangsgesetz

E-Government-Gesetz

DSGVO

Digitalisierungsgesetze der Länder

eIDAS

Digitalstrategie der Bundesregierung

Europäische Ebene: - Rahmenwerk der Europäischen Digitalen Dekade (2030 Digital Compass - The European Way for the Digital Decade) - Interoperabilitäts-Rahmenwerke und Maßnahmen: SDG, eID, EIF

Zivilgesellschaftliche Quellen mit hoher Relevanz: - eGovernment-Monitor der Initiative D21 - Deutschland-Index der Digitalisierung 2023 sowie die weiteren Veröffentlichungen des ÖFIT - DIN-Whitepaper „Normung und Standardisierung bei der Digitalisierung der öffentlichen Verwaltung“

Exkurs: Konkreter Use Case BundID:

Sehr große Relevanz hat aus Sicht der VITAKO der (zukünftige) Wegfall der (gesetzlich vorgeschriebenen) De-Mail und die Etablierung der BundID samt Postfachdienst. Die Nutzung der BundID darf nicht (wie aktuell) mit hohen bürokratischen Hürden verbunden sein. 1. Es ist nicht zielführend, ein weiteres Verzeichnis jeder öffentlichen Stelle zu führen, welche genauen Dienstleistung jeder mit der BundID als Authentisierungsmerkmal ausstattet. Dies würde zu einer hohen Bürokratisierung führen, da jede Veränderung / jede Anbindung immer mit Meldepflichten zu tun hätte. Stattdessen sollte jede öffentlich/rechtliche Stelle (Kommunen, kommunale IT-Dienstleister, Landesbehörden, ö/r Zweckverbände etc.) die Berechtigung haben, die BundID für die Verwaltungsprozesse benutzen zu können, ohne jeweils neue Anträge oder Einträge vornehmen zu müssen. 2. Die Beantragung / Einrichtung von Mandanten für die BundID (z.B. wie aktuell für Serviceportale) muss einfach, automatisch und schnell sein. 3. Der Postfachdienst muss umgehend/schnellstmöglich mit hoher Funktionalität bereitgestellt werden. Durch den Wegfall der De-Mail fehlen ansonsten in Kürze verbindliche und einfache Zustelldienste. Zudem muss der Postfachdienst mit entsprechenden Schnittstellen auf Standardbasis umgesetzt werden, damit die Behörden sowohl Informationen von Bürgerinnen und Bürgern / Gewerbetreibenden etc. direkt darüber zugestellt bekommen, als auch die (v.g.) Zielgruppen der Verwaltung über diesen Dienst erreicht werden können. Standardschnittstellen deshalb, damit die (kommunalen) Fachverfahren mit einer einheitlichen Kommunikationsinfrastruktur ausgestattet werden können. Sonderlösungen oder komplexe Infrastrukturkomponenten in diesem Kontext sind nicht zielführend.

G.B - original vom 28.01.2024

Wir folgen den Ausführungen der DIHK [1] und teilen die Einschätzung, dass eine strukturierte Aufarbeitung der bestehenden Unterlagen die Teilnehmer*innen am Konsultationsprozess in ihrer Meinungsbildung unterstützt hätte. Es ist bedauerlich, dass dies bisher nicht geschehen ist.

Mit Ausnahme von Konzepten der FitKO zur Nutzerinnenzentrierten Umsetzung des Registermodernisierungsgesetzes die im Rahmen von IFG Anfragen öffentlich wurden sind uns keine Papiere bekannt die der Zielsetzung folgen würden die Bürgerinnen zu befähigen.

[1] https://gitlab.opencode.de/bmi/ozg-rahmenarchitektur/zielbild-ozg-rahmenarchitektur/-/issues/141note_93470

04. Beachtung der föderalen IT-Architekturrichtlinien

Datum der Veröffentlichung: 25.10.2023
Anzahl eingegangener Antworten: 39
Issue # in GitLab: #139
Leitfrage 04

Welche Gründe sprechen Ihrer Meinung nach aktuell gegen eine Beachtung der föderalen IT-Architekturrichtlinien? Kennen Sie positive Beispiele zur Einhaltung technischer Richtlinien?

https://docs.fitko.de/arc/policies/foederale-it-architekturrichtlinien/

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

S.W - editiert am 17.11.2023

Gegen die Einhaltung der föderalen IT-Architekturrichtlinie spricht die trägen Abstimmungsprozesse zwischen den Beteiligten. Außerdem werden die wichtigsten Teilnehmenden - die Kommunen - nicht direkt in die Entscheidungsprozesse mitgenommen. Kommunale Vertreter (nicht KLV´n) sollten direkt im IT-Planungsrat sitzen und in den Gremien mitentscheiden können. Dies sollte in einem rotierenden Ablauf geschehen und alle Vertreter der Kommunen aus den Bundesländern sollten mit am Tisch sitzen. Denn die praktischen Experten sitzen ausnahmslos alle in den Kommunen und wissen genau, was zu tun ist, um eine erfolgreiche Umsetzung zu garantieren.

Positiv zu sehen ist, dass die strategischen Ziele sehr gut abgebildet werden. Die Umsetzung bleibt jedoch bis heute weit hinter den selbst gesteckten Zielen zurück.

M.P - original vom 01.11.2023

Die Einhaltung umfangreicher IT-Architekturrichtlinien kann die Zeitrahmen für Projekte verlängern. Vorhandene Infrastrukturen können nicht zu den geforderten Anforderungen kompatibel sein. Richtlinien schänken die Flexibilität und Innovation ein, oft erfordern sie auch höhere Investionen. Die Kenntnis der IT-Architekturrichtlinien ist nicht vorhanden. Es existiert keine Architektur Governance bei den Betreibern und Nutzern.

Cisco_Issue_4

T.G - original vom 01.11.2023

IBM unterstützt den Ansatz der Föderalen IT-Architektur, TOGAF als offenen Standard für Architekturbeschreibungen zu verwenden und Architektur ganzheitlich zu beschreiben.

TOGAF definiert den Begriff der Facharchitektur (Business Architecture). Facharchitektur und IT-Architektur stehen in Korrelation zueinander. Wir haben in Projekten sehr gute Erfahrungen gemacht, in der Facharchitektur neben (Fach-)Prozessen auch Fachkomponenten bzw. Fachbausteine (analog zu technischen Bausteinen zu beschreiben ( –siehe „231024_Konsultationsprozess_Online-Webseminar_I, Seite 7) zu modellieren. Ziel ist es, Fachbausteine 1:1 in technische Bausteine überführen zu können.

Weiterer Vorteil in der Abbildung von Fachkomponenten auf technische Bausteine, liegt in der Möglichkeit, verschiedene technische Umsetzungen zu ermöglichen. Dies ist aufgrund der heterogenen Systemlandschaft insbesondere auf Landes- und/oder kommunaler Ebene notwendig.

S.M - editiert am 05.12.2023

Bundesagentur für Arbeit: Die BA enthält sich an der Stelle, da sie als Bundesbehörde auf föderaler Ebene keine Betroffenheit hat.

Als positives Beispiel für die Einhaltung der technischen Richtlinien ist die Interoperabilität zwischen verschiedenen Kommunikationspartnern / Akteuren.

L.K - original vom 05.12.2023

Sie dürfen hier auch gerne Ihre Erfahrungen mit der Architekturrichtlinie für die IT des Bundes teilen - welche Mechanismen tragen zu deren Einhaltung bei, wo sehen Sie Verbesserungspotenziale?

M.S - editiert am 17.11.2023

Open Source Business Alliance - Bundesverband für digitale Souveränität e.V.:

Ein positives Beispiel zur Einhaltung der föderalen IT-Architekturrichtlinien ist die Entwicklung des souveränen Arbeitsplatzes für die öffentliche Verwaltung (jetzt „openDesk“):

„Der openDesk ist wesentlicher Bestandteil für eine selbstbestimmte, sichere und zukunftsfähige Informationstechnik für die gesamte öffentliche Verwaltung. Mittels openDesks wird Mitarbeitenden, IT-Administratoren und Betreibern der öffentlichen Verwaltung zukünftig eine wirksame Open Source-basierte Alternative im Bereich Arbeitsplatzumgebung zur Verfügung stehen.

openDesk stellt dabei eine Maßnahme im Rahmen der gemeinsamen Strategie zur Stärkung der Digitalen Souveränität von Bund, Ländern und Kommunen sowie einen wesentlichen Schritt zur Auflösung kritischer Abhängigkeiten in der IT der öffentlichen Verwaltung dar. Das Projekt "openDesk - der souveräne Arbeitsplatz" basiert auf dem Auftrag des IT-Rats an das Bundesministerium des Innern und für Heimat (BMI) zur Erarbeitung und Prüfung einer Alternative im Bereich Arbeitsplatzsoftware für die öffentlichen Verwaltung vom Oktober 2020. Die Erarbeitung von openDesk erfolgt durch eine kollaborative, offene und effektive Zusammenarbeit innerhalb der öffentlichen Verwaltung und mit dem Open-Source-Ökosystem.

Der openDesk bietet eine Vielzahl an Vorteilen. Als geplanter Standard für die öffentliche Verwaltung im Bereich digitaler Arbeitsplatz zeichnet sich openDesk durch Nutzerfreundlichkeit, Sicherheit, Kollaborationsmöglichkeiten und Anpassungsfähigkeit hinsichtlich der Bedarfe der Öffentlichen Verwaltung aus.“

Siehe https://www.cio.bund.de/Webs/CIO/DE/digitale-loesungen/digitale-souveraenitaet/souveraener-arbeitsplatz/souverarner-arbeitsplatz-node.html sowie https://gitlab.opencode.de/bmi/souveraener_arbeitsplatz/info und https://gitlab.opencode.de/bmi/souveraener_arbeitsplatz/info/-/blob/main/FAQ.md)

A.B - editiert am 14.11.2023

Grundsätzlich sind aus Sicht der bayrischen IHKs IT-Architekturrichtlinien, wie auch durch die Fitko spezifiziert, positiv zu beurteilen, da Sie einen gemeinsamen Mindeststandard festlegen. So ist z.B. der Ansatz API-First richtig und wird auch in der Digitalindustrie so gelebt. Kritisch können jedoch durchaus einzelne Punkte wie z.B. Herstellerunabhängigkeit gesehen werden, da Sie manchmal dem Ziel einer schnellen, ausgereiften und guten Digitallösung entgegen stehen. Auch sollte nicht notwendigerweise jede Basiskomponente wie z.B. eine Workflowengine selbst entwickelt werden. Hier könnte Souveränität statt Autonomie eine Lösung sein.

A.S - original vom 14.11.2023

Welche Gründe sprechen gegen eine breitere Verwendung der IT-Architekturrichtlinien:

Architekturrichtlinien scheiter, qua ihres visionären Charakters, an der Komplexität und Lebenswirklichkeit der Verwaltungs-IT. Hier entsteht ein Dilemma, da sich IT-Verantwortliche oft an die Richtlinien halten möchten, die lokalen Gegebenheiten jedoch nich den Anforderungen der Richtlinien nachkommen können.

Overhead der Richtlinien. Die konkreten Punkte der ARL sind oft leicht verständlich und klar formuliert. Finden sich jedoch erst nach hinreichender Befassung auf bspw. der FITKO-Seite und sind somit von unnötigem Overhead überlagert. Hier besteht Optimierungs- und Fokussierungspotential. Je einfacher das Produkt, desto leichter lässt es sich vermarkten.

Einordnung für Entscheiderinnen und Entscheider und Bekanntheitsgrad unter diesen

M.D - editiert am 15.11.2023

Der Beschluss 2021/37 des IT-Planungsrates ("Der IT-Planungsrat beschließt die verbindliche Anwendung der „Föderalen IT-Architekturrichtlinien“.) ist aus meiner Sicht kein verbindlicher Standard im Sinne des § 2 Abs. 2 IT-Staatsvertrages, da die Voraussetzungen aus § 2 Abs. 1 IT-Staatsvertrag nicht vorliegen. Die Regelungsinhalte der „Föderalen IT-Architekturrichtlinien“ sind nicht erforderlich für den Datenaustausch zwischen Bund und Ländern. Vielmehr handelt es sich bei den Strategischen Architekturrichtlinien um Regelungen, die offenbar Umsetzungen von Projekten begleiten sollen, gleichzeitig aber auch gegen geltende gesetzliche Regelungen verstoßen. So ist SR4 ("Alle relevanten Sicherheitseinstellungen müssen bereits in der Grundkonfiguration des Dienstes aktiviert sein") eine absurde, gegen das Gesetz verstoßende Vorgabe vor dem Hintergrund der Regelungen aus DSGVO, des BDSG, der eGovG sowie dem BSIG und der notwendigen Abwägungen zwischen Datenschutz und IT-Sicherheit.

Die "erste Fassung" der Förderalen Architekturrichtlinien ist kein Ersatz für eine Architekturrichtlinie des Bundes, sie entfaltet weder Bindungswirkung für die Bundesverwaltung noch ist das Dokument inhaltlich geeignet, um als "Architekturrichtlinie" gelten zu können.

Insgesamt weisen Beschlüsse des IT-Planungsrates nicht die erforderliche Qualität auf, die auf einer solchen Ebene notwendig sind, weder formell noch fachlich. Beispielsweise liegt für den Beschluss 2023/51 ("Der IT-Planungsrat beschließt „XBezahldienste“ als Standard für Online-Zahlverfahren im Bereich der öffentlichen Verwaltung.") gar keine Spezifikation eines IT-Standards vor, die Parameter der API sind bislang nicht bestimmt, hier wurden nicht einmal die eingereichten Unterlagen für den Tagesordnungspunkt auf Vollständigkeit geprüft. Der ITPLR hat durch seine bisherige Arbeit kein Vertrauen aufbauen können als Standardisierungsgremium zuverlässige und fachlich zu rechtfertigende Beschlüsse zu treffen. Für IT-Projekte des Bundes wäre es daher aus meiner Sicht ratsam, die Abstimmung mit den Ländern auf die gesetzlich vorgeschriebenen Aufgabenbereiche zu beschränken.

M.S - original vom 17.11.2023

Was spricht dagegen? Unkenntnis und Grad der Verbindlichkeit vs. wie kommen wir vor Ort dahin, die Standards einzuhalten? Was kostet das? Nichtmals die Architekturrichtlinie des Bundes ist allen Bundesbehörden und Dienstleistern bekannt; die Beschlüsse des IT-Planungsrat werden nicht aktiv auf allen Ebenen vermittelt. Es fehlt eine Folgenabschätzung während der Erstellung für die unterschiedlichen föderalen Ebenen.

M.N.AKDB - original vom 17.11.2023

Gegen eine Beachtung der aktuellen föderalen Architekturrichtlinien (Version 1.0 Stand: 29.10.2021) spricht nichts.

Gleichwohl deutet die gelebte Heterogenität der realen Verwaltungsdigitalisierung auf Defizite hinsichtlich Bekanntheitsgrad, Beachtung und Eignung hin. Auch ist der Charakter von Richtlinien beizubehalten, um Zeiträume für Projekte nicht durch überschießende Richtlinien zu belassen - es muss also genügend Beinfreiheit für die sachlich richtige Abweichung von der Richtlinie bleiben.

Weiterhin ergeben sich Leerstellen zur Förderung der Datenintegration.

Positive Beispiele sind die EfA-Mindeststandards, Open Data-Installationen und die kontinuierliche laufende Diskussion über digitale Souveränität.

Bei der Compliance gegenüber technischen Richtlinien i.e.S. stechen die Beachtung der Maßgaben des BSI, ISO27001 und i.w.S. der DS-GVO hervor.

D.T.OZG.S - editiert am 10.01.2024

Ausgangslage und Grundverständnis:

Aufgrund des IT-Planungsratsbeschlusses 2021/37 vom 29.10.2021 sind die föderalen IT-Architekturrichtlinien verbindlich anzuwenden. Die föderalen IT-Architekturrichtlinien stellen ein generelles Regelwerk für die Umsetzung von Digitalisierungsvorhaben dar. Mithilfe der IT-Architekturrichtlinien wird den beteiligten Stakeholdern, insbesondere für diejenigen, die Umsetzungsvorhaben durchführen und verantworten, ein Regelwerk an die Hand gegeben, welches generelle Anforderungen definiert, die zu berücksichtigen sind.

Gründe die gegen eine Beachtung der föderalen IT-Architekturrichtlinien sprechen:

Grund 1: Verbindlichkeit muss Marktnachfrage generieren

Die Verbindlichkeit der Anwendung der IT-Architekturrichtlinien sollte bzw. müsste zunächst von den originär Umsetzungsverantwortlichen nämlich den IT-Dienstleistern von Bund, Land und Kommunen berücksichtigt und praktisch umgesetzt werden. Folgerichtig würden dann die IT-Architekturrichtlinien auch als Voraussetzungen, Rahmenbedingungen bzw. Kriterien (insb. im Rahmen von Ausschreibungen) an die externen Dienstleiter also an die unterstützende IT-Industrie weitergegeben. Die so entstehende Marktnachfrage generiert ein passendes Angebot des externen IT-Marktes. Dabei muss berücksichtigt werden, dass die Nachfrage in für die IT-Industrie relevanten Größenordnungen entsteht und langfristig, nachhaltige Investitionen rechtfertigt.

Grund 2: Berücksichtigung des Investitionsschutz und Aufsetzen einer Roadmap

Weit vor dem IT-Planungsratsbeschluss im Jahr 2021 zur Verbindlichkeit der föderalen IT-Architekturrichtlinien, wurden seitens aller IT-Verantwortlichen Bereiche (insb. IT-Dienstleister der Verwaltung und der auf die Verwaltung spezialisierten IT-Industrie) IT-Architekturen erfolgreich konzipiert, aufgebaut und betrieben. Diese folgten und folgen den spezifischen Anforderungen der jeweiligen Nutzendgruppen und berücksichtigen die bestehenden Besonderheiten und Anforderungen der entsprechenden Ebenen (Bund, Land, Kommune). Zum einen weisen die geschaffenen IT-Architekturen immer einen Überlappungsgrad mit den föderalen IT-Architekturen auf und müssen dementsprechend nicht vollständig neu konzipiert und realisiert werden, zum anderen muss man aus Investitionsschutzgründen Zeiträume (insb. Vertrags- und Vergabezyklen) berücksichtigen bis zu denen neue Architekturkomponenten zum Einsatz kommen können. Eine entsprechende Roadmap sollte entsprechend je Betriebsbereich aufgebaut und eingeplant werden.

Grund 3: „Mehr Standards in IT-Architekturrichtlinien = Mehr Beachtung“

IT-Architekturrichtlinien werden dann am besten von allen beteiligten Stakeholdern geplant und umgesetzt werden, je näher sich die Einzelrichtlinien, Vorgaben und Methoden an den marktüblichen Standards orientieren. Vor diesem Hintergrund empfiehlt es sich, so weit wie möglich auf verwaltungsspezifische und nur in Deutschland und auch Europa gültige Vorgaben zu verzichten. Vor dem Hintergrund der global und international aufgestellten IT-Industrie hat Deutschland damit die Chance IT-Architekturrichtlinien für die öffentliche Verwaltung zu definieren und weiterzuentwickeln, ohne den Anschluss an die Innovationskraft der IT-Industrie zu verlieren.

Grund 4: Fehlende Erfolgskontrolle/Prüfung bzw. Sanktionierung

Jede verbindliche Vorgabe muss auch einer regelmäßigen Erfolgskontrolle bzw. Prüfung unterzogen werden. Nur so kann über die Laufzeit erreicht werden, dass die Vorgaben auch eingehalten werden und die Vorgaben selbst können durch die regelmäßige Feedbackschliefen praxisbezogen angepasst bzw. adaptiert werden.

Aus Sicht der Deutschen Telekom sollte das Architekturboard neben der Definition von IT-Architekturrichtlinien auch die Einhaltung der Richtlinien im Rahmen der Entwicklung und dem Betrieb von Anwendungen prüfen (lassen).

Vor diesem Hintergrund sollten die IT-Architekturrichtlinien in ein gesamtheitliches Governance-Framework eingebunden werden. Die Etablierung einer entsprechenden Governance erfordert neben der reinen Definition von Anforderungen auch die Überprüfung auf Einhaltung der erteilten Maßgaben. Innerhalb des The Open Group Architecture Frameworks (TOGAF), welches bereits im IT-Planungsratsbeschluss 2021/37 Erwähnung fand, sind sowohl die Definition von Architektur-Prinzipien als auch die Architektur Governance als Methodiken enthalten.

Positive Beispiele zur Einhaltung technischer Richtlinien

Als zwei praxiserprobte Beispiele, welche erfolgreich die Einhaltung von technischen Richtlinien sicherstellt, seien IT-Grundschutz des BSI sowie die GMP-Richtlinien genannt:

Das Bundesamt für Sicherheit in der Informationstechnik erlässt mit IT-Grundschutz ein Regelwerk zur IT-Sicherheit, welches von verschiedenen Organisationseinheiten ein- und umgesetzt wird. Wesentliche Basis von IT-Grundschutz sind die modularen und aufeinander aufbauenden Bausteine sowie Umsetzungshinweise. Die Einhaltung von IT-Grundschutz kann und wird durch interne und externe Revision überprüft.

Die GMP-Richtlinien (Good Manufacturing Practice) dienen heute der Qualitätssicherung von Arzneimitteln und werden darüber hinaus zum Teil im Bereich von Wirkstoff-, Lebensmittel- und Kosmetikaproduktion und -vertrieb angewandt. Die Richtlinien werden zentral von der EU erlassen und in Leitfäden näher erläutert, die in deutscher Übersetzung durch das Gesundheitsministerium bereitgestellt werden. In nationales Recht sind sie durch die Arzneimittel- und Wirkstoffherstellungsverordnung (AMWHV) übernommen und damit auch in Deutschland für alle Unternehmen dieser Branche rechtsverbindlich geworden. Die Richtlinien definieren allgemeine Anforderungen an das Qualitätsmanagementsystem. Die Gestaltung der Produktion obliegt aber weiterhin dem einzelnen Unternehmen. So bieten sie den beteiligten Unternehmen Rechtssicherheit und den zuständigen Behörden entsprechende Kontrollmöglichkeiten.

Frage04_OZGRahmenArchitektur_Konsultationsprozess

SEITENBAU - original vom 10.01.2024

Wir stimmen den genannte vier Gründen zu. Auch wenn im Sinne der IT-Architekturichtlinien gehandelt wird, so werden diese (z.B. in Ausschreibungen) nicht noch konsequent explizit referenziert bzw. auf Berücksichtigung hin kontrolliert..

P.S - original vom 17.11.2023

Ein gutes Beispiel für erfolgreiche technische Richtlinien sind sicher die zahlreichen technischen Richtlinien des BSI. Diese sind allerdings sehr viel ausführlicher, präziser und messbarer als die Föderalen Architekturrichtlinien. Letztere haben eher den Charakter von Architekturprinzipien (vgl. TOGAF). Sie sollen Entscheidungen leiten, in die im Einzelfall aber viele Faktoren fließen.

So wird SR 12 die “Umsetzung des Once Only Prinzips” verbindlich vorgeschrieben, obwohl die Voraussetzungen dafür nicht gegeben sind, solange das Once-Only System der Registermodernisierung nicht zur Verfügung steht. Die SR8: “Einsatz von Open Source” ist sinnvoll - mit OpenCoDE steht nun sogar eine geeignete Plattform dafür zur Verfügung. Viele Behörden haben aber keinerlei Erfahrung im Aufbau und in der Arbeit mit einer Open Source Community. Toxische oder kommerzielle Lizenzen bergen weiterhin Risiken, wenn Behörden den Umgang damit nicht ausreichend professionalisiert haben.

Ähnliche Herausforderungen stellen sich bei etlichen der Architekturrichtlinien. Die wenigen Beispiele zeigen aber bereits: Die Umsetzung der Richtlinien ist zum Teil schwierig, erfordert ein Abwägen zwischen weiteren Einflussfaktoren und es entstehen Kosten und Risiken, die die Herausgebenden der Richtlinien nicht tragen. Wir empfehlen verbindliche, umsetzbare Richtlinien von eher weichen, richtungsweisenden Architekturprinzipien zu trennen. Ergänzend müssen die Voraussetzungen zur Anwendbarkeit der Prinzipien geschaffen werden – bspw. durch geeignete Unterstützungsangebote für Behörden, die zum ersten Mal Ihre Lösungen Open Source bereitstellen wollen.

D.K - original vom 19.11.2023

Wir sehen keine überzeugenden Gründe gegen eine Beachtung der föderalen IT-Architekturrichtlinien. Die Einhaltung technischer Richtlinien ist entscheidend, um eine interoperable und effiziente IT-Landschaft in der öffentlichen Verwaltung zu gewährleisten. Die Einbindung der föderalen IT-Architekturrichtlinien in das Zielbild der OZG-Rahmenarchitektur ist wichtig, um eine kohärente und standardisierte Umsetzung sicherzustellen.

Positive Beispiele zur Einhaltung technischer Richtlinien finden sich in anderen Ländern, in denen erfolgreiche digitale Verwaltungsprojekte umgesetzt wurden. Diese Beispiele können als Best Practices und zur Inspiration für die deutsche Verwaltung dienen.

Risiko bei Richtlinien ist allerdings, dass diese den Charakter von allgemein gültigen Richtlinien (ohne spezifischen Produktbezug oder nicht mehr neutrale spezifische Vorgaben) verletzen. Durch falsch gesetzte Richtlinien besteht die Gefahr, indirekt doch spezifische, meist proprietäre Software festzusetzen.

D.S - original vom 19.11.2023

Zum einen sind diese weithin unbekannt bei den Softwareherstellern. Zum anderen sollte sich jede/r der/die sich Richtlinien ausdenkt in die Lage des Geschäftsführers eines Softwareunternehmens versetzen. Für diesen ist es wichtig, dass die Software möglichst fehlerfrei funktioniert, allen Fachgesetzen und -verordnungen entspricht, möglichst gut durch die Kunden bedient werden kann und eine hohe Akzeptanz bei den kommunalen Kunden hat. Bei all diesen Punkten zahlt eine Architekturrichtlinie nicht ein, im Gegenteil ist sie für den Softwarehersteller sogar schädlich, weil sie teils extreme Kosten hervorruft, ohne einen Beitrag zu den genannten Punkten zu leisten. Oft wird gefordert, die Kommunen müssten bei Ausschreibungen und Beschaffungen die erlassenen Richtlinien als Anforderung definieren. Aber auch bei den Kommunen bringen diese keinerlei Vorteile, bei der Nutzung der Software und verursache für diese erhebliche Mehrkosten. Das Grundproblem liegt darin, dass wir nicht auf der grünen Wiese arbeiten, sondern das Land dicht bebaut ist. Da kann man noch so viele Richtlinien erlassen, wie die Gebäude aussehen sollen. Niemand wird den Bestand abreißen und teuer neu bauen, nur weil eine Verordnung aus vielleicht sogar nachvollziehbaren Gründen andere Häuser vorschreibt. Man kann solche Richtlinien für die Neuentwicklung von Software durchaus umsetzen, wenn sie der Behörde, welche die Software beauftragt, einen Vorteil bringt. Ist kein Vorteil mit der Beachtung der Richtlinie verbunden, wird sie kein Auftraggeber in den Anforderungskatalog aufnehmen, wenn sie Mehrkosten verursacht. Ein Grundproblem ist dabei auch, dass die IT-Unternehmen, welche die Richtlinie umsetzen soll, nicht an deren Entwicklung beteiligt war. Oft lassen sich die Dinge garnicht sinnvoll in die Softwarelösungen und Prozesse integrieren und würden sogar zu Dysfuktionen führen. Um diese Konflikte bereits im Entstehungsprozess aufzulösen, ist eine Beteiligung der IT-Wirtschaft zwingend geboten. Im Zweifel müssen den Experten der IT-Wirtschaft die Arbeitsaufwände finanziert werden, genauso wie den meist fachlich unwissenden Beratern in den Projekten die Arbeit finanziert wird. Das gut investierte Geld führt zu weniger Widerständen, einer höheren Funktionalität und einer deutlich schnelleren Einführung.

TSA.S.W - original vom 20.11.2023

Grundsätzlich sind wir als TSA Public Service GmbH der Ansicht, dass die fehlende Beachtung von föderalen Architekturrichtlinien in fast allen Fällen zu nicht-nachhaltigen Leuchtturmprojekten führt, die dann weder in bestehenden Prozesse eingebettet sind noch im Rahmen einer gemeinsamen Weiterentwicklung betrachtet werden können.

Ein positives Beispiel für die Einhaltung technischer Richtlinien ist die Standardisierung der Zuständigkeitsfindung. Dies betrifft in diesem Kontext die regelmäßige Anwendung und Weiterentwicklung von Standards wie XZuFi beim Datenaustausch zwischen verschiedenen Fachverfahrensherstellern und verschiedener föderaler Ebenen. Dies gilt auch für den inzwischen veralteten Standard XD115, die im Kontext des Wissensmanagements von Servicecentern angewendet wurde und wird.

S.H - original vom 20.11.2023

Aus kommunaler Sicht, Großstadt 750.000 Einw.:

These: Reifegrad von Architekturkompetenz nimmt Top-Down (Bund > Land > Kommune > IT Strukturen innerhalb Kommunen) ab. Dementsprechend: in Umsetzung von Architekturen nach gängigen Architekturframeworks wird nicht durchgehend standardisiert umgesetzt. Insbesondere auch bedingt durch verteilte Verantwortlichkeiten.

Fehlendes Wissen der umzusetzenden Stellen um die Richtlinien. Folge: Oftmals wird das Rad (Richtlinienerarbeitung) mehrfach erfunden.

Auf kommunaler Ebene keine bindenden Regelungen.

Ist-Architektur oftmals nicht durchgängig bekannt.

Notwendige technologische Implementierung findet im „Anflanschen“ neuer Dienste/Schnittstellen/Tools statt.

Interne IT-Abteilungen sind mit dem Aufrechterhalten des laufenden Betriebs voll ausgelastet.

Fehlende IT Projektmanagementressourcen in den Fachabteilungen zur Umsetzung von Projekten, ausgerichtet nach diesen IT-Richtlinien.

E.S - editiert am 10.01.2024

Die Gründe gegen eine Betrachtung sind in unseren Augen als Bitkom vielfältig und bedürfen verschiedener Lösungsansätze:

Die Architekturrichtlinien sind nicht flächendeckend bekannt.

Sie werden nicht von allen mitgetragen und somit nicht akzeptiert oder ihre Erfüllung erfordert die Bereitstellung zusätzlicher Ressourcen.

Sie kollidieren mit anderen Anforderungen oder bereits bestehenden Systemen.

Die Nutzungshürden einer Dokumentation sind zu hoch. Erfahrungen aus umgesetzten Projekten zeigen, dass Architekturrichtlinien in Code übersetzt und offen geteilt werden müssen, um eine breite Akzeptanz und Anwendbarkeit zu fördern.

Die Architekturrichtlinien eignen sich nicht für eine Anwendung in allen Projekten.

Kennen Sie positive Beispiele zur Einhaltung technischer Richtlinien?

Die Idee einer „Produktionsstraße“ für Dienste mit wenigen Feldern und einfache Anwendungsfälle, kann es erlauben schnell neue Online-Dienste zu erzeugen. Dies allerdings oft nur für landeseigene Dienste, bei denen Abstimmungen mit anderen Ländern entfallen und wo für die Anbindung an eigene Systeme bereits Erfahrungswerte existieren. NRW nutzt mit dem Wirtschaftsserviceportal bspw. ein existierendes Framework.

R.W - original vom 20.11.2023

Die AWV fokussiert sich in ihren Anmerkungen zum Konsultationsprozess in erster Linie auf die Anforderungen von Kommunikation und Lösungen zwischen Wirtschaft und Verwaltung.

Aus der praktischen Arbeit zeigt sich, dass technische Standards und Richtlinien maßgeblich das Nebeneinander verschiedener technischer Lösungen sowohl im Betrieb wie auch in der Entwicklung reduzieren und die Wartbarkeit und Wiederverwendbarkeit von vorhandenen Lösungen stark erhöhen. Je nach Anwendungsfall oder Einsatzumgebung kann es aber vorkommen, dass es besser geeignete Lösungen gibt.

S.G - original vom 20.11.2023

Aus Sicht der VISION Consulting GmbH ist die Beachtung der föderalen IT-Architekturrichtlinien grundsätzlich sinnvoll, wenn sichergestellt werden könnte, dass die föderalen Partner die Richtlinien in einer kompatiblen Art und Weise interpretieren und umsetzen. Die Praxis zeigt immer wieder, dass dies genau nicht geschieht. Die föderalen IT-Architekturrichtlinien sollten deshalb einer Validierung unterzogen und erheblich konkretisiert werden. Aktuell lassen sie den Beteiligten zu viele Interpretationsmöglichkeiten. Des Weiteren sollten sie mit der OZG-Rahmenarchitektur abgestimmt und aktiv verbreitet werden. Idealerweise sollten sie in eine zentrale, für alle Beteiligten verpflichtende IT-Architekturrichtlinie umgewandelt werden. Es sollte darüber hinaus eine zentrale Übersicht mit sämtlichen für die Digitalisierung der öffentlichen Verwaltung geltenden Richtlinien erstellt werden, um hier für alle daran Beteiligten einheitliche und klare Informationsbasis zu erhalten.

S.L.B - editiert am 20.11.2023

Grundsätzlich birgt die föderale Betrachtung das Risiko einer unüberschaubaren und schlussendlich nicht mehr einzufangenden Komplexität. Auf der anderen Seite können unkonkrete Richtlinien bzw. Richtlinien mit zu viel Freiraum ebenso dazu führen, dass anstelle einer einheitlichen Architektur eine Sammlung von Insellösungen entstehen.

Die Bundessteuerberaterkammer begrüßt daher grundsätzlich das Vorhandensein von IT-Architekturrichtlinien. Wünschenswert ist die Abstimmung nicht nur auf föderaler, sondern auch auf Bundesebene, sodass es nicht zu einer Fragmentierung unterschiedlicher Richtlinien oder gar Widersprüchen zwischen den Richtlinien kommt. Die aktuell vorliegenden föderalen IT-Architekturrichtlinien greifen auf ein Architekturframework (TOGAF) zurück, was grundsätzlich sehr zu begrüßen ist. Wichtig ist, dass die für TOGAF definierten Ziele gemeinsam abgestimmt und eine sinnvolle Gewichtung erhalten.

Beispiele für erfolgreich realisierte technische Richtlinien, insbesondere definiert durch das BSI, sind zahlreich. Zu nennen sei die erfolgreiche Realisierung von eID-Servern nach der BSI TR-03130.

SEITENBAU - original vom 20.11.2023

Grundsätzlich können wir uns folgende Gründe vorstellen, weswegen die Richtlinien möglicherweise nicht beachtet werden.

Allgemein - Bekanntheitsgrad: Ein Auftraggeber der öffentlichen Verwaltung und sein Auftragnehmer beachten die Architekturrichtlinie nicht, weil sie diese nicht kennen oder die Relevanz nicht ihren Konzeptionen zuordnen können. - Ungünstige Ausgangslage: Eine Entscheidung, die im Widerspruch zu den Architektur-Richtlinien steht, wurde bereits vor Veröffentlichung der Richtlinien gefällt und kann nicht ohne Weiteres oder in absehbarer Frist korrigiert werden.

Für nachstehende Richtlinien können wir uns folgende Gründe vorstellen, weswegen diese möglicherweise nicht beachtet werden.

Verwendung von Standards - Ein Standard ist zu umfangreich und aufwendig für einen Anwendungsfall. Eine Berücksichtigung erscheint erst mal nicht wirtschaftlich. - Ein Standard ist zu generisch, umfasst kritische Aspekte für einen Anwendungsfall nicht und würde eine Entwicklung blockieren - Ein passender Standard ist jünger als eine existierende oder weit fortgeschrittene Lösung. Eine Umstellung ist nicht wirtschaftlich oder würde andere Entwicklungen blockieren.

Sicherstellung von Wiederverwendung - Geeignete, wiederverwendbare Lösungen stehen zum Zeitpunkt der Entwicklung noch nicht oder nicht im notwendigen Maße zur Verfügung. - Die Identifikation einer geeigneten Lösung gestaltet sich schwierig, da diese nicht an den einschlägigen Orten (z.B. Marktplatz, GovDigital) hinterlegt sind oder anhand der gegeben Informationen nicht als relevant identifiziert werden können.

Sicherstellung der Herstellerunabhängigkeit - Durch bestehende Lizenzen wurde bereits eine Abhängigkeit zu einem Dienst bzw. dessen Hersteller eingegangen, die sich schwer ablösen lässt. - Eine Lösung mit Herstellerabhängigkeit bietet bzgl. kurzfristiger Einsatzmöglichkeiten oder anderer Aspekte (Funktionsumfang, begleitende Angebote) ein (scheinbar) besseres Angebot.

Gewährleistung einer umweltfreundlichen und nachhaltigen Nutzung von Informationstechnik - Herleitungen und Berechnungen könnten sich insb. bei komplexeren Systemen als nicht trivial herausstellen.

Umsetzung des „Once Only“ Prinzips - Voraussetzungen (vgl. Registermodernisierung) sind noch nicht geschaffen

Open Data by Design - Bei limitierten Ressourcen, könnten Anforderungen in diesem Bereich als weniger wichtig eingestuft und nicht oder erst nachträglich umgesetzt werden.

E.H - editiert am 27.01.2024

Antwort von Bundesamt für Migration und Flüchtlinge (BAMF):

Im Rahmen der Richtlinien wird in SR9 auf XÖV verwiesen. Der XÖV-Standard vereint Semantik und Struktur und erfordert einen umfangreichen Standardisierungsprozess für jeden einzelnen Datensatz, dessen zeitliche Dauer sich negativ auf die Agilität bei der Einführung neuer Dienste auswirkt. Eine empfohlene Vorgehensweise wäre die Definition eines semantischen Katalogs für jedes Attribut und die Anwendung neuer Technologiestandards wie OWL/XML, TRURLE, JSON-LD. In diesem Zusammenhang wäre XÖV nicht obsolet, sondern könnte als semantisches Repository weiterhin dienen. Mit diesem verbreiteten Ansatz, könnte jeder Diensteanbieter in seiner Dienstbeschreibung auf die individuellen Taxonomien verweisen, die unter anderem auch in der Europäischen Union standardisiert sind.

F.K - editiert am 28.11.2023

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen:

An deutschen Hochschulen existieren bereits fertige Fachanwendungen, z.B. in Form der Campus Management Systeme. Zu prüfen wäre, inwieweit die Hersteller vertraglich angehalten werden können, sich ebenfalls an die Richtlinie zu halten.

Allerdings könnten Open Source und Herstellerunabhängigkeit im Bereich der Campusmanagementsysteme der Hochschulen schwierig umzusetzen sein, da die Software sehr umfangreich und proprietär ist. Eine Neuentwicklung wäre nicht realisierbar und den Code den Herstellern abzukaufen weder von Herstellerseite gewollt noch finanzierbar.

Im Rahmen der HIS-Genossenschaft lässt ein großer Teil der staatlichen Hochschulen allerdings selbstentwickeln.

T.K - editiert am 27.11.2023

Sammlung CDO-MID Sachsen-Anhalt und Vertreter von Kommunen des Landes:

Zusammengefasste Meldungen: • die strategischen Ziele werden unterstützt

• Es wäre schön, wenn die extreme Abhängigkeit von Fachverfahren angegangen wird

Welche Gründe sprechen Ihrer Meinung nach aktuell gegen eine Beachtung der föderalen IT-Architekturrichtlinien?

• Keine, es sollte schnellstmöglich eine geschaffen werden.

Kennen Sie positive Beispiele zur Einhaltung technischer Richtlinien?

https://docs.fitko.de/arc/policies/foederale-it-architekturrichtlinien/ • Leider nein

AS - original vom 20.11.2023

In der föderalen Umsetzung des OZG sind die Richtlinien weitgehend unbekannt. Bislang lag der Fokus in Umsetzungsprojekten auf bundesweit nachnutzbare EfA-Lösungen – auch im Betrieb. Schnell mussten föderale Lösungen entwickelt werden, EfA-Mindestanforderungen erfüllt und Meilensteine / Steuerungsindikatoren reportet werden. Aus dieser Dynamik heraus, sich immer wieder ändernde Anforderungen, unzulänglichen bzw wenig praxisorientierten Dokumentationen sowie nicht transparenten Weiterentwicklungen von Basiskomponenten, konnten die Projektbeteiligten wenig nach rechts und links schauen. Hinzu kamen länderspezifische Vorgaben von technischen Komponenten und deren Datenformate, Datenflüsse sowie Vorgaben von Datenschutz- und IT-Sicherheitsvorgaben bis in die ministeriale Ebene des Onlinedienstes. Die Richtlinien wurden wenig kommuniziert und Verbindlichkeiten fehlten. Uns ist unklar, wer die Zielgruppe der Richtlinien ist und wie sie in den Prozess der Erstellung/Abstimmung involviert wurden; sind sie für diese Zielgruppe(n) verständlich und praxisorientiert beschrieben?

M.M - original vom 21.11.2023

Prinzipiell begrüßen wir diese Architekturrichtlinien. Sie sollten allerdings angepasst werden * SR5, API-First Ansatz * Grundsätzlich ein sehr sinnvollen Ansatz, aber es gibt dabei Probleme: eine Abstimmung zwischen allen Beteiligten, würde einer Abstimmung zwischen Bund und Bundesländern gleich kommen, auf einem Detailgrad der sehr breit gefächert ist und viel Detailwissen benötigt. Dies hemmt die Geschwindigkeit der Digitalisierung enorm und bedeutet eine große Abschreckung und fördert mehr "inovative" Vorstöße, aka. Insellösungen. * SR4 Security by Default, Privacy by Default: * SR4 hat einen kleineren Scope "by Default" als SR6 "by Design". Sicherheit und vor allem Datenschutz ist aber nicht mit der Konfiguration abgeschlossen. Security by Design ist ein bewährtes Konzept, wird hier aber unnötigerweise auf Security by Default reduziert.

J.P - editiert am 10.01.2024

Antworten Team PwC: - Fehlende Kenntnis und Verbindlichkeit der IT-Architekturrichtlinien - Positive Beispiele zur Einhaltung technischer Richtlinien sind detaillierte Anbindungskonzepte zur Nutzung von EfA-Onlinediensten (explizit wie die techn. Richtlinien eingehalten werden sollen) - Nicht Nutzerorientiert, nicht ausreichend standardisiert - Zielgruppe unklar - Technische Richtlinien sollten mit dem technischen Fortschritt Schritt halten

M.K - original vom 22.11.2023

Antworten des PB-OZG-EU-OOTS der Registermodernisierung

Aus unserer Perspektive sprechen keine allgemeinen Gründe gegen eine Betrachtung der föderalen Architekturrichtlinien. Aus den eigenen Projekterfahrungen wird nur in begründeten Ausnahmefällen von den Richtlinien abgewichen. Festzuhalten ist aber auch, dass Bekanntheit und Verbindlichkeit erhöht werden sollten. Der IT-PLR-Beschluss scheint nicht ausreichend, um eine durchgehende Einhaltung zu visieren. Auch fehlende Sanktionsmöglichkeiten können hier ein Problem darstellen. Es scheint auch, dass politischen Entscheidern die Sinnhaftigkeit oft unklar ist. Daher gilt es vermehrt die positiven Vorteile der föderalen IT-Architekturrichtlinien zu kommunizieren und transparenter zu machen. Als gutes Beispiel können die Umsetzungsprojekte der Registermodernisierung genannt werden. Diese sind aufgrund der Festschreibung der föderalen IT-Architekturrichtlinien in die Abnahmekriterien zur Einhaltung dieser verpflichtet.

M.H - original vom 24.11.2023

Universtität Duisburg-Essen, HISinOne-Cm.nrw: Grundsätzlich spricht aus Sicht der Hochschulen nichts gegen die Beachtung der föderalen IT-Architekturrichtlinien. Im Gegenteil, Richtlinien wie SR1 (Verwendung von Standards), SR3 (bestehende Marktstandards verwenden) und SR12 (Umsetzung des „Once Only“ Prinzips) entsprechen den Interessen der Hochschulen. Wären die Prozesse des Hochschulzugangs und Hochschulabschluss besser berücksichtigt worden, hätte man bestimmte nationale Anwendungsfälle, wie beispielsweise den Datenaustausch mit den Rentenkassen bei der Exmatrikulation, äquivalent zum Studentenmeldeverfahren (SMV) lösen können, als hier den Datenaustausch auf Basis von Embedded PDFs zu realisieren. Außerdem hätte man sich beim Leistungsdatenaustausch auf bestehende Standards stützen können, anstatt neue zu schaffen.

A.M - original vom 27.11.2023

Antworten ekom21 KGRZ Hessen

·       Die Nutzung proprietärer „Verwaltungsstandards“ mit funktionalen Nachteilen im Vergleich zu vergleichbaren etablierten Industriestandards.

·       Höhere Kosten durch zwingende Nutzung von Architekturstandards in der Entwicklung und im Delivery-Prozess und dadurch bedingte Wettbewerbsnachteile durch höhere Preise.

·       Akzeptanzprobleme durch mangelnde Usability von Standards, z.B. in der digitalen Authentisierung.

·       Notwendiger Investitionsschutz der im Rahmen der OZG-Umsetzung bereits entstandener Infrastrukturen.

D.H - original vom 28.11.2023

Wir erwarten, dass im Rahmen des Konsultationsprozesses konkret über aktuelle Entwürfe der bei FITKO vermutlich bereits vorliegenden Architekturrichtlinien und Entwürfe einer OZG-Rahmenarchitektur diskutiert wird.

Wenn Sie möchten, dass der Konsultationsprozess tatsächlich Wirkung entfalten kann, sollten Sie bald entsprechende Entwürfe bereit stellen und nicht nur wie in https://docs.fitko.de/arc/policies/foederale-it-architekturrichtlinien/abbildung-4 auf zukünftige Versionen verweisen.

D.U - editiert am 19.12.2023

Als Materna SE/Infora GmbH verteten wir die Meinung, dass die Architekturrichtlinien eine konsistente und leistungsfähige Basis für die Architekturentwicklung darstellen.

Ihre Anwendung erfordert jedoch ein tiefes Architektur Know how, das häufig in den Behörden nicht ausreichend vorhanden ist und dementsprechend leistungsfähige und speziell ausgebildete Expertise von externen Dienstleistern erfordert.

Tendenziell ist die Richtlinie offen gestaltet und enthält dementsprechend z.T. nicht ausreichend konkrete Vorgaben. Dies führt zu Interpretationsspielräumen und erschwert die einheitliche Umsetzung in verschiedenen Behörden. Andererseits ist der Ansatz trotz der Offenheit nicht nicht immer nahtlos in die unterschiedlichen IT-Landschaften bestimmter Behörden integrierbar. Die Heterogenität der bestehenden Systeme und Infrastrukturen erschwert eine adäquate Anpassung und Integration.

Der Zuschnitt der Architekturbausteine muss daher die Modernisierungsfähigkeit von Altsystemen und ihre Integrierbarkeit in neue Architekturen berücksichtigen.

Ein weiterer zentraler Punkt betrifft die finanziellen Herausforderungen, insbesondere für kleinere Behörden: Die Umsetzung der Richtlinie erfordert möglicherweise erhebliche Investitionen, die für kleinere Organisationen finanziell nicht tragbar sind. Dies könnte zu einer ungleichen Umsetzung der Richtlinie führen und kleinere Behörden benachteiligen.

Zusätzlich stellt sich die Frage nach den personellen Ressourcen. Viele Behörden könnten Schwierigkeiten haben, die erforderlichen Fachkenntnisse und Mitarbeiterkapazitäten bereitzustellen, um die Richtlinie effektiv umzusetzen. Dies könnte zu Verzögerungen und Qualitätsmängeln in der Umsetzung führen.

Das nachträgliche Weiterentwickeln von Lösungen unter Nutzung der neuen Architekturvorgaben muss systematisch angelegt und unterstützt werden: d.h. z.B. Transformationsleitlinien für den schrittweisen Umbau von Altsystemen und deren Integration in aktuelle Gesamtarchitekturen sind erforderlich.

Als positive Beispiele haben wir gute Erfahrungen mit der Entwicklung von "Referenzarchitekturen" gemacht, die die Architekturrichtlinien auf konkrete Klassen von Anwendungsszenarien übersetzen und drauf konkretisieren (z.B. Genehmigungsverfahren). Daher empfehlen wir, diesen Ansatz mit Blick auf eine kleine Anzahl wesentlicher Szenarien zu prüfen, die damit konkreter geleitet werden können.

Einen weiteren wichtigen Aspekt bei der Klassifizierung von Anwendungsszenarien stellen die Anforderungen an Datenschutz und IT-Sicherheit dar. Hier ist einerseits ein Mindestniveau zu definieren (übergreifend auf Ebene der OZG-Rahmenarchitektur), andererseits können höhere oder spezifische Anforderungen für dedizierte Referenzarchitekturen berücksichtigt werden.

Um Architekturvorgaben zu nachhaltiger Wirkung zu bringen, haben wir gute Erfahrung damit gemacht, von Beginn an eine Governance inkl. Monitoring anhand der Praxiserfahrungen einzurichten. So wird einerseits die Nutzung gefördert und gleichzeitig werden Korrekturen angestoßen, wenn wichtige Aspekte sich in der Praxis nicht bewähren oder nicht anwendbar sind.

K.G - original vom 07.12.2023

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister:

Gegen die Beachtung der föderalen IT-Architekturrichtlinie könnten sein: - Kosten bzw. finanzielle Engpässe in den kommunalen Haushalten: Die Umsetzung der förderalten IT-Architekturrichtlinien kann mit erheblichen Kosten verbunden sein, insbesondere dann, wenn bereits vorhandene Systeme und Infrastrukturen (Softwarelizenzen, Softwarepflege, Hardwarebeschaffung und externe Dienstleistungen) angepasst, ersetzt oder konsolidiert werden müssen. - Komplexität: Die Einhaltung der Richtlinien erfordert möglicherweise komplexe Änderungen an bestehenden Systemen und Infrastrukturen, was zu zusätzlicher Komplexität und Arbeitsbelastung führen kann. - Zeit: Es kann sein, dass die Einhaltung der Richtlinien sehr zeitaufwendig sind und dadurch Problem entstehen können. Es müssen zeitliche Freiräume für die sachlich richtige Abweichung von Richtlinien möglich sein. - Synchronizität/Asynchronizität: Bezüglich SR 10 (https://docs.fitko.de/arc/policies/foederale-it-architekturrichtlinien/sr10): Es fehlt der Aspekt der synchronen bzw. asynchronen Kommunikation: In allen bekannten Architekturen scheinen die Ersteller davon auszugehen, dass jeder Dienst zu jeder Zeit verfügbar ist und auch genutzt werden kann. Einfache Wahrscheinlichkeitsrechnungen zeigen, dass, je mehr Komponenten zeitgleich verfügbar sein müssen, desto wahrscheinlicher es ist, dass das komplette System ausfallen wird/könnte. Praxisbeispiel: Once-Only-Prinzip aus der Registermodernisierung. Wenn in einem Formular eine Information aus einer Drittquelle benötigt wird, z.B. liegen Einträge im polizeilichen Führungszeugnis vor, so wird vom Formular die Personen mit ihren Wohnortdaten abgeglichen. Dafür muss zuerst herausgefunden werden, welches Register im zentralen Registerdienst zuständig ist. Dann wird das Register des Meldedatenabgleiches ermittelt. Vom Wohnort aus ergibt sich die nächste Frage: Welche registerführende Stelle ist liefert das polizeiliche Führungszeugnis. Dann geht die Anfrage dorthin: Zusammen vier Kommunikationsaufrufe zu mindestens drei verschiedenen Servern. Jeder Server kann temporär nicht verfügbar sein. Alternative: Formular nimmt die Eingaben entgegen und vertagt die Abfrage der Register auf einen späteren Zeitpunkt (nach der Einreichung des Antrags). Wenn einer der Dienste nicht sofort verfügbar ist, wird er später befragt und dann geht die nächste Frage für die Folgeauskunft los. Der Bürger hat früh das Formular abschließen können, die Nachverarbeitung findet fehlertoleranter später statt. - Annahme einer „Pflicht zur synchronen Verarbeitung“ scheint vermutlich in der SDG-VO unter Artikel 14 Satz (3) f) „dem Nutzer die Möglichkeit bieten, die von der anfordernden zuständigen Behörde zu verwendenden Nachweisen vorab einzusehen und zu entscheiden, ob er mit dem Austausch von Nachweisen fortfährt oder nicht“ - Synchron muss geschaut werden, welche von den zu erfragenden Nachweisen abgerufen werden und (wenn per DVDV lokalisiert) auch von welcher registerführenden Stelle. Es gibt einige Nachweise wie ein polizeiliches Führungszeugnis etc., die nur von anderen Behörden gelesen werden dürfen. Bei anderen Dingen wie Einkommensnachweisen etc. ist es ein Problem des Datenschutzes, dass ein Nachweis nicht selbst angezeigt wird, da bei vielen Antragsarten keine Hoch-Authentifizierung stattfindet. Daher sollten Nachweise nicht als "echte" Nachweise interpretiert werden dürfen, sondern vielmehr als Aussage, welche Nachweise aus welcher Quelle stammen. Als anderes Beispiel ist die Befüllung von EfA-Formularen mit den Daten einer Kommune (Parametrisierung). Der EfA-Dienst könnte einmal täglich sich die Daten der Kommune von einen Parametrisierungsdienst abholen, nicht jedes Mal, wenn das Formular vom Bürger aufgerufen würde. Dieses technische Postulat würde zwar einige Umsetzung komplizierter machen, die Vorteile überwiegen aber deutlich. - Deswegen sollte, wo es möglich ist, auf eine asynchrone Kommunikation gebaut wird, d.h. Daten werden von A zum Abruf bereitgestellt und B kann, wenn es passt, dort die Daten abrufen.

Kennen Sie positive Beispiele zur Einhaltung technischer Richtlinien? Das Bundesministerium des Innern, für Bau und Heimat hat die föderale IT-Architekturrichtlinie erfolgreich umgesetzt, um die Interoperabilität und den Datenaustausch zwischen den verschiedenen Behörden auf Bundesebene zu verbessern.

G.B - original vom 28.01.2024

Juristischer Rahmen ist normativ und schränkt technische Entwicklung ein Die föderale IT-Richtlinien bezeichnen aktuell das Registermodernisierungsgesetz und somit implizit das Identifikationnummergesetz als normativ. Dies hat zur Folge, dass eine Einhaltung der juristischen Vorgaben erzwingt, dass die zum Einsatz kommenden Lösungen hinter den Möglichkeiten des Stand der Technik zurückbleiben. Wir hoffen, dass dieser Mangel im des geplanten und budgetierten Konsultationsprozesses des BMI zur Registermodernisierung genesen wird.

Fehlende Begrifflichkeiten Bisher existieren keine vereinheitlichende Begriffe, bspw. nach Vorbild der OSI Layer, um eine einheitliche Strukturierung der Lösungen zu ermöglichen. Ein entsprechendes Schichtenmodell, welches sowohl die notwendigen technischen wie auch organisatorischen Anforderungen abbildet. Dies bspw. durch die Unterscheidung von Datenbanken/Registern, Geschäftslogiken und UI respektive API existiert bisher nicht. Dies verhinder eine nachaltige Modularisierung der technischen Lösungen und des Entwurfs der entsprechenden Prozessketten und verkompliziert u.a. das Herstellen von interoperabilität sowie die zukünftige Vernetzung entsprechender Services. Dies verhindert die Weiterentwicklung von Verwaltungsleistungen wie bspw. der Kindergrundsicherung.

Umsetzung der Empfehlungen der IuK Enquettkomission von 1984 Bisher trifft die Kritik der IuK Enquettkomission von 1984 umfassend zu, diese schreibt: " Bislang erfolgte der Einsatz der IuK-Techniken in der öffentlichen Verwaltung in der Hauptsache zum Zweck der Effizienzsteigerung (Rationalisierung des Verwaltugnshandelns). Andere Ziele, die sich an den Bedürfnissen und Interessen der Verwaltungsbediensteten und der Bürger sowie an einer Verbesserung der Qualitäts der Verwaltungsleistung insgesamt orientieren (MItarbeiterzufridenheit, Bürgernähe etc.) wurden zu wenig berücksichtig. Der Einsatz der neuen IuK-Techniken eröffnet in der Verwaltungsorganisation neue Spielräume für die Verwirklichung dieser Ziele (Entspezialisierung, Dezentraliiserung,der Informationstechnologien, räumliche Dezentralisierung, Wiederverknüpfung von einzelnen Teilaufgaben, Bürgernähe), bei gleichzeitiger Steigerung der Verwaltungsqualität und - effizienz. In welcher Weise und in welchem Umfang diese spielräume geneutzt werden können, hängt entscheiden auch von politischen Vorgaben und organisatorischen Zielsetzungen ab." Aktuell bleibt zur prüfen in welchem Rahmen das akutell verabschiedete OZG 2.0 Raum lässt die organisatorischen Zielsetzungen entsprechend zu entwickeln.

PSD2 Richtline Ein positives Beispiel für das Einhalten technischer Richtlinien ist die PSD2 Richtlinie, hier wird durch das nach Schutzbedarf gestaltete Prozessdesign ein für die Nutzer*innen nachvollziehbare Verknüpfung aus im Rahmen der UX erfahrbarern Aufwänden, bspw. durch 2 Faktor Authentifizierung und den bestehenden Risiken geschaffen.

OWASP Kriterien Die vom Open Web Application Security Project erhoeben Richtlinien für IT-Sicherheit von Webanwendungen zeigen mit ihrem datengestützen Ansatz auf wie entsprechende Maßnahmen nachvollziehbar gemacht werden können.

02. Technische und organisatorische Herausforderungen

Datum der Veröffentlichung: 25.10.2023
Anzahl eingegangener Antworten: 44
Issue # in GitLab: #138
Leitfrage 02

Was sind die aktuellen konkreten technischen und organisatorischen Herausforderungen der OZG-Umsetzung denen mit einem gemeinsamen Zielbild der OZG-Rahmenarchitektur begegnet werden kann?

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

M.P - editiert am 09.11.2023

Was sind die aktuellen konkreten technischen und organisatorischen Herausforderungen der OZG-Umsetzung denen mit einem gemeinsamen Zielbild der OZG-Rahmenarchitektur begegnet werden kann?

Einige der organisatorischen Herausforderungen im Rahmen der OZG-Umsetzung umfassen:

1.     Eine erfolgreiche Umsetzung des OZG erfordert eine enge Zusammenarbeit zwischen den verschiedenen Behörden auf Bundes-, Landes- und kommunaler Ebene. Die Einführung effektiver Governance-Strukturen gewährleistet eine reibungslose Zusammenarbeit aller Beteiligten.

2.     Eine wesentliche Aufgabe besteht darin, Change-Management-Prozesse zu etablieren, um die Akzeptanz und die Bereitschaft zur Veränderung bei den Mitarbeitern zu fördern.

3.     Für eine effiziente Umsetzung der OZG-Anforderungen ist es unerlässlich, klare Verantwortlichkeiten und Zuständigkeiten für die Verwaltungsprozesse zu definieren.

4.     Die Bereitstellung von horizontalen Diensten, die von mehreren Behörden genutzt werden, erfordert eine transparente Nutzung und klare Regelungen zur Kostenverteilung.

5.     Ein strukturierter Veränderungsprozess ist notwendig, um sicherzustellen, dass die erforderlichen Änderungen systematisch und gezielt umgesetzt werden.

6.     Die Nutzung der Vorteile agiler Entwicklungsmethoden und die entsprechende Anpassung der Arbeitsweisen können dazu beitragen, flexible und effiziente Lösungen zu entwickeln.

7.     Finanzierung von agilen Entwicklungen benötigen agile Finanzierungsmethoden, in denen Projektteams langfristig finanziert werden und eigenständige, passgenaue Produktentscheidungen treffen können.

Einige der aktuellen konkreten technischen Herausforderungen sind:

1.     Um einen nahtlosen Onlinezugang zu ermöglichen, müssen die verschiedenen IT-Systeme der Behörden miteinander kommunizieren und Daten austauschen können. Dies erfordert die Definition einheitlicher Schnittstellen und Standards.

2.     Der Online-Zugang zu sensiblen Daten erfordert eine hohe Sicherheit. Es ist wichtig, geeignete Sicherheitsmaßnahmen wie Authentifizierung, Verschlüsselung und Zugriffskontrolle zu implementieren.

3.     Die IT-Infrastruktur muss in der Lage sein, die steigende Anzahl an Nutzern und Anfragen zu bewältigen. Skalierbare Lösungen wie Cloud-Computing können dabei helfen, eine flexible und leistungsfähige Infrastruktur bereitzustellen.

4.     Um einen effizienten und zuverlässigen digitalen Prozess zu gewährleisten, müssen die Daten in den IT-Systemen der Behörden von hoher Qualität sein. Es ist wichtig, Prozesse zu etablieren, um die Datenqualität sicherzustellen und sicherzustellen, dass die Daten korrekt und vollständig sind.

5.     Eine weitere Herausforderung besteht darin, Legacy-Systeme in die neue Zielarchitektur zu integrieren, um eine reibungslose Datenkommunikation sicherzustellen.

6.     Die unterschiedlichen Datenformate und -strukturen, die in verschiedenen Behörden verwendet werden, müssen durch eine einheitliche Datenstandardisierung harmonisiert werden, um einen effizienten Austausch von Informationen zu ermöglichen..

7.     Der Schutz sensibler Daten ist von entscheidender Bedeutung. Es ist erforderlich, Sicherheitsmaßnahmen, Datenschutzrichtlinien und -vorschriften einzuhalten, um die Vertraulichkeit und Integrität der Daten zu gewährleisten.

8.     Um eine breite Nutzung und einen inklusiven Zugang zu ermöglichen, müssen die Online-Services benutzerfreundlich gestaltet sein und barrierefreie Zugangsmöglichkeiten bieten.

Ein gemeinsames Zielbild der OZG-Rahmenarchitektur bietet eine professionelle Lösung zur Bewältigung dieser technischen und organisatorischen Herausforderungen. Es schafft eine einheitliche Ausrichtung und einen gemeinsamen Rahmen für die Umsetzung.

Cisco-Issue2-V2

S.M - original vom 03.11.2023

Bundesagentur für Arbeit: Siehe u.a. Antworten zu Frage 1.

Aktuelle Herausforderungen: Es gibt bundesweit mehrere etablierte Fachportale mit dazugehörigen Nutzerkonten. Diese zu einem Nutzerkonto zusammenzuführen wird als Herausforderung angesehen. Zudem ist das bestehende Nutzerkonto des Bundes (BUND ID) nicht für Drittstaatler zugänglich.

Prozessgebundene Identifizierung/Authentifizierung ist in der Bevölkerung nicht bekannt / etabliert.

Im Bereich des Organisationskonto für Unternehmen gibt es noch keine ausreichende Ausgestaltung. Weder im Bereich der grundsätzlichen Nutzung des Kontos sowie der Anmeldemöglichkeiten gibt es bisher ausgereifte Konzepte.

M.S - editiert am 28.11.2023

Open Source Business Alliance – Bundesverband für digitale Souveränität e.V.:

Obgleich Open Source Software und offene Standards in etlichen Beschlüssen und Papieren zum OZG als zentraler Schlüssel zum Erfolg benannt werden, hängt die Umsetzung in der Praxis immer noch hinterher (siehe u.a. Grundprinzipien des OZG-Konjunkturprogramms https://www.digitale-verwaltung.de/Webs/DV/DE/onlinezugangsgesetz/ozg-grundlagen/ozg-konjunkturprogramm/konjunturprogramm-node.htmldoc20338150bodyText2 oder der OZG-Servicestandard https://www.digitale-verwaltung.de/Webs/DV/DE/onlinezugangsgesetz/servicestandard/servicestandard-node.html sowie die föderale IT-Architektur).

Ohne den konsequenten und flächendeckenden Einsatz von Open Source Software und offenen Standards ist der Erfolg der OZG-Umsetzung und die schnelle, effiziente und nachhaltige Verwaltungsdigitalisierung in Gefahr. Das Einer-für-Alle-Prinzip und eine wirklich effiziente Nachnutzung von Softwarelösungen funktionieren nur mit Open Source Software und offenen Standards.

In vielen Verwaltungen bestehen mit Blick auf die IT-Architektur historisch gewachsene Strukturen und damit auch historisch gewachsene Abhängigkeiten von einzelnen IT-Anbietern oder Softwarelösungen. Vielerorts besteht der Wunsch nach grundlegenderen Infrastrukturänderungen, nach einer Reduzierung von Abhängigkeiten und Kompatibilitätsproblemen sowie nach Software, die easy-to-use und benutzerspezifisch anpassbar ist. Einige Länder und Kommunen haben sich bereits auf den Weg gemacht, andere wissen z.T. nicht, wo und wie sie anfangen sollen.

Das Zielbild für die OZG-Rahmenarchitektur muss den Verwaltungen technisch und organisatorisch Hilfestellungen und Möglichkeiten anbieten, diese grundlegenderen Infrastrukturänderungen vorzunehmen und auf einen flächendeckenden Einsatz von Open Source Software und offenen Standards umzustellen. Die in der Antwort auf Leitfrage 1 genannten Aspekte „Open Source Software als Standard“, „Offene Standards“, „Referenzimplementierungen“, „Offene Zusammenarbeit“ und „Transparenz und Auditierbarkeit“ sind zentrale Aspekte um diese technischen und organisatorischen Herausforderungen zu adressieren.

A.S - editiert am 28.11.2023

Was sind die aktuellen konkreten technischen und organisatorischen Herausforderungen der OZG-Umsetzung denen mit einem gemeinsamen Zielbild der OZG-Rahmenarchitektur begegnet werden kann?

Technische Herausforderungen

Loslösen von bestehenden, aber stark veralteten technischen Infrastrukturen (bspw. OSCI vs. FIT-Connect)

Lösungen für Integration von Fachanwendungen anbieten

Low-Code/No-Code Integration fördern

fehlende einheitliche Paymentinfrastruktur mit zentralem Gebührenregister

Integration von Fachanwendungen (bspw. Payment E-Akte)

gezielter Einsatz von Open-Source-Komponenten da, wo diese sich auch Lohnen bspw. KI-System im OZG-Kontext etc.

Organisatorische Herausforderungen

ganzheitliche Betrachtung der digitalen Transformation in den Behörden

Weitergabe von Softwareartefakten

Festlegung, Nutzung und Verbreitung von Protokoll und Datenstandards

Abstimmung

Empfehlungen für Ausschreibungen hinsichtlich notwendiger offener Schnittstellen (für die Erleichterung der Integration in bestehende Infrastrukturen in den Behörden)

D.H - editiert am 28.11.2023

Ja. OSCI ist beim besten Willen nicht mehr zeitgemäß und sollte deshalb am besten abgelöst oder zumindest von modernen und offenen E-Government-Diensten "weggekapselt" werden.

T.B - original vom 14.11.2023

Technische Herausforderungen: - Unterschiedliche, technische Voraussetzungen, Ausgestaltungen und Know-how in den Bundesländern - Fehlende Funktionalitäten führen zu Brückenlösungen und verhindern eine "Verschlankung" der IT-Systemlandschaft (bspw. werden Routing- und "Durchlauf-"komponenten eingesetzt, da viele Systeme eine Anbindung an XTA nicht bewerkstelligen können) - Fehlende Rückkanäle: Die wenigsten Dienste/Komponenten können aktuell wirklich einen funktionierenden Rückkanal bereitstellen - Vielzahl an unterschiedlichen Fachverfahren und -systemen führen zu immensen Kosten, Aufwänden und zeitlichen Verzögerungen (Bereitstellung von Open-Source-Lösungen könnte zukünftig dies minimieren) - Interoperabilität ist weiterhin nicht gegeben - IT-Security und sicherheitsrelevante Aspekte sind oft nicht im gesamten Prozessverlauf und den dazugehörigen IT-Komponenten berücksichtigt - oft wird ein "Einfallstor" offen gelassen

Organisatorische Herausforderungen: - Abhängigkeit von einzelnen Organisationen zur Unterstützung beim Aufbau technischer Lösungen (bspw. ComDespina) - IT-Governance: Es sollte zu Zentralisierungseffekten und nicht zu immer mehr Brücken- und Insellösungen führen

M.N.AKDB - editiert am 28.11.2023

Die wichtigste technische wie organisatorische Herausforderung ist effiziente Organisation und Etablierung von geeigneten technischen Standards (Schnittstellen, Protokolle, Datenschemata). Diese zahlen unmittelbar positiv auf die überlagernde technische Herausforderung der Integration der OZG-System- und Infrastrukturkomponenten ein. Die Integration von Daten, Systemen, Infrastrukturen und Plattformen im föderalen, nationalen, supra-nationalen sowie internationalen Kontext ist die größte Herausforderung für eine gelingende Verwaltungsdigitalisierung.

D.T.OZG.S - editiert am 17.11.2023

Was sind die aktuellen konkreten technischen und organisatorischen Herausforderungen der OZG-Umsetzung denen mit einem gemeinsamen Zielbild der OZG-Rahmenarchitektur begegnet werden kann?

Die Digitalisierung der föderalen Verwaltung Deutschlands muss gemeinsam von Bund, Ländern, Kommunen und weiteren Trägern der öffentlichen Verwaltungen vorangetrieben werden. Das Zielbild der OZG-Rahmenarchitektur sollte dazu dienen die flächendeckende und medienbruchfreie Ende-zu-Ende Umsetzung und damit die Digitalisierung der deutschen Verwaltung zu beschleunigen.

Aus den OZG-Projekterfahrungen der Deutschen Telekom sowie deren Töchter lassen sich folgende technische und organisatorische Herausforderungen ableiten, denen mit einem gemeinsamen Zielbild der OZG-Rahmenarchitektur begegnet werden kann. Außerdem regen wir an, dass die OZG-Rahmenarchitektur mit weiteren Querschnittsthemen, insbesondere „Beyond EU Digital Identity Wallet“, bearbeitet wird.

Nachstehenden organisatorischen Herausforderungen kann eine OZG-Rahmenarchitektur im Sinne eines EAM (bspw. nach TOGAF) begegnen. Maßgeblich für eine wirksame Etablierung eines Architekturmanagements sind die Definition von Architekturprinzipien und Standards, die Analyse des Status Quo, die Entwicklung eines Zielbilds sowie die Gestaltung eines Transformationspfads und Institutionalisierung einer Architektur Governance.

Organisationsübergreifende Adaption von Good / Best Practice für Betriebs- und Supportprozesse bzw. deren Optimierung (ITIL, DevOps-Prinzipien)

Ausrichtung der Weiterentwicklung der Architektur anhand der Bedarfe von Nutzer:innen und wertschöpfenden Prozessen

Management einer zentral verantworteten und gemeinsam getragenen Migrationsplanung der priorisierten Einzelvorhaben, die erforderlich sind, um das Zielbild zu erreichen

Kulturwandel von klassischen zu agilen Projektmanagementmethoden

Schulung, Weiterbildung, Onboarding von Mitarbeiter:innen in Verwaltungen (und ggf. externen Mitarbeiter:innen von unterstützenden Dienstleistern)

Identifikation zukünftiger Handlungsfelder und Umsetzungsbedarfe, bspw. Schaffung eines rechtssicheren Rahmens für den Einsatz von KI

Steigerung der Innovationsfähigkeit und Reaktionsfähigkeit auf äußere Einflüsse

Beschleunigung und Optimierung von Vergabeverfahren, bspw. durch Bereitstellung von standardisierten (Leistungs-)Beschreibungen der Architektur-/Lösungsbausteine

Etablierung einer neuen Zusammenarbeitskultur zwischen Verwaltung und externen Dienstleistern (OZG-Rahmenarchitektur bildet ein gemeinsames Zielbild)

Daneben kann die OZG-Rahmenarchitektur mithilfe von Prinzipien, Standards und Architekturbausteinen einen Lösungsansatz für bestehende technische Herausforderungen darstellen. Die Definition der OZG-Rahmenarchitektur muss unter Anwendung von Architektur- und Lösungsbausteinen erfolgen. Die Bausteine müssen lose miteinander gekoppelt und modular aufgebaut sein; damit kann eine Lösung auf Grundlage der Rahmenarchitektur orchestriert und andererseits eine Weiterentwicklung der einzelnen Module ermöglicht werden.

Definition und Etablierung konkreter Maßgaben für Funktionsweisen von Bausteinen, beispielsweise zur Umsetzung von Datenschutzzielen mit neuen Methoden (Zero-Knowledge Proof, Selective Disclosure)

Beschleunigung in der Erstellung und Bereitstellung von Onlinediensten durch automatisierte Übernahme von FIM-Artefakten oder Etablierung von LowCode-Plattformen

Etablierung von Systemen zur Unterstützung von Attraktivitätssteigerungen für Nutzer:innen und zur Reduzierung des Verwaltungsaufwands (AI/-Chatbot)

Optimierung des Identitäts- und Zugriffsmanagements unter Berücksichtigung von eIDAS und DSGVO (ID-Wallets)

Entwicklung eines Zielbilds für eine Ende-zu-Ende Digitalisierung durch Definition und Umsetzung von Workflowsystemen

Schaffung eines professionellen Schnittstellenmanagements (Enterprise-Service-Bus, API-Gateway) zur Unterstützung der schnelleren Bereitstellung von Standards für den Datenaustausch

Erweiterung der Datenaustauschstandards um moderne Techniken (JSON-LD)

Etablierung eines Baustein- und Schnittstellenorientierten Architektur zur Vermeidung von Vendor-Lockins und gleichzeitiger Partizipationsmöglichkeit an Innovationskraft der IT-Wirtschaft

Definition und Etablierung eines einheitlichen Technologie-Layers (für souveräne und sichere Cloud- und Betriebsstandards, Standardsoftware und Schnittstellen

Frage02_OZGRahmenArchitektur_Konsultationsprozess

P.S - original vom 17.11.2023

Es existieren zahlreiche organisatorische und technische Herausforderungen der OZG-Umsetzung, von denen wir folgende hervorheben möchten:

Organisatorische / Rechtliche Herausforderungen:

Unterschiedliche finanzielle Rahmenbedingungen: Beim Entwurf der OZG-Rahmenarchitektur muss die unterschiedliche finanzielle Ausstattung der umsetzenden Behörden berücksichtigt werden. Die Frage „Und wer bezahlt das?“ ist häufig ein Showstopper innovativer Lösungen.

Unterschiedliche personelle Rahmenbedingungen: Der Umfang des vorhandenen Fachwissens und der Ressourcen ist in den einzelnen Behörden sehr unterschiedlich ausgeprägt. Einfache Lösungen haben eine höhere Erfolgschance.

Vielzahl an Entscheidungsorganen und langwierige Entscheidungsprozesse: Durch die meist notwendige Beteiligung einer Vielzahl an Organen ist die Entscheidungsfindung meist nicht in der notwendigen Geschwindigkeit und Verbindlichkeit möglich.

Auslegungen des Datenschutzes: Aspekte des Datenschutzes werden teils sehr unterschiedlich ausgelegt, wodurch – trotz gleicher Anforderungen – inkompatible Lösungen entstehen.

Technische Herausforderungen:

Heterogene, unzureichende IT- und Netzinfrastruktur: Insbesondere die im IT-NetzG geforderte Anbindung an sichere Netze ist häufig nicht in ausreichendem Umfang gegeben.

Unterschiedliche Schutzbedarfe: Die unterschiedlichen Verwaltungsleistungen unterliegen unterschiedlichen Schutzbedarfen, die miteinander interagieren müssen.

D.K - editiert am 20.11.2023

Technisch muss bei der Öffentlichen Verwaltung zwingend der Einsatz von Open Source Software vorgeschrieben werden. Derzeit ist die Rechtslage noch nicht konkret genug und bietet zu viel Interpretationsspielraum, diesen Einsatz zu umgehen. Die OZG-Umsetzung wird nur gelingen, wenn Herstellerunabhängig leicht anpassbare und offene Software für die Verwaltung zum Einsatz kommt. Organisatorisch benötigt die Verwaltung einen Kulturwandel. Die Öffentliche Verwaltung muss den Mut voranzugehen und notfalls auch erstmal mit Lösungen, die zu 80 % ausgearbeitet sind und durch offene Quellecodes und offene Standards aber eine zügige Weiterentwicklung und Anpassbarkeit hin zu den 100 % bieten. Ebenfalls benötigen die Verwaltungsbeschäftigten – von der Entscheidungs- bis zur ausführenden Ebene – die nötige Rückendeckung und eine entsprechend gute Fehlerkultur. Erst wenn ausprobiert wird, kann es auch eine Weiterentwicklung geben.

Das gemeinsame Zielbild der OZG-Rahmenarchitektur sollte der Verwaltung die notwendige Sicherheit und das Aufzeigen eines Weges hin zu einem Wandel bieten. Es kann die Grundlage für eine effiziente und gut funktionierende Zusammenarbeit zwischen den verschiedenen Ebenen der Verwaltung, wie auch der Verwaltung nach außen, geben.

D.S - original vom 19.11.2023

Technisch In einem föderalen Umfeld können die Vorgehensweisen und Best-Practices der meisten anderen Staaten nicht übernommen werden, die zentral organisiert sind. Jede föderale Ebene ist, gerade auch technisch, grundsätzlich selbständig, was deutlich mehr Absprachen und Standards erforderlich macht, als bei einem zentralstaatlichen Ansatz. Es braucht daher eine Standardisierungs-Agenda, welche Teil des Zielbildes sein sollte. Im Bereich der Infrastruktur und Querschnitts-Technologien ist ein Kirchturm-Denken, welches sich noch häufig findet, zu vermeiden. Hier sollte das Zielbild eine gemeinsame Architektur formulieren, die sich jedoch nur auf Querschnitts-Themen beschränken muss, um zu große Widerstände in den föderalen Ebenen zu vermeiden. Organisatorisch Aufgrund des föderalen Staatsaufbaus, ist bei übergreifenden Festlegungen ein Konsens zu erzielen , da Widerstände von beteiligten Akteuren gegen getroffene Festlegungen Prozesse verlangsamen und zum Stillstand bringen können. Dies gilt gerade auch in Fällen, in welchen eine gesetzliche Grundlage eine verbindliche Vorgabe des Bundes ermöglichen würde. Das Zielbild muss daher organisatorisch Wege aufzeigen, wie und an welchen Stellen alle relevanten Akteure mitgenommen werden. Der Weg über die Erschaffung von Standards wäre für das Zielbild ein guter Weg, weil die Prozesse zur Standardisierung allgemein akzeptiert und deren Ergebnisse anerkannt sind. Standards entfalten darüber hinaus Druck und Wirksamkeit abseits politischer Bühnen und gewährleisten ein Fortkommen unabhängig von Wahlen und politischen Konstellationen, sowie eine über lange Zeit angelegte Kontinuität. Dennoch lassen sie sich an neue technische Entwicklungen anpassen und sind daher nicht so statisch wie Gesetze oder Verordnungen.

B.R - original vom 20.11.2023

Der Föderalismus stellt für die Digitalisierung mit Standards und einheitlichen Lösungen eine große Herausforderung dar (z.B. Ländereigene Seiten, Plattformen, Daten über Ländergrenzen bereitstellen). Damit verbunden fehlt eine gesamtbundeseinheitliche Planung. So stellen wir vermehrt fest, dass es eine Vielzahl von verschiedenen Online-Anträgen zu ein und derselben Leistung gibt (in BW: Standardprozess, UNIP, UNIP+ und nun auch verstärkt EfA-Leistungen). Es fehlen klare Zuständigkeiten und Verantwortungen (Bund, Länder) und eine klare einheitliche Kommunikation. Man muss sich als Behörde immer auf Basis einer schlechten Informationslage entscheiden, ob man besser warten oder umsetzen soll und auf was man eigentlich wartet.

Ein Schritt in die richtige Richtung sind sicherlich die EfA-Lösungen, aber auch hier besteht die Gefahr, dass zunehmend ein „Flickenteppich“ an EfA-Lösungen mit ggf. unterschiedlichen Standards entsteht. Dies kann die Akzeptanz von Lösungen schädigen, insbesondere wenn für verschiedene Leistungen, verschiedene Zugangsportale mit verschiedenen Zugangsdaten erforderlich wären. Bei den einheitlichen Lösungen, die aktuell angeboten werden, setzt man sich teilweise sehr hohe Ziele, die vorher nicht verifiziert sind. Das Ergebnis ist, dass im Projekt festgestellt werden muss, dass nicht alles umsetzbar ist, was versprochen wurde. Damit sinkt das Vertrauen in die angebotenen Lösungen. Außerdem wird dadurch die Entwicklungsdauer zu lange, so dass die Lösungen sich selbst überholen.

Weiterhin und ein oft erwähntes Thema ist die Ressourcenknappheit in Bezug auf Personal und finanzielle Mittel. Bei nachnutzbaren EfA-Lösungen werden Kosten zu Beginn teilweise vom Bund übernommen. Für uns als Behörde fehlt hier teilweise der Planungshorizont, wie/ ob fortlaufende Kosten in Zukunft gedeckt werden. Abschließend sei noch auf die Themen Informationssicherheit, Datenschutz und IT-Sicherheit als Herausforderung hingewiesen.

TSA.S.W - original vom 20.11.2023

Eine konkrete organisatorische Herausforderung im Kontext der Umsetzung des OZG für uns als TSA Public Service GmbH ist vor allem die fehlende Einbindung von Kommunen und ihrer Dienstleister.

Dies ist zum Teil durch die Top-Down-Digitalisierung begründet, die mit den gegebenen föderalen Strukturen an ihre Grenzen stößt. Hier fehlt an manchen Stellen die Augenhöhe zwischen den verschiedenen föderalen Ebenen.

Auf technischer Seite fehlt es an der verbindlichen Nutzung öffentlicher Standards, deren Nutzung über eine Rahmenarchitektur festgelegt und dann in der Praxis umgesetzt werden kann.

J.E - original vom 20.11.2023

Die föderale Verwaltung Deutschlands als System ist komplex und dadurch schwer steuerbar: Es gibt „unzählige“ Verwaltungsleistungen an denen 1000nde von Behörden beteiligt sind, die miteinander ggf. über drei föderale Ebenen hinweg interagieren. Daneben fehlt es an fachlich kompetentem Personal und an einfachen Möglichkeiten zu kooperieren. Es gibt keine übergreifenden Standards für die Umsetzung der Digitalisierung und keine gemeinsamen "Zielbilder". In der Phase 1 der OZG-Umsetzung führte das zu ineffizientem Vorgehen oder gar gegenseitigem Behindern. Auch gibt es innerhalb der Verwaltung scheinbar an vielen Stellen wenig Offenheit oder Unverständnis für die Neugestaltung der Prozesse unter Nutzung der Möglichkeiten der Digitalisierung. So wurden die Ziele der OZG-Umsetzung bis Ende 2022 weit verfehlt.

Neben dem möglichen Effizienzgewinn durch Umsetzung von EfA und die Entwicklung einer einheitlichen Plattform für die Verwaltungsdigitalisierung mit der Deutschen Verwaltungscloud, können wesentliche Erfolgsfaktoren für die Beschleunigung der Verwaltungsdigitalisierung in einer Standardisierung der Prozesse, Methoden und Technik liegen. Um eine Nachnutzbarkeit der Online-Dienste zu erreichen, müssen diese portier- und integrierbar, auf Basis von Standards entwickelt werden und definierten Architekturprinzipien bzw. Architekturmustern folgen. Ein abgestimmtes gemeinsames "Zielbild" kann dazu einen wesentlichen Beitrag leisten.

S.H - original vom 20.11.2023

Aus kommunaler Sicht, Großstadt 750.000 Einw.:

Technologisch:

Teilweise unklare technische (laufende und zukünftige) Schnittstellen, die genutzt werden

Kein Architekturmanagementskills im Sinne standardisierter Frameworks wie TOGAF/ADM weder intern, noch mit zuliefernden IT-Dienstleistern

Fragmentierung in der Umsetzung durch Vielzahl an Tools mangels Anwenderbasierten (low code/no code) Werkzeugkasten

Unklare elementare Sub-Dienste werden schon abgebildet und tollseitig weiterentwickelt. Bspw. wie sieht DER Epaymentprozess durchgängig aus? Ziel: klar definieren!

Technische Schulden werden aus Ressourcengründen nicht abgebaut und werden durchgeschleift

Organisatorisch:

Begrenzte Ressourcen zur Umsetzung in Projekten.

Für komplexe Prozesse braucht es mehr Ressourcen

Für einfache Prozesse (Unterstützungsprozesse / OZG zuliefernde) werden aufgrund des Handlungsdrucks Tools als Silos (vorerst ohne E2E Gedanke) etabliert.

Unterschiedliche Prioritätensetzungen der Beteiligten (und Betroffenen) in den Umsetzungen

Sehr viele einzubindende Stakeholder, die zu beachtende Anforderungen einbringen müssen. (weitere Stakeholder und Anforderungssteller der Gremien wie Personalräte, Informations- Datensicherheit, Inklusion, Gleichstellungsbeauftragte, Revision, Fachexperten..)

Keine nach stringenten (agilen) Methoden ausgestattete Projektorientierte, ganzheitliche Umsetzungsteams mit entsprechendem Skillset (digital- / agiles Mindset).

ad- hoc Tools werden aufgrund des Handlungsdrucks aufgebaut, ohne das Gesamtbild und –Standards zu berücksichtigen.

E.S - original vom 20.11.2023

Die Bitkom-Mitgliedsunternehmen sehen verschiedene Herausforderungen, die das Zielbild adressieren kann und sollte:

Organisatorische Herausforderungen und Chancen

Heterogenität der Akteure, involvierten Ebenen und Systeme: Die OZG-Rahmenarchitektur kann dazu beitragen, dass die verschiedenen Interessen und Anforderungen im Entscheidungsprozess berücksichtigt werden. Dies führt zum einen zu einer höheren Akzeptanz und Verbreitung und zum anderen haben die Akteure ein abgestimmtes Leitbild zur Orientierung.

Fehlende Standards: Grundsätzlich ist der Ansatz einer dezentralen Entwicklungsorganisation und der Nachnutzung von entwickelten Leistungen sinnvoll und unterstützenswert. Diese Art der Organisation braucht jedoch nutzbare Standards im Hinblick auf Interoperabilität und Integration. Die Rahmenarchitektur sollte diese Standards unter Einbeziehung von Entwicklern definieren. So bietet sich die Chance, Versäumnisse der Vergangenheit auszubessern. Dazu gehört auch die Entwicklung von Komponenten und Standards für den Bereich UX/UI.

Zu geringer Fokus auf Nutzerinteressen und -reisen: Die OZG-Umsetzung erfolgte bisher auf Ebene der Verwaltungsleistungen nutzendenzentriert, jedoch nicht ganzheitlich im Sinne eines nutzendenzentrierten digitalen Deutschlands (z.B. verschiedene, nicht miteinander verbundene Portale). Hierdurch entfalten die bisherigen Umsetzungen nur eine begrenzte Wirkung. Eine OZG-Rahmenarchitektur trägt diesem Umstand Rechnung, indem von den Nutzenden ausgehend ein Zielbild – ggfs. entlang der bereits existierenden Lebens- und Geschäftslagen – entwickelt und dann mit einem technischen Rahmen unterlegt wird.

Fehlende Anreize zur föderalen Zusammenarbeit (Nachnutzung): Auf Basis einer gemeinsamen Rahmenarchitektur können federführende oder umsetzungsinteressierte Länder schnell ein erstes Zielbild einer digitalen Lösung erarbeiten und eine Umsetzungsplanung anstoßen. Kommunen und Ländern wird es leichter fallen, ihr Nachnutzungsinteresse basierend auf einem ersten, in die gemeinsame Rahmenarchitektur eingebettetes Zielbild zu beurteilen.

Parallelität: Durch die verschiedenen involvierten föderalen Ebenen und die 14 Themenfelder geschehen viele ähnliche Aktivitäten parallel und es stellen sich ähnliche Fragen. Das Zielbild der OZG-Rahmenarchitektur bietet hier großes Orientierungs- und Unterstützungspotential für die Umsetzer.

Anzahl an Vorgaben: Die schiere Anzahl an Dokumenten, Vorgaben und Aufgaben erschwert den Akteuren einen Überblick zu erhalten und führt zu vermehrter Koordinationsarbeit. Eine gemeinsame OZG-Rahmenarchitektur trägt diesem Umstand Rechnung und gibt allen Akteuren einen klaren Rahmen vor, an welchem sie ihre Digitalisierungsbestrebungen ausrichten können. Gerade für beteiligte Personen aus Fachbehörden, welche bisher nicht oder nur wenig mit der Verwaltungsdigitalisierung in Berührung gekommen sind, wird es durch eine gemeinsame Rahmenarchitektur einfacher, sich zurechtzufinden. Auch können sich (kleinere) Kommunen an der Rahmenarchitektur orientieren.

Fokus auf Frontend-Digitalisierung: Der bisherige Fokus auf die Front-End-Digitalisierung führt dazu, dass Prozesse nicht Ende-zu-Ende gedacht und gestaltet werden. Die Rahmenarchitektur hat das Potential, dies zu korrigieren.

Technische Herausforderungen

Geringer Umsetzungsanreiz: Eine gemeinsame OZG-Rahmenarchitektur kann dazu beitragen, dass auch für Verwaltungsleistungen mit geringen Mengengerüsten (digitale) Fachverfahren entwickelt werden. Durch eine gemeinsame OZG-Rahmenarchitektur mit entsprechenden Standards und Schnittstellen reduzieren sich die individuellen Anforderungen von Kommunen und Ländern. Fachverfahren können so flächendeckend eingesetzt werden, wodurch eine entsprechende Wirtschaftlichkeit auch für Verwaltungsleistungen mit geringen Mengengerüsten erreicht werden kann.

Verschiedene Datenaustauschstandards: Für andere Verwaltungsleistungen existiert eine Vielzahl an Fachverfahren, wodurch unterschiedliche Datenaustauschstandards existieren. Eine gemeinsame Rahmenarchitektur trägt dazu bei, diesen Umstand zu reduzieren. Darüber hinaus bietet eine gemeinsame Rahmenarchitektur Anreize für Fachverfahrenshersteller, ihre Systeme entsprechend anzupassen, um auch zukünftig wettbewerbsfähig zu sein. Mit Blick auf die anstehende Registermodernisierung könnte hier eine gemeinsame Rahmenarchitektur einen Anstoß geben, die Fachverfahren rechtzeitig – vor der flächendeckenden Umsetzung des Once-Only-Prinzips – zu ertüchtigen.

Einbindung bestehender Lösungen: Die Einbindung, Integration und Weiterentwicklung von bestehenden und etablierten technischen Lösungen gestalteten sich öfter schwierig. Hier kann die Rahmenarchitektur ebenfalls einen Beitrag leisten.

B.S - original vom 20.11.2023

Aus Sicht der GKV:

Bei der Ausgestaltung der Prozesse drängt sich der Eindruck auf, dass hier nicht alle Verwaltungsleistungen bzw. deren Erbringung berücksichtigt wurden.

Der bisherige Ansatz, dass für eine Verwaltungsleistung immer eine zuständige Stelle besteht, greift bei der GKV zu kurz. Die gesetzlichen Krankenkassen als Körperschaften des öffentlichen Rechts stehen im Wettbewerb zueinander und der Bürger / Versicherte kann in der Regel frei entscheiden, welche Krankenkassen er wählt. Daher gibt es eine Leistung der Krankenkasse zwar grundsätzlich nur einmal, welche Krankenkasse diese für den Bürger erbringt, ist abhängig von der gewählten Krankenkasse. Es ist daher nicht zielführend, wenn z.B. im Bürgerportal eine Leistung nur 1x vorkommt, der Bürger aber anschließend über einen manuellen Prozess die zuständige Krankenkasse wählen muss.

Neben dem Bürger sind auch Unternehmen aus dem In- und Ausland für die Erbringung von Verwaltungsleistungen relevant. Daher müssen die unterschiedlichen Anforderungen dieser Verfahrensteilnehmer zur Authentifizierung und das damit einhergehenden Rollenkonzept ein wesentlicher Bestandteil der OZG-Rahmenarchitektur sein, welcher nicht für jedes Verfahren / jede Verwaltungsleistung neu ausgestaltet werden sollte.

Die OZG Rahmenarchitektur sollte daher alle wesentlichen Anforderungen der teilnehmenden berücksichtigen, um zentrale, wiederverwendbare Komponenten zu ermöglichen.

R.W - original vom 20.11.2023

Die AWV fokussiert sich in ihren Anmerkungen zum Konsultationsprozess in erster Linie auf die Anforderungen von Kommunikation und Lösungen zwischen Wirtschaft und Verwaltung.

Von Bedeutung erscheint uns die Nutzung existierender und zukunftsweisender technischer Standards. Dabei sollten nicht nur verwaltungsinterne technische Lösungen Berücksichtigung finden, sondern auch Lösungen bspw. zwischen Unternehmen und Verwaltungen. Konkret empfehlen wir, existierende Standards wie eXTra (www.extra-standard.de) für den m2m-Datenaustausch zwischen Wirtschaft und Verwaltung einzubinden.

SEITENBAU - original vom 20.11.2023

Unter den sehr vielen Herausforderungen möchten wir als Softwareentwicklungsdienstleister folgende hervorheben:

Schaffung eines einheitlichen Verständnisses über ein Zielbild mit dem die OZG-Umsetzung gemeinsam vorangetrieben werden kann, das einen hohen Bekanntheitsgrad und Akzeptanz hat.

Die Schaffung und Gewährleistung der Kompatibilität und Interoperabilität zwischen Komponenten. Integration von bestehenden, etablierten Lösungen.

Gewährleistung einer ausreichenden Verfügbarkeit: Je mehr zentrale Dienste ein Dienst integriert, desto höher kann die Beeinträchtigung der Verfügbarkeit ausfallen (z.B. durch die Summierung von Wartungsfenstern).

Gewährleistung oder Erlangung der digitalen Souveränität bei den für die OZG-Umsetzung relevanten Systemen und Anwendungen.

Komplexität handhaben, die sich durch die bestehende Vielfalt an Lösungen ergibt: Identifikation geeigneter Lösungen für einen Anwendungsfall.

Konsolidierung und Verbreitung von Standards. Erreichung einer dafür notwendigen Attraktivität.

A.S - original vom 20.11.2023

Aus Sicht der DigitalService GmbH des Bundes:

Aus unserer Recherche zu Basisdiensten und -komponenten haben wir, nach umfangreicher Sekundärforschung und über 45 Interviews, sieben systemische Hürden abgeleitet, die die Verwaltungsdigitalisierung blockieren. In unserer Nutzungreise Basiskomponenten und -dienste wiederverwenden, haben wir diese sieben Hürden in konkretere Herausforderungen aufgespalten. [Veröffentlichung folgt.]

Einigen dieser Herausforderungen kann sicherlich mit der OZG-Rahmenarchitektur und dem Zielbild dieser begegnet werden. Die aus unserer Sicht hierfür relevanten Herausforderungen sind:

2b: Fehlender zentraler Player: Es gibt keinen starken zentralen Akteur, der die Komplexität reduziert und eine Plattform oder Plattformprinzipien forciert.

3b: Neigung zur Neuentwicklung: Es gibt eine Tendenz zur Neuentwicklung statt der Verbesserung und Wiederverwendung bestehender Komponenten und Dienste.

3c: Unklare Governance: Die Strukturen zur Zusammenarbeit, Entscheidungsfindung und Verbesserung der Basisdienste sind unklar.

4a: Fehlendes Bewusstsein an Basisdiensten: Genannter Bedarf beschränkt sich (bisher) auf Nutzerkonten und Payment.

5b: Limitierte Dokumentation und Testumgebung: Eine limitierte (öffentliche) Dokumentation und Testumgebungen erschweren das Einbinden von Basiskompontenten.

6a: Unzuverlässiger Single-Point-of-Failure: Basisdienste sind teilweise nicht funktional lieferfähig und anfällig bei Ausfällen.

(7a: Gefühlt fehlende verpflichtende Standards: Mangel an einheitlichen Standards und/oder Basiskomponenten, teilweise bestehende Standards in der Praxis nicht nutzbar).

(7b: Proprietäre Entwicklung: IT-Dienstleister arbeiten proprietär (wollen die eine Plattform für ihr Bundesland bauen) und integrieren bestehende Basisdienste (BundID, Payment).

S.G - original vom 20.11.2023

Aus Sicht der VISION Consulting GmbH bestehen im Rahmen der OZG-Umsetzung aktuell folgende wesentliche Herausforderungen:

1.       Organisatorische Herausforderungen

-          Das gesamte OZG-Thema muss als eine gesamtstaatliche Infrastruktur behandelt werden (analog zu Autobahn GmbH, Deutsche Bahn AG, Deutsche Post AG, etc.). Die bisherige Aufteilung der Verantwortlichkeiten entsprechend der föderalen Strukturen muss schnellstmöglich zugunsten eines zentralistischen Ansatzes aufgegeben werden. Bei der bisherigen Aufteilung wurden durch die beteiligten Entitäten (Bund, Länder, etc.) zu einem nicht unwesentlichen Teil jeweils eigene Konzepte, Architekturen und Systeme entwickelten. Dies führte und führt zu diversen Parallelstrukturen (verbunden mit entsprechenden Inkompatibilitäten sowie Problemen bei der Entwicklung und Einführung der Systeme) und einer Verschwendung von finanziellen und personellen Ressourcen.

-          Das bisher verwendete EfA-Prinzip (Einer für alle), bei dem OZG-Leistungsbereiche zur Entwicklung und Umsetzung/Betrieb an die einzelnen Bundesländer vergeben wurden, hat sich als eher nachteilig erwiesen (Mangel an Ressourcen, nicht-Beteiligung einiger Länder, Hoheitsfragen, etc.). Auch hier ist von der Rahmenarchitektur und der Organisation her ein eher zentralistischer Ansatz einzuführen (z.B. zentrale Planung/Architektur/Richtlinien und Vergabe genau definierter Arbeitspakete).

-          Best Practices aus anderen EU Mitgliedstaaten übernehmen: Dänemark, Finnland, Litauen, Lettland, Österreich, etc. Hier ist man auf diesem Gebiet schon wesentlich weiter. In Deutschland muss das Rad nicht neu erfunden werden, man kann auch bereits funktionierende Architekturen, Konzepte, Systeme übernehmen. Hierbei erfolgt zwar häufig der Einwand, man könne dies aufgrund der wesentlich höheren Nutzerzahl in Deutschland nicht so machen wie in kleineren Staaten. Bei genauerem Hinsehen zeigt sich allerdings, dass nicht die höhere Nutzerzahl das Problem darstellt, sondern die föderalen Strukturen. Dies gilt auch für den Hang zum „großen Wurf“ – siehe das grandios gescheiterte Ziel „575-OZG-Leistungen Ready per 31.12.2022“. Hier gehen insbesondere die baltischen Staaten viel kleinere, agilere (und deshalb erfolgreichere) Schritte.

2.       Technische Herausforderungen

-          Das gesamte OZG-Thema muss konsequent vom Bürger (Nutzer) aus gedacht werden (aktuell wird noch zu viel von der Verwaltung und von den Verwaltungsstrukturen ausgedacht). Die Bürgerinnen und Bürger wollen einen einzigen Zugang (Nutzeraccount), von dem aus sie sämtliche Leistungen abrufen und nutzen können. Eine allzu sichtbare Weiterleitung auf einzelne Systeme der jeweiligen Leistungserbringer (schlimmstenfalls verbunden mit wiederholter Anmeldung durch die Nutzer oder Fehlschlag der Weiterleitung) muss unbedingt verhindert werden.

-          Es muss dringend eine Registermodernisierung durchgeführt werden. Die bei diversen Leistungserbringern vorhandenen dezentralen Register sind in wenige zentrale Register zu überführen und hierbei Doppeleinträge von gleichen Daten in verschiedenen Registern zu vermeiden bzw. zu verhindern.

-          Verstärkte Beachtung, wie andere (andere Länder, Privatwirtschaft) bisher im Bereich Digitalisierung vorgegangen sind. Bund ID, e-Payment, Wallet, digitale Unterschrift usw.: Adoption fortgeschrittener Technologien - in Kooperation mit z.B. Banken, die sichere Online-Dienste seit Jahrzehnten anbieten - für die Authentifizierung, die Zugriffe auf und die Durchführung von Online-Diensten ermöglichen.

-          Statt der bislang vielfach aufgebauten sehr komplexen IT-System sind verstärkt Mikrodienste zu entwickeln und einzuführen (Aufteilung in überschaubare, in sich abgeschlossene Einheiten, die über standardisierte Schnittstellen mit den anderen Einheiten kommunizieren). Kleine Verfahren welche, wenn sie fertig sind, über ein Plug & Play System schnell in die Produktion eingeführt werden können.

S.L.B - original vom 20.11.2023

Die Herausforderungen der OZG-Umsetzung sind aus Sicht der Bundessteuerberaterkammer vielfältig, sodass an dieser Stelle nur auf ausgewählte Themen eingegangen wird.

Bei der Umsetzung des OZG sind neben der Entwicklung auch die betrieblichen (technischen) Herausforderungen zu betrachten. Je mehr Anforderungen zu berücksichtigen sind, desto komplexer werden die Systeme und die entsprechende Realisierung. Würden mehr zentrale Komponenten einheitlich vorgegeben oder sogar bereitgestellt werden können, würde sich der Aufwand in beiden Dimensionen und damit auch der Kostenfaktor immens verringern. Sicherlich muss trotzdem jede Fachdomäne in ihrem jeweiligen Rahmen Entscheidungen treffen können. Es muss also ein Gleichgewicht zwischen Flexibilität bzw. Interoperabilität geschaffen werden. Am ehesten gelingt dies durch den Einsatz konkreter, öffentlicher Standards.

Insbesondere der föderale Kontext erfordert eine enge Koordination und Kooperation zwischen verschiedenen Verwaltungsebenen und Stakeholdern. Da am Konsultationsprozess nicht alle Interessengruppen gleich und in voller Stärke vertreten sein können, sollte die Rahmenarchitektur auch Raum für Erweiterungen bieten und auch bestehende Lösungen und Portale mitberücksichtigen und Integrationspunkte schaffen.

E.H - editiert am 27.01.2024

Antwort von Bundesamt für Migration und Flüchtlinge (BAMF):

Neben dem bisherigen Schwerpunkt der OZG-Umsetzung, das Verfahren an sich zu digitalisieren und dabei die Verwaltungsabläufe in der Behörde nicht näher in Augenschein zu nehmen, werden nun mit dem OZG-Änderungsgesetz auch die behördeninternen Prozesse in Augenschein genommen. Herausforderung wird dabei sein, die organisatorisch und technisch notwendigen Anpassungen durchführen zu können. Hier fehlt es bisher an der Kommunikation der Zielvorgaben, so dass es nun höchste Zeit ein Transparenzgebot einzuführen und frühzeitig zu informieren. Auch nachgeordnete Behörden müssen frühzeitig informiert werden. Eine Vision scheint es zu geben, aber was Medienbruchfreiheit bei einer Ende-zu-Ende Digitalisierung wirklich bedeutet, bleibt bislang unklar. Geht es soweit, z.B. KI in die Verwaltungsverfahren als festen Bestandteil zu integrieren?

Der eingeschränkte Rahmen des Serviceangebotes des IT-Dienstleisters des Bundes stellt eine große Herausforderung dar.

Die eingeschränkten Finanzmittel stellen eine Herausforderung dar.

Die eingeschränkten Funktionalitäten und die fehlende schnelle Anpassungsfähigkeit der Systeme der IT-Konsolidierung stellen eine Herausforderung dar.

Der (notwendige) Schutz der Netze des Bundes und damit die Kommunikation in diese und aus diesen heraus stellen eine Herausforderung dar.

Der (notwendige) Schutz personenbezogener Daten bei geleichzeitiger Nutzendenfreundlichkeit insbesondere im Once-Only Umfeld stellt eine Herausforderung dar.

Das Delegations- und Vertretungskonzept "On Behalf Of Semantik" ist im Zielbild zu integrieren. Im Kontext einer medienbruchfreien Kommunikation müssen sowohl das Vertrauensmodell als auch die Validierung der Berechtigungsscheine digital abgebildet werden, einschließlich dynamischer Ausstellung und Entzugsmöglichkeiten. In diesem Zusammenhang ist folgenden Herausforderungen zu begegnen:

Die Ende-zu-Ende Kommunikation benötigt eine Datenschutz-konforme Identifikation ohne zentrale Nutzerverwaltung bzw. die Möglichkeit eigene Identifikations-Verfahren dynamisch einzubringen; im Fall vom BAMF die Identifikation anhand eines Erstregistrierungsnachweises.

Die BSI-Protokollierungsrichtlinie; Identitäten müssen bei einer Verkettung von Services durch alle „Instanzen“ getragen werden. Ein Wechsel zu einer Maschinenidentität mit umfassenden Rechten nach dem ersten Dienstaufruf (wie es in der aktuellen OZG Schnittstelle umgesetzt ist) erlaubt weder eine feingranulare Protokollierung noch eine feingranulare Autorisierung. Technisch, vor allem bei asynchroner Verarbeitung, wird die Umsetzung eines End2End Security-Token herausfordernd. Eine Lösung mit rein technischen Nutzern (ClientID Token) zu arbeiten wird aus Sicherheits- und Datenschutzgründen nicht ausreichend sein, was in der derzeitigen OZG Schnittstelle jedoch heute so implementiert ist.

Ein dezentrales Architekturbild, das jeder Behörde erlaubt, selbstsouverän ihre Dienste in einer neuen Version zum selbstbestimmten Zeitpunkt aktiv zu setzen.

"Das OnceOnly-Konzept erfordert die Wiederverwendung von Daten, um eine erneute Eingabe zu vermeiden. Die Vorstellung einer zentralen Verwaltung sämtlicher Daten in einem Register erweist sich als nicht praktikabel, da dies ein äußerst komplexes Rechtemanagement zur Gewährleistung des Datenschutzes erfordert.

F.K - editiert am 28.11.2023

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen:

Einigung auf einheitliche Schnittstellen und Standards => XÖV Standard prüfen, ob dieser ausreichend ist und ggf. Entsprechend anpassen, damit dieser zur Zufriedenheit aller verwendet werden kann

Kommunikation zwischen den verschiedenen Stakeholder (Land, Hochschulen, Campusmanagementsystem-Hersteller) muss sichergestellt werden, damit sich nicht einzelne wegentwickeln ("Bin ich noch auf dem richtigen Pfad?")

Einheitliches und transparentes Tracking des Fortschrittes, ggf. Öffentliches

Technische Voraussetzungen in den betroffenen Verwaltungen (Soft – und Hardware, Sicherheitskonzepte etc.)

Schulung der Mitarbeiter, betroffene Personen informieren, um die Akzeptanz zu erhöhen

Gewährleistung eines koordinierten Vorgehens bundesländerübergreifend im operativen Bereich OZG-/SDG-VO- und RegMod-Umsetzung

Bessere Nutzung von Synergien anstatt „Jeder für sich beantwortet und bearbeitet übergeordnete/grundlegende Fragen“ [Symbol] Ressourcenbündelung, gute und gut nutzbare Informations-/Wissens-/Austauschplattformen für Akteurs-/Interessensgruppen, wie z.B. Hochschulen (bundesweit, trotz Föderalismus)

Die Hochschulen haben nicht von EfA-Diensten profitieren können. Das war bisher nicht möglich, da die Hochschulen seit Jahrzehnten Campusmanagement-Systeme einsetzen; in Deutschland sind das ca. 20 Anbieter

Teilweise ließen sich bestimmte OZG-Leistungen erfolgreich und relativ zügig umsetzen. Bei einigen Leistungen besteht große Heterogenität in den Prozessen der Hochschulen; historisch gewachsene Prozesse in unterschiedlichsten Hochschulbereichen müssten koordiniert neu gedacht und gestaltet werden. Hier braucht es entsprechend Zeit um die Hochschulen und Akteure „mitzunehmen“

Weiterhin sind Ressourcen an den Hochschulen knapp für die Umsetzung der Aufgaben rund um OZG/SDG/RegMod; Finanzierungen teilweise kurz- bis mittelfristig, darüber hinaus besteht Fachkräftemangel

Bedarf an Finanzierung bzw. Mittelsicherung langfristig gewährleisten, sonst weitere

Umsetzung und Weiterentwicklung eingeschränkt.

Hochschulen benötigen im Kontext OZG/SDG/RegMod mehr Zeit - für Digitale Transformation statt nur Digitalisierung der Oberflächen (die ggf. die Nutzer, aber nicht die Hochschulen digital voranbringen und die im Nachgang zu Anschluss- oder gar Rückabwicklungsarbeiten führt)

Es braucht Visionen und mehr Begeisterung für die Digitale Transformation an zentralen Stellen anstelle von Reaktionsmanagement

Es braucht Follow-Up-Orientierung / Blick für Langfristigkeit der Digitalisierung: nicht nur jetzt/bald und gesetzeskonform digital umsetzen, sondern zukünftige Pflege, Weiterentwicklung usw. berücksichtigen und einplanen (zeitlich, Ressourcen etc.)

T.F - original vom 20.11.2023

Antwort seitens Deloitte:

Technische Herausforderungen:

Eine Vielzahl von, gemäß Efa-Mindestkriterien zulässigen, technischen Datenübertragungsstandards (OSCI, FitConnect & XTA2) in unterschiedlichen Graden der Ausgereiftheit erschweren die Ende-zu-Ende Implementierung von Onlinediensten vom Portal bis zum Fachverfahren

Verschiedene Elemente der Infrastruktur (z.B. OSCI Intermediäre, FitConnect Infrastuktur) und die Prozesse der IT-Dienstleister sind von ihrer Kapazität nicht auf den Umfang des OZG ausgelegt. Dies führt zu geringer Umsetzungsgeschwindigkeit innerhalb der Projekte und dauerhaft zu betrieblichen Herausforderungen.

Die Schaffung von Insellösungen ist eine Herausforderung. Ein Beispiel: es wurde mit dem Postkorb der BundID ein einheitlicher Postkorb geschaffen, um Insellösungen zu vermeiden, an anderer Stelle wird im Rahmen von FIT-Connect die bidirektionale Kommunikation ermöglicht für dessen Nutzung Portale eigene Postfächer integrieren müssen. Gem. Informationen von FIT-Connect wird der Postkorb der Bund-ID erst perspektivisch mitgedacht. Somit werden erneut Insellösungen geschaffen, die mit hohem Aufwand zusammengeführt werden müssen.

In einigen Fällen lässt sich eine Zuständigkeitsfindung über Leika und ARS – wie es aktuell in den EfA-Mindestanforderungen gefordert wird – nicht realisieren, da die Komplexität der Zuständigkeiten zu groß und heterogen ist.

Organisatorische Herausforderungen:

Aufgrund der fehlenden Verbindlichkeit von EfA-Diensten entstehen eine Vielzahl von redundanten Onlinediensten, die langfristig betrieben und gepflegt werden müssen.

Zuständige Stellen in Ländern und Kommunen müssen gleichzeitig eine Vielzahl von Onlinediensten mit unterschiedlichen technischen Voraussetzungen anbinden. Dies führt häufig zu einer Überforderung der begrenzten Kapazitäten, die für die Anbindung zur Verfügung stehen.

A.K - original vom 20.11.2023

Aus einer organisatorischen Sicht, kann ein Zielbild - eine übergreifende Orientierung resp. ein gemeinsames Verständnis „Wohin soll die Reise gehen“ bieten - bietet Ansatzpunkt zur Planung im Sinne einer Roadmap - Soll-Ist-Abgleich im Zuge der Umsetzung „Sind wir auf dem richtigen Weg?“ - Die OZG-Rahmenarchitektur dient als Leitfaden für die Fokussierung und Priorisierung von technischen Projekten zur Umsetzung der OZG-Architektur und schafft als Zielbild der Organisation stets eine Richtung der Organisationsentwicklung zu geben.

Aus einer technischen Sicht, kann ein Zielbild - Auswahl und Ausrichtung einer zukunftsfähigen technologischen Basis unterstützen. - Einheitliche und Standard-konforme Lösungen unterstützen. - Abhängigkeiten und benötigte Schnittstellen zwischen Komponenten darstellen und durch Vorgabe von Standards eine einheitliche Grundlage für die Umsetzung schaffen. - Klarheit darüber schaffen, was Architekturkonform ist und was nicht (siehe hierzu die Antwort zu den Architekturrichtlinien) - Einheitliche Standards - Gewährleistung von Nachnutzung und Interoperabilität

T.K - editiert am 22.11.2023

Sammlung CDO-MID Sachsen-Anhalt und Vertreter von Kommunen des Landes

• Nach meinen aktuellen Erfahrungsstand benötigt man noch viele kleine Zwischenschritte, um Onlinedienste (auch Nahnutzungen) an den Start zu bringen: hier müssen noch Zertifikate eingeholt werden, müssen noch Meldungen erfolgen. Ich hoffe, die OZG-Rahmenarchitektur trägt zur Automatisierung bzw. Überspringen dieser vielen Zwischenschritte bei.

• Derzeit braucht es noch recht viele Ressourcen in der Verwaltung, um OZG-Dienste in der Verwaltung umsetzen zu können. Die Stadt Zeitz kann z. B. frühestens am 1.3.24 der Interessensgemeinschaft ePayBL/ePayLSA beitreten, weil unsere EDV früher keine Ressourcen bereitstellen kann.

• Der Fachkräftemangel im IT-Bereich ist eine große Bremse für die Digitalisierung. Eine technische und organisatorische Standardisierung, die kein tieferes Fachwissen für die Anwender erfordert, würde hier helfen (Nutzerfreundlichkeit für die Anwender, Zielgruppe: Verwaltungsmitarbeiter).

• Kommunen (insbesondere in der Konsolidierung) müssen mit der sicher zunehmenden Digitalisierungsgeschwindigkeit mithalten können.

•schwierige Nachnutzung, wenn man es Ende-zu-Ende denkt - vor allem durch die heterogene IT-Infrastruktur • Vendor-Lockin bei Fachverfahren

• schwierige Nachnutzung, wenn man es Ende-zu-Ende denkt - vor allem durch die heterogene IT-Infrastruktur • Change Management in der Verwaltung (Stichwort Silodenken und "hab ich schon immer so gemacht") - Digitalisierung ist interdisziplinär und agil, beides ungewohnt für die klassische Verwaltung

• Registermodernisierung und die Anbindung an die Fachverfahren wurden bei der Erstellung der OD nicht mitgedacht - Mehraufwände entstehen im Nachgang

• unterschiedliche Herangehensweise bei der Einführung von EfA-Diensten (Projektmanagement, fehlende Handlungsleitfäden, etc.)

• Basiskomponenten müssen mindestens den Anforderungen/Funktionalitäten von am Markt befindlichen Verfahren entsprechen (Stichwort ePayBL Sachsen-Anhalt)

• zu lange Implementierungswege und Abstimmungsrunden aufgrund der Heterogenität

• Kosten für Erstellung und Betrieb der Lösungen auf allen Verwaltungsebenen

• keine Planungssicherheit für die Einführung von IT-Lösungen aufgrund stetig neuer Anforderungen

AS - original vom 20.11.2023

Governance-Strukturen stärken

Die föderale Gliederung der deutschen Verwaltung bedingt einen hohen Komplexitätsgrad von Prozessen und Strukturen. Die Zusammenarbeit der vielen beteiligten Akteure gestaltet sich aufgrund oftmals unklarer Zuständigkeiten und einem großem Veto-Potential zentraler Akteure häufig schwierig und zeitintensiv. Wichtig ist daher, die Strukturen und Prozesse der OZG-Governance so zu organisieren, dass Entscheidungen transparent und innerhalb akzeptabler Laufzeiten getroffen werden. Zuständigkeiten sollten klar verteilt sein. Sofern diese Aspekte durch die Erstellung des Zielbildes nicht unmittelbar beeinflusst bzw. unterstützt werden können, sollte das Zielbild auf fachlich-technischer Ebene Lösungen und Orientierung bieten, sodass die zentralen Akteure entlastet werden und handlungsfähig bleiben. Ein Zielbild kann sicherstellen, dass wiederkehrende technische Anforderungen durch zentrale Umsetzungsprojekte gelöst werden, die von Ländern und Kommunen einfach nachgenutzt werden können. Im Zielbild können Festlegungen zur Interoperabilität getroffen werden, ohne die es (wie bisher noch zu häufig) zur Entwicklung von Insellösungen kommt.

Mehr Zentralisierung wagen

Im Rahmen der Entwicklung des Zielbildes sollte erwogen werden, stärker auf zentrale Strukturen und Akteure zu setzen. Die dezentrale Bereitstellung und Entwicklung von Diensten bedingt einen großen Anteil der beobachtbaren Komplexität des Systems. Die Entwicklung im Bereich der Servicekonten zeigt deutlich: Zentrale Funktionen sollten einmal entwickelt und zentral (bzw. bei sicherheitskritischen Anwendungen als verteilte Anwendung) bereitgestellt werden. Für diese dann kleinere Anzahl an Komponenten und Diensten kann das Zielbild zielführende Betriebs- und Supportstrukturen vordenken, wobei die Supportstrukturen die gesamte Prozess-Kette, von den Antragsteller:innen bis hin zur Sachbearbeitung, abdecken sollten.

T.L.S.P - original vom 20.11.2023

Neben den hier bereits genannten technischen und organisatorischen Herausforderungen wollen wir gezielt auf eine, aus unserer Sicht zentrale, Herausforderung eingehen:

Aus guten und überzeugenden Gründen wurde sich zur Umsetzung des OZG im Kern für eine dezentrale IT-Struktur bzw. –Systemarchitektur entschieden. Aus bekannten und bereits genannten Gründen ist hierbei erstrebenswert, auf einheitliche Standards zu setzen. In der Praxis zeigt sich jedoch, dass dies nicht ohne Weiteres realisierbar ist und teils immense Umsetzungshürden zur Folge hat: Insbesondere, da zum einen bestehende (Legacy) IT-Systeme betroffen sind, die sich nicht ohne Weiteres auf einen Standard umstellen / migrieren lassen. Zum anderen aber auch, da es nicht den einen Universal-Standard gibt, der für alle Systeme greift und eingesetzt werden kann. Vielmehr haben sich in unterschiedlichen Kontexten unterschiedliche Datenformate und Schnittstellenstandards entwickelt und etabliert, die jeweils durchaus klare Vorteile haben und daher (zumindest temporär) beibehalten werden sollten. Die Pluralität kontextspezifischer Standards in Punkto Datenformate, Schnittstellen und Transportschemata steigert jedoch unweigerlich die Komplexität des Gesamtsystems und erhöht den Aufwand, den OZG-Beteiligte zur Anbindung ihrer Systeme an die im Ergebnis doch heterogene Systemlandschaft betreiben müssen (technische Herausforderung). Da zudem jede Kommune und jedes Land sich an diese heterogenen Systeme bzw. Verwaltungsleistungen anbinden muss, wird der bundesweite Aufwand zur Realisierung des OZG entsprechend multipliziert (organisatorische Herausforderung).

Um die Systemkomplexität für die dezentralen Systemkomponenten bzw. Bund, Länder und Kommunen zu kapseln und den Aufwand damit beherrschbar zu machen, sollte aus unserer Sicht deshalb zwingend in der Architektur eine zentrale Infrastrukturkomponente vorgesehen werden, die nach außen die jeweiligen Schnittstellenstandards, Datenformate und Transportschemata anbietet, sie im Inneren aber wandelbar / konvertierbar macht und damit per Design eine Kompatibilität zwischen unterschiedlichen Standards herstellt. So kann diese Komponente gezielt Daten in einem Datenformat A über eine Schnittstelle X annehmen, die Datenformate wandeln bzw. übersetzen und anschließend in einem Datenformat B über eine Schnittstelle Y wieder ausgeben. So kann sich jede IT-Systemkomponente auf ihre kontextspezifisch standardisierten Datenformate und Schnittstellen konzentrieren und über die verbindende & übersetzende zentrale Infrastrukturkomponente mit anderen IT-Systemkomponenten kommunizieren, auch wenn diese andere Datenformate und Schnittstellen benutzen. Dies ermöglicht zudem auch, das Legacy-Systeme eine angemessene Zeitspanne zur Verfügung gestellt bekommen, um auf neuere Datenformate, Schnittstellen und Transportschemata migrieren. Nicht zuletzt bedeutet dies, dass Kommunen und Länder sich im besten Fall nur noch an die besagte zentrale Infrastrukturkomponente anbinden müssen, um mit allen bestehenden und zukünftig neuen Systemkomponenten interagieren zu können.

M.M - original vom 21.11.2023

Herausforderungen

technisch

Interoperabilität per Design durch Nutzung von FIM-Stammprozessen in Verbindung mit FIM-Stammdatenschemata. Weiterentwicklung des "Bildes vom Gesetz (FIM)" zum "Bild von der guten Idee (OZG-Referenzinformation)" in Form der syntaktisch gleichen bis sehr ähnlichen Modelle. Anschließend modellgetriebene Entwicklung unter Nutzung von funktionell beschriebenen Komponenten / Microservices / Workflow-Engines u.ä.

Wissen über die öffentliche Verwaltung, wichtige technische Ebenen semantisch beschreiben und verknüpfen

Unterstützt viele unterschiedliche Enwickler, Unternehmen, etc. bei der Digitalisierung

Unterstützt Mitarbeiter der öffentlichen Verwaltung

auch Dokumentationen offener Standards an verschiedenen Orten semantisch verknüfen

Beseitigung von Medienbrüchen, weil einzelne Systeme nicht miteinander sprechen können und dadurch Daten mehrfach erhoben werden müssen. Das setzt zuerst voraus, dass jedes System passende Schnittstellen hat. Um diese dann interoperabel zu haben, kann man entweder Standards definieren, die aber vergleichsweise starr sind und nur langsam auf Änderungen reagieren, oder man setzt auf eine gemeinsame Wissensbasis, die die Schnittstellen formal beschreibt und so für eine dynamischere Integration vorbereitet. Die zweite, dezentralere Lösung erlaubt es auch eher den föderalen Eigenheiten gerecht zu werden, weil die Einigung eher auf dem Level einzelner Begrifflichkeiten stattfinden muss, statt auf der Ebene komplexerer Schnittstellen.

organisatorisch

Entwürfe unter Nutzung des FIM als Basis generell ausgehend von den für alle/viele gleichen Handlungsgrundlagen, damit bereits in Konzeptphasen gleiche Anforderungen betont und so per Design für Nachnutzbarkeit gesorgt werden kann.

Wissen über die Organisation semantische beschreiben

wichtige Ansprechpartner/Beteiligungen definieren

Hierachie der Gesetzesgebung abbilden

wichtige Organisationen und Akteure sollten sich wiederspiegeln

Zielgruppen definieren, andere Zielgruppe = andere Interressen = anderes Zielbild

Flughöhen anpassbar

Artefakte des föderalen Aufbaus der BRD. Als Herausforderung hier die Bereitschaft einzelner Beteiligter (Kommunen, Länder, Bund), sich in wichtigen Fällen technischen Standards unterzuordnen, wenn diese nicht mit den eigenen Vorgehensweisen kompatibel sind.

Verbindliche Deadlines für Umsetzung bzw. Sanktionen für Verspätungen.

J.P - editiert am 21.11.2023

Antworten Team PwC:

Technische Herausforderungen: - Fehlende strategische Entscheidungen zur Priorisierung von technischen Anbindungsoptionen, wie OSCI/XTA oder FIT-Connect - Fehlende Übersicht und Standardisierung in der Fachverfahrenslandschaft (Zersplitterung) - Fehlende bundesweite Standards zum Datenschutz und zur IT-Sicherheit im Rahmen der OZG-Umsetzung (fehlende Best-Practices) - Unklare Supportstruktur von EfA-Onlinediensten (First-/Second-/Thirdlevelsupport) - Fehlende Verbindlichkeit hinsichtlich der Verwendung von Standards, Methoden und Tools - Fehlende Praxisnähe, Koordinierung (Verteilung von Zuständigkeiten) und Rahmensetzung des Bundes und damit verbundene mangelnde strategische Zielsetzung für Kommunen - Fehlendes (technisches) Back-End: Der konzeptionelle Fokus des OZG trifft nicht die Realität der Kommunen und löst nicht ihre praktischen Herausforderungen - Heterogenes Angebot der IT-Dienstleister – Schnittstellen hindern die Umsetzung - Unterschiedliche technische Lösungen in Bund, Ländern und Kommunen sowie in den verschiedenen Verwaltungsbereichen, welche nur mit viel Aufwand verknüpft werden können, was häufig nicht zu nutzerfreundlichen und effizienten Gesamtlösungen und Prozessen führt - Fehlende Kenntnis/Wissen/Know-how, sowie Zeit und Ressourcen bei den anbindenden Kommunen, um den komplexen technischen, gewachsenen Strukturen zu begegnen

Organisatorische Herausforderungen: - Fehlendes Deutschlandweites/einheitliches Schaubild/ Übersicht zur standardisierten OZG-Rahmenarchitektur - Fehlende Betrachtung aller föderalen Ebenen in der OZG-Rahmenarchitektur (konkrete Bedarfe der Länder und Kommunen werden teilweise außer Acht gelassen) - Mangelnde Rechtskonformität von digitalisierten Verwaltungsleistungen - Fehlende Verbindlichkeit hinsichtlich der Verwendung von Standards, Methoden und Tools - Fehlende Kapazitäten bei der für die jeweilige Leistung zuständige Fachlichkeit - Unklare Zuständigkeiten bei föderationsebenenübergreifenden Leistungen - Mangelnde Führung und Vorgaben vom Bund für Länder und Kommunen - Die Stakeholder eines gemeinsam entwickelten (EfA-)Onlinedienstes müssen sich darauf verständigen, einen gemeinsamen Onlinedienst zu schaffen, und nicht bis zu 16 Individuallösungen - Fehlendes (technisches) Back-End: Der konzeptionelle Fokus des OZG trifft nicht die Realität der Kommunen und löst nicht ihre praktischen Herausforderungen. In der Folge werden andere Themen prioritär behandelt - Unzureichender Spielraum, um Lösungen markt- und praxisgetrieben entstehen zu lassen. Wünschenswert: Bund gibt Rahmen, in dem Kommunen und Länder gestalten können - Förderung von praxisnahem Austausch abseits von politischen Gremien - Projekte ohne längerfristige Haushaltsmittel - Dauerhafte Überlastung von Referaten mit Zuständigkeiten im Bereich der OZG-Umsetzung - Sehr lange Entscheidungsprozesse im föderalen Kontext zu allen Arten von Fragestellungen - Unsicherheiten in der langfristigen Finanzierung von Digitalisierungsvorhaben - Konsequent weitermachen, anstatt auf die große Verwaltungs- bzw. Digitalisierungsreform zu warten (Grundsatzdebatten kann man parallel weiterführen) - Progressivere Interpretation bestehenden Rechts zu Gunsten der Nutzerfreundlichkeit

IT.E.B.S.S - original vom 22.11.2023

welche Infrastrukturen sind zentral nutzbar in Bund, Land und Kommunen

welche Netze müssen / sind angebunden

welche Identifizierungsmechanismen sind nutzbar (vor allem auch für Maschine-zu-Maschine)

wer ist die vertrauenswürdige Stelle, welche die Berechtigungen für die Kommunikation erteilt

welche Standards sind wo sinnvoll einsetzbar? XÖV ist bei Leistungen, die nur von einer Stelle erbracht werden überflüssig. Generell sollte ohnehin auf Datenaustauschformate verzichtet werden und wenn möglich lediglich eine Ja/Nein Frage gestellt und beantwortet werden (siehe Reifegrad D im OOTS). Dies ist auch der einzig gangbare Weg für Datensparsamkeit. Es werden nicht alle Daten aus einem Melderegister benötigt, wenn die eigentlich Frage lautet: "ist die Person volljährig".

es ist unrealistisch, zunächst aufwendig Datenaustauschformate abzustimmen UND vor allem im Anschluss sämtliche Bestandssoftware dahingehend anzupassen. Bis das passiert ist sind weitere 10-15 Jahre vorbei. Hinzu kommt, dass die Versionierung dieser Austauschformate zu schwerfällig ist für Neuerungen aber gleichzeitig viel zu fragil für die damit arbeitenden Fachverfahren

bevor alles so digitalisiert wird, wie es aktuell analog existiert, sollte überall versucht werden, Verfahrensvereinfachungen zu ermöglichen

M.K - editiert am 22.11.2023

Antworten des Programmbereichs OZG-EU-OOTS der Gesamtsteuerung Registermodernisierung

Organisatorisch 1. Es fehlt eine klare Roadmap hinsichtlich Identitäten von Unternehmen inkl. Vertreter und natürlichen Personen. Welche Rolle wird z. B. die EUDI-Wallet haben? 2. Vielzahl an Stakeholdern und unklare bzw. dezentrale Verantwortlichkeiten führen zum Ausbleiben von Entscheidungen 3. Desweiteren fehlen klare Roadmaps um die zeitliche Schiene transparent einzusehen. 4. Unzureichende fachliche Informationen zur Erreichung des OZG-Reifegrad-4: Ungenügende Definition. Welche Ausgestaltungsarten sind erwünscht/erlaubt 5. Es bestehen sehr unterschiedliche Ansätze die das Zusammenbauen eines Puzzles sehr erschweren. Es fehlt ein gemeinsames Zielbild. 6. Fehlende Harmonisierung der Beteiligten (bzgl. Fachprozessen, Betriebs- und Supportstandards, fehlende Standardisierung von Datenaustausch-formaten), 7. Die OZG-Infrastruktur enthält viele redundante Funktionen, die auf Ebene Länder und Kommunen betrieben werden, wie z. B. Bezahldienste. Sind Konsolidierungen möglich? 8. Für die Umsetzung OZG ist die Harmonisierung und Vereinheitlichung von Richtlinien, Schnittstellen, Verfahren und Standards notwendig. Mit der Festlegung von Leitlinien und damit verbundene Governance können Herausforderungen begegnet werden 9. Unklare Finanzierungen 10. Unklare Verantwortlichkeiten bspw. Eckpunktepapier, Aufgaben der Kommunen etc. 11. Im Kontext der Reifegrad-4-Umsetzung ergeben sich eine reihe rechtlicher Fragen, welche an keiner zuständigen zentralen Stelle adressiert werden können

Technisch 11. Vereinfachung für den Nutzer durch Single Sign-on 12. Die niedrige Datenqualität von PVOG mit geringer Trefferquote 13. Es gibt eine Fülle von Verwaltungsportalen mit sehr unterschiedlicher Qualität. In Summe schlechte Nutzerorientierung. 14. Weiterentwicklung der EfA-Mindestanforderungen zur nutzerorientierten Verknüpfung von OZG-Plattformen (bspw. Dynamischer oder statischer Link, Single-Sign-on, Mitgabe von Daten, usw. 15. Wallet oder eIDAS

M.H - original vom 24.11.2023

Universtität Duisburg-Essen, HISinOne-Cm.nrw:

Die aktuellen technischen und organisatorischen Herausforderungen der OZG-Umsetzung, insbesondere im Kontext des Hochschulwesens, sind vielschichtig und komplex. Einer der Hauptaspekte ist die Harmonisierung und Integration unterschiedlicher IT-Systeme die an Hochschulen, Schulen und anderen Bildungseinrichtungen eingesetzt werden. Eine gemeinsame Zielsetzung der OZG-Rahmenarchitektur kann hierbei einen koordinierten Ansatz bieten, um eine einheitliche digitale Plattform zu schaffen, die sowohl die nationalen Anforderungen als auch die internationalen Vernetzungsbedürfnisse berücksichtigt.

Organisatorisch gesehen liegt eine Herausforderung darin, die verschiedenen Interessengruppen – von Schulen über Hochschulen bis hin zu weiteren Institutionen wie der Stiftung für Hochschulzulassung sowie der IT-Infrastruktur/den EfA-Diensten des Bundes – in den Prozess der Entwicklung und Implementierung einzubinden. Eine effektive Zusammenarbeit und Abstimmung zwischen diesen Akteur:innen ist entscheidend, um eine Nutzer:innenzentrierung zu gewährleisten und die Verwaltungsprozesse im Bildungszugang zu vereinfachen. Dies würde die Bildungsjourney aus Sicht der Studierenden als nahtlosen, integrativen und unterstützenden Prozess gestalten.

Ein zentraler Punkt ist der eingeschränkte Zugriff der Hochschulen auf die Netzinfrastruktur des Bundes oder der Länder, was den Zugang zu vorgeschriebenen Diensten wie der BundID oder ePayment-Lösungen wie ePayBL erschwert. Solche Dienste sind für die digitale Abbildung der Hochschulprozesse essenziell. Die Vielzahl von Standards für den Austausch von Leistungsdaten, wie der XBildungsstandard, ELM oder ELMO, erhöht die Komplexität der Umsetzung. Oft scheitert die Umsetzung daran, dass die notwendige Prozesssicht und die verschiedenen Anwendungsfälle nicht ausreichend berücksichtigt werden oder wurden. Zudem bewegen sich Hochschulen in einem internationalen Kontext, wodurch eine rein nationale Digitalisierung nur einen Teil der erforderlichen Lösungen abdeckt.

Die Finanzierungsaspekte der Digitalisierung im Kontext des Onlinezugangsgesetzes (OZG) stellen eine signifikante Herausforderung dar, insbesondere für Hochschulen. Da die Lebenslange Studium im Rahmen des OZG keine direkte Finanzierung für die Umsetzung von OZG-Leistungen beinhaltet, stehen Hochschulen vor dem Problem, dass sie selbst für die Umsetzung zuständig sind, ohne auf eine zentrale Finanzierung zurückgreifen zu können. Dies erschwert die Realisierung einer durchgängigen Digitalisierung, da vorhandene Konjunkturmittel des Bundes lediglich für Projekte zur Verfügung stehen/standen, die neue Online-Dienste nach dem EfA-Prinzip entwickeln. Diese Mittel sind jedoch für die Hersteller der Campusmanagementssysteme (CaMS) nicht nutzbar. Hingegen sind es aber gerade diese CaMS, die im Allgemeinen die notwendigen integrierten Online(antrags-)diensten beinhalten bzw. bereitstellen. Im Sinne einer ganzheitlichen Digitalisierung gilt es nun, ein echtes digitales Ökosystem „Bildung“ / „Hochschule“ zu schaffen. Die Notwendigkeit einer stabilen Grundfinanzierung für die Digitalisierung im Hochschulbereich wird somit deutlich. Ohne eine solche Finanzierungsbasis ist es für Hochschulen schwierig, die geforderte Digitalisierung im Sinne des OZG effektiv umzusetzen und eine moderne, nutzerorientierte digitale Bildungsinfrastruktur zu etablieren.

Um diese technischen Herausforderungen zu bewältigen, ist es notwendig, die gesetzlichen und strukturellen Rahmenbedingungen zu überprüfen und anzupassen, die Vernetzung zwischen den verschiedenen Akteur:innen auf Bundes-, Landes- und Hochschulebene zu verstärken und eine ausreichende Finanzierung sicherzustellen. Nur durch ein koordiniertes Vorgehen und eine enge Zusammenarbeit aller Beteiligten kann eine erfolgreiche digitale Transformation im Bildungssektor erreicht werden.

L.S - original vom 24.11.2023

Die komplexen Herausforderungen bei der aktuellen OZG-Umsetzung sehen wir vermehrt in der Etablierung und Anwendung von internationalen Industriestandrads, sowie der Integration von aktuellen Entwicklungen wie „Infrastructure as a Code“ und der klaren Integration von OZG nahen Vorhaben wie dem Digitalcheck und der Registermodernisierung. Die Verbindung der Vorhaben erhöht den Nutzen und damit die Akzeptanz bei den Bürgerinnen und Bürgern und auch in der Verwaltung (Ende-zu-Ende).

Folgend möchten wir für uns wichtige Themen und Herausforderungen benennen:

Technische Herausforderungen:

Nutzung von Standards Die Nutzung von Standards ist eine wichtige Voraussetzung für die OZG-Umsetzung, es sind neben den deutschen Standards auch im Sinne der Zukunftsfähigkeit europäische und internationale Standards zu nutzen. Deutschland kann nicht isoliert entwickeln und in vielen Bereichen der IT nicht Marktführer.

IT-Architekturrichtlinien In die IT-Architekturrichtlinien müssen zwingend das „Cloud-First“-Paradigma und die „hybride Interoperabilität“ aufgenommen und konsequent verfolgt werden. Dabei geht es vor allem um die Öffnung in Richtung aktueller und marktüblicher Technologie statt der Vorgabe von etablierten und vielfach nicht mehr aktuellen Produkten. Auch im Sinne der Resilienz. Physikalisch isolierte Informationsverbünde für Fachverfahren erfordern für Interoperabilität in der Regel hohe und komplexe Integrationsaufwände. Wir empfehlen außerdem eine Plattformstrategie anstatt die Entwicklung einzelner Produkte, die in Kombination häufig nicht lauffähig sind.

Nachnutzung Die Nachnutzung im Sinne des EfA-Prinzips setzt voraus, das die unterschiedlichen Dienstleister die Lösungen selbst auf ihrer eigenen Infrastruktur anbieten können. Trotz DVS sind hier in der Regel die Integrationsaufwände sehr hoch. Es sollte an dieser Stelle über die Nutzung von am Markt verfügbaren Plattformen nachgedacht werden, die einen zentralen Betrieb aus einer für alle Nutzenden zugänglichen Cloud ermöglichen. Bei der Auswahl der Plattformen sollte auf eine bestmögliche Integration in die bestehende Arbeitsumgebung geachtet werden, um die Integrationsaufwände gering zu halten, und es sollten Anbieter mit entsprechender Leistungsfähigkeit ausgewählt werden.

Derzeit sind auch Themen wie „Infrastructure as a Code“ nur oberflächlich von der DVS adressiert – hier hat es Sinn nachzuschärfen und damit die Lauffähigkeit des Codes in unterschiedlichen (Cloud) Umgebungen sicherzustellen. Zusätzlich ist es empfehlenswert jede zu modernisierende Anwendung nach den folgenden Kriterien zu prüfen: - neu entwickeln (neueste Standards und Cloud-born) - Migrieren (zum Beispiel „lift and shift“) - Modernisierungen (z.B. Server-less, Containerisierung) - Ablösung (durch neue Verfahren) - Beibehalten (da eine Migration oder Ablösung nicht mehr relevant ist) - Abschaffung

Prozessoptimierung und -digitalisierung Eine „Front-End-Digitalisierung“ der Leistungen für Bürger:innen reicht nicht aus, da die wesentlichen Effizienzsteigerungen nur durch Optimierung und Digitalisierung der Verwaltungsprozesse erreicht werden können. Die häufig manuellen Arbeitsschritte mit sequentieller Bearbeitung müssen gestrafft und parallelisiert werden. Dazu sollten alle Arbeitsschritte und erforderliche Nutzeroberflächen in die gewohnte Arbeitsumgebung der Mitarbeiter integriert werden, um die Bearbeitungs- und Kommunikationsaufwände minimieren zu können. An dieser Stelle sollte von vorneherein die konsequente Integration und Nutzung von KI eingeplant werden, um die Beschäftigten maximal zu entlasten und moderne Potenziale zu heben.

Datennutzung / Once-Only Die bisherige Praxis der Datenisolation in Fachverfahren muss zugunsten einer gemeinsamen und geteilten Datennutzung modernisiert werden. Daten müssen sicher und einfach in verschiedenen Verfahren genutzt werden können, um das „Once-only“ Prinzip umzusetzen. Hierzu sind marktübliche Standards und Produkte verfügbar, die eine neue Datenkultur ermöglichen. Auch regulatorisch müssen hier Voraussetzungen geschaffen werden, sodass Datenbestände auch Organisationsübergreifend nutzbar sind (siehe als ein konkretes Beispiel von vielen Grundsteuerreform ELSTER vs. Kataster). Zusätzlich ist eine durchgängige und international vergleichbare Datenklassifikation erforderlich, damit eine sichere Datennutzung zeitnah umgesetzt werden kann. Erfolgsfaktor bei der Datenklassifizierung ist die Einfachheit des Systems, nicht die Komplexität. Das heißt wir raten von granularen Klassifizierungssystemen ab und empfehlen eine geringe Anzahl an Stufen der Klassifikation.

Identitätsverwaltung Die verbindliche Nutzung der Bund-ID anstelle von verschiedenen Länder-IDen ist ein Schritt in die richtige Richtung. Für eine zielführende Nutzung sind jedoch einige Anpassungen erforderlich. Die Nutzung muss vereinfacht und auch sinnvoll mobil möglich sein, ohne komplizierte zusätzliche Apps und andere Hürden. Gleichzeitig sollten zusätzliche Dienste aus dem Alltag der Bürgerinnen und Bürger (Versicherung, Transport, Banking etc.) als Mehrwert angeboten werden, die über diese ID nutzbar sind.

Technische Industriestandards vor eigenen Verwaltungsstandards Statt der Definition „neuer Standards“ die als Grundlage für die Interoperabilität innerhalb der Verwaltung dienen sollen (XTA, OSCI) ist die Empfehlung, sich auf bestehende und erprobte Industriestandards zu stützen. In der Praxiserfahrung fehlt bei der konkreten technischen Umsetzung von eigenen Standards das breite KnowHow (aufgrund der fehlenden Verbreitung im Markts) ohne gleichzeitig einen nennenswerten Vorteil gegenüber bestehenden Industriestandards (insbesondere auch im Kontext Verschlüsselung und Transportsicherheit) zu erzielen.

Intelligente, digitalisierte Gesetzgebung als Grundpfeiler für OZG-Anwendungen und Prozesse: Eine konsequente Digitalisierung fängt beim Gesetzgebungsverfahren an und hört bei der Integration neuer Gesetze und Verordnungen in den Fachanwendungen mit Bürger:innen-Kontakt auf. Wir empfehlen das konsequente Umsetzen von intelligenten, digitalisierten Gesetzgebungsprozessen, die maschinenlesbar gestaltet sind, um so Gesetze und Verordnungen auf schon vorab auf Wirksamkeit hin simulieren zu können, nach Freigabe diese in die bestehenden Fachverfahren automatisch zu integrieren (Prozessebene) und damit ohne Zeitverzug in Bürger: innen-Dienste zu überführen. Die Integration des parallel laufenden Projektes „Digitalcheck“ für Gesetze ist daher wichtig.

Organisatorische Herausforderungen: Ergebnisorientierung Statt der bisher vielfach üblichen Aufgabenorientierung ist eine Ergebnisorientierung erforderlich, die die Ziele und Ergebnisse über die gesamte Prozesskette betrachtet. Bei einer „Ende-zu-Ende“ Digitalisierung müssen die Ergebnisse für Bürger, Anwender und Nutzer der Verwaltung transparent und messbar sein. Die Bereitstellung digitalisierter Formulare ist keine erfolgreiche Digitalisierung, die Nutzung muss intuitiv und bis zum digitalen Bescheid vorgedacht sein. Im Idealfall agiert der Staat proaktiv und bietet Leistungen an, erstellt Bescheide nach einfacher ja/nein Zustimmung der Bürgerinnen und Bürger, zahlt Unterstützung bei klarem Bedarf einfach aus.

Datenkultur etablieren Zur gemeinsamen Nutzung von Daten muss die Bereitschaft bei den Verantwortlichen der Fachverfahren geschaffen werden, eigene Daten zur Verfügung zu stellen und auch Daten aus anderen Fachverfahren zu nutzen. Dies setzt eine entsprechende Governance und geeignete Sicherheitsmechanismen voraus. Schulungs,- und Dialogprogramme sind hier wichtig.

Cloud-first Mindset

Sowohl in den Fachbereichen, als auch bei den IT-Dienstleistern ist es erforderlich, ein generelles Verständnis für die Änderungen durch Nutzung von Cloud-Services sicherzustellen. Die grundlegenden Änderungen betreffen das Verständnis von Cloud als Betriebsmodell statt als Ort der Hardware-Bereitstellung und der Wechsel von Funktionsorientierung hin zu Produktorientierung. Hier sind Lernplattformen und Befähigungsangebot wichtig.

Betriebsmodell der IT-Dienstleister Durch die Vorgabe der DVS sind die IT-Dienstleister verantwortlich dafür, ein Teil der hybriden Multi-Cloud des Bundes zu werden. Generell ist die größte Änderung bei der Cloud-Nutzung nicht eine andere Technologie oder der Ort der Hardware-Bereitstellung, sondern das zwingend andere Betriebsmodell, ohne das Cloud-Dienste nicht effektiv und zielführend genutzt werden können. Hier ist ein Wandel von einem funktionsorientierten hin zu einem produktorientierten Betriebsmodell erforderlich.

Geschwindigkeit und Agilität Die Geschwindigkeit der großen internationalen Cloud-Anbieter bei der Einführung neuer Cloud-Dienste steigt kontinuierlich. Um hier nicht noch weiter den Anschluss zu verlieren, ist eine Adaption der Prinzipien und die Aufnahme in die internen Beschaffungs- und Beauftragungsprozesse zwingend erforderlich. Das betrifft auch die Prozesse für die Beauftragung der IT-Dienstleister, die auf Cloud-Dienste hin optimiert und beschleunigt werden müssen.

Wirtschaftlichkeit / Preis-Leistung Eine Wirtschaftlichkeitsbetrachtung ist Grundlage jedes Beschaffungsprozesses. Das konsequente zu Ende denken der Wirtschaftlichkeit muss auch im Kontext „make or buy“ betrachtet werden, im Zusammenspiel unterschiedlicher Lösungen und Plattformen als auch den Betrieb und Dekommissionierung von Systemen. Hier sollten daher, wie in vielen anderen Ländern auch, nicht ausschließlich Infrastructure as a Service Lösungen in den Fokus kommen, sondern auch Platform as a Service und Software as a Service Lösungen (von spezialisierten Anbietern). Größter Fokuspunkt sollte hierbei auf der großflächigen, ggf. weltweiten Verfügbarkeit liegen – Eigenentwicklungen der Bundesrepublik sind kostenintensiv im Vergleich zur Nutzung von etablierten de-facto Standards, die weltweit in Unternehmen und Organisationen im Einsatz sind. Diese de-facto Standards sind auch Grundlage für mögliche Standardisierungen.

A.M - editiert am 28.11.2023

Antworten ekom21 KGRZ Hessen

Nicht vorhandene oder nicht kompatible Infrastrukturen (z.B. XTA-OSCI Kommunikation, XöV Versionen, ..)

Unzureichende Funktionalitäten oder verspätete Bereitstellung von erforderlichen Basiskomponenten zur Erfüllung der EfA-Mindestanforderungen (Unternehmenskonto, Nutzerkonto, XöV Schemata)

Fehlende Qualitätsstandards für Basiskomponenten

Fehlende Regelungen für die Leistungserbringungen und Verrechnung von Service- und Supportleistungen für nachgenutzte EfA-/OZG-Dienste

Fehlende bundesweite Standardisierung von Anforderungen zum Datenschutz und Informationssicherheit

D.H - original vom 28.11.2023

Die Nutzung der technisch bisweilen unausgereiften und inzwischen nicht mehr zeitgemäßen nationalen bzw. proprietären "Standards" aus der XÖV-Familie sind ein echtes Hindernis für die effiziente (Weiter-) Entwicklung moderner E-Government-Dienste. Hier sollte man dringend Hand anlegen und technische Standards von entsprechenden Experten und nicht von politischen Gremien entwickeln lassen.

H.T - editiert am 10.12.2023

Für medienbruchfreie Abläufe wird die Verwendung von elektronischen Signaturen und Siegeln (fortgeschritten und qualifiziert) notwendig. Zum Thema "Elektronische Identitäten" ist die Informationslage aus meiner Sicht völlig unzureichend, mindestens aber unübersichtlich.

Wenn aus föderalen Gründen eine bundesweite Basiskomponente hier nicht zur Verfügung gestellt werden kann, wäre es dennoch sinnvoll, zumindest auf bundesweit einheitliche Vorgaben/Schnittstellen zu setzen.

Sollte sich das Thema Siegel/Signaturen in den Funktionsbausteinen "verstecken", sollte das vielleicht begrifflich ergänzt werden.

D.H - editiert am 10.12.2023

@OC000024391276, Ihre Einschätzung bzgl. der Nutzung von fortgeschrittenen und qualifizierten elektronischen Signaturen und Siegeln teile ich uneingeschränkt! Siehe auch https://gitlab.opencode.de/bmi/ozg-rahmenarchitektur/zielbild-ozg-rahmenarchitektur/-/issues/145.

Die Situation bei den elektronischen Identitäten ist m.E. gar nicht so sehr unübersichtlich. Ich sehe hier grob drei Punkte:

Personalausweis & Co.

Seit 01. November 2010 wird in Deutschland der Personalausweis mit Online-Ausweisfunktion ausgegeben, welcher zur elektronischen Identifizierung (eID) und datenschutzfreundlichen Authentisierung auf dem Sicherheitsniveau "hoch" gemäß Art. 8 eIDAS-VO genutzt werden kann. Technisch praktisch identisch sind hier übrigens der elektronische Aufenthaltstitel und die Unionsbürgerkarte. Ähnliche elektronische Ausweise gibt es inzwischen in praktisch allen EU-Mitgliedsstaaten. Aktuell gibt es 32 (prä-) notifizierte eID-Systeme von denen bereits 25 EU-weit anerkannt sind. Die verschiedenen Europäischen Ausweissysteme sind technisch sehr unterschiedlich, können aber über eine einheitliche SAML-basierte Schnittstelle akzeptiert werden. Diese Systeme werden teilweise technisch weiter entwickelt, um z.B. die Benutzbarkeit zu verbessern. Beispielsweise arbeitet man im BMI/BSI seit 2021 an der Smart-eID, bei der die Ausweisdaten direkt in einem Chip des Smartphones gespeichert sind und man also gar keine Ausweiskarte mehr benötigt. Parallel dazu wird, motiviert durch die Aktualisierung der eIDAS-VO, im BMI/BSI wie auch im Rest von Europa an der European Digital Identity Wallet (EUDIW) gearbeitet, bei der so genannte Verifiable Credentials mit beliebigen Attributen im Smartphone verarbeitet werden.

Nutzer- und Servicekonten (zukünftig nur noch BundID)

Bislang stellen der Bund (https://id.bund.de/) und fast alle Länder gemäß § 3 (2) OZG im Portalverbund so genannte Nutzerkonten bereit. In BSI TR-03160 wird Servicekonten gesprochen, obwohl das Gleiche gemeint ist. Durch das geplante OZG-Änderungsgesetz wird es voraussichtlich nur noch ein zentrales Bürgerkonto (https://id.bund.de/) beim Bund geben. Einige Länder haben diesen Schritt bereits vollzogen und haben sich für eine Nachnutzung der BundID entschieden. Neben den oben genannten elektronischen Ausweisen und der immer noch unterstützten Authentisierung mit Benutzername und Passwort kann die Anmeldung bei der BundID auch mit einem bereits bei der Steuererklärung genutzten ELSTER-Zertifikat erfolgen. Wie in der BSI TR-03160-2 (Abschnitt 3) festgelegt, nutzen alle diese Nutzer- bzw. Servicekonten den weit verbreiteten SAML v2.0 Standard. Das FINK-Projekt ("Föderiertes Identitätsmanagement interoperabler Nutzerkonten"), für das ein unglaubliches Budget von 5.967.494 Euro pro Jahr vorgesehen wurde, hätte hier insbesondere einen Server zur Bereitstellung von SAML-Metadaten erschaffen sollen. Dass hier heute unter der offenbar vorgesehenen (vgl. Interoperable Servicekonten, Bericht der PG eID-Strategie zum Abschluss der Entwicklung und Migration, V1.0 / 15.01.2020, Abschnitt 4) Einstiegs-URL https://informationsplattform.efink.services/ scheinbar gar nichts zu finden ist, unterstreicht aus meiner Sicht sehr deutlich, wie effektiv der IT-Planungsrat zur effizienten und konstruktiven Weiterentwicklung der deutschen E-Government-Landschaft beizutragen vermag.

Weitere relevante Identitäten (vor allem GesundheitsID)

Neben den oben erläuterten elektronischen Ausweisen (1.) und den Nutzer- und Servicekonten (2.) sollten bei der Weiterentwicklung der BundID weitere relevante Identitäten und Standards berücksichtigt werden. Hier ist allen voran die von der gematik spezifizierte GesundheitsID zu nennen, die ab dem 01.01.2024 auf Grund von § 291 (8) SGB V von allen gesetzlichen Krankenkassen ausgerollt wird und mindestens ein Sicherheitsniveau der Stufe "substanziell" bietet. Die GesundheitsID basiert nicht auf SAML, sondern auf OpenID Connect, so dass die BundID diesbezüglich unter Umständen ergänzt werden sollte. In diesem Zusammenhang sollte auch die wichtige Frage geklärt werden, ob und unter welchen Umständen bei den Krankenkassen, z.B. über die BundID, die SteuerID erfasst und verarbeitet werden darf und ob nicht umgekehrt auch die KVNR, z.B. über die GesundheitsID, in der BundID gespeichert und verarbeitet werden darf. Darüber sollte die BundID im Zuge der Einführung der EUDIW zukünftig auch "Verifiable Credentials" akzeptieren und ausstellen können.

K.G - original vom 07.12.2023

Aus Sicht der VITAKO - Bundesarbeitsgemeinschaft der Kommunalen IT-Dienstleister ist die wichtigste technische wie organisatorische Herausforderung die Etablierung von geeigneten Standards (Schnittstellen, Protokolle, Datenschemata). Darüber hinaus sind die folgenden Herausforderungen zu berücksichtigen: - Die verschiedenen Behörden und Verwaltungen in Deutschland müssen ihre Systeme so gestalten, dass sie miteinander kommunizieren können, um den Austausch von Daten und Informationen zu gewährleisten (Interoperabilität). - Finanzielle Rahmenbedingungen für die Nutzung von EfA-Diensten sowohl einmalig als auch laufend für die nächsten Jahre müssen den Kommunen zur Planung bekannt sein. - Während die technische Anbindung zur Nutzung von EfA-Online-Diensten grundsätzlich geklärt ist, erscheinen die konkreten Arbeiten für viele Kommunen unklar. Hier ist fachliche Unterstützung erforderlich. - Sofern Online-Dienste an Fachverfahren angebunden werden sollen, müssen auch Schnittstellen auf der Ebene der Fachverfahren vorhanden sein. Diese müssen finanziert und eingerichtet werden. Hier sind Standardisierungen durch die EfA-Online-Diensteanbieter erforderlich. - Die OZG-Umsetzung erfordert einen sicheren Austausch von personenbezogenen Daten zwischen Behörden und Bürgern bzw. Unternehmen. Datenschutz- und Datensicherheitsmaßnahmen sind hier zwingende Voraussetzung, um die Vertraulichkeit und Integrität der Daten zu gewährleisten (Datenschutz und Datensicherheit). - Um den Bürger*innen einen einheitlichen und nahtlosen Zugang zu den verschiedenen Verwaltungsdienstleistungen zu ermöglichen, müssen die Prozesse und Verfahren aller Behörden harmonisiert werden. Dies erfordert eine enge Zusammenarbeit und Koordination zwischen den verschiedenen Beteiligten (Prozessharmonisierung). - Die OZG-Anforderungen gelten für alle Behörden auf Bundes-, Landes- und kommunaler Ebene. Die technische Infrastruktur sollte daher skalierbar sein, um den steigenden Datenverkehr und die Anzahl der Nutzer bewältigen zu können (Skalierbarkeit).

A.K - editiert am 20.12.2023

Folgende Überlegungen möchte Red Hat gerne beitragen:

Grundsätzlich sind die organisatorischen Herausforderungen insgesamt deutlich höher zu bewerten als die technischen Herausforderungen.

Als organisatorische Herausforderungen sind zu benennen:

Gemeinsames Verständnis hinsichtlich Aufgaben und Vorgehen.

Umsetzung über mehrere Verwaltungsebenen in einem föderalen Umfeld mit unterschiedlicher Leistungsfähigkeit der jeweiligen Einrichtungen und Körperschaften.

Ressourcenmangel und fehlende Fachkenntnis aufgrund demografischem Wandel und nicht ausreichender / nicht aktueller Ausbildung.

Sicherstellung des Grundrechts auf Datenschutz und informationelle Selbstbestimmung auch gegenüber denjenigen, die Grundrechte generell als hinderlich für den Fortschritt empfinden. Der Schutz eingestufter Informationen sowie personenbezogener Daten stellt insbesondere dann eine Herausforderung dar, wenn nicht die Ressourcen oder das Wissen zur Verfügung stehen, wie dieser Schutz umzusetzen ist.

Entwicklung eines einheitlichen, leistungsfähigen, auf hohem Standard operierenden Sicherheitsmanagements, das der steigenden Bedrohung im Bereich Cyber-Security wirksam entgegensteht.

Fehlendes Wissen über Verwaltungsprozesse (einschl. deutscher Besonderheiten und Rechtsvorschriften) und über bereits erfolgte, erfolgreiche Digitalisierungsvorhaben in In- und Ausland.

Fehlende Kenntnis und Nachnutzung bzw. Integration bestehender, funktionierender Umsetzungen und Best Practices (einschl. Fachverfahren).

Beteiligung und Befähigung/Ertüchtigung aller Beitragenden bzw. Betroffenen.

Vermeiden der Errichtung einer neuen Form von Bürokratie, die sich aus einer zementierten, schlechten oder ggf. nur in Teilen umgesetzten Automatisierung ohne eine Möglichkeit zur menschlichen Einflussnahme (etwa durch eine Clearingstelle) ergibt.

Entwicklung klarer Zielsetzungen und Anforderungen.

Fehlen notwendiger Rahmenbedingungen für die Anwendung agiler Entwicklungsprozesse und kooperativer Vorgehensmodelle / Community-Strukturen (Co-Innovation, Co-Creation etc.).

Transparenz von Projektfortschritt, Budgetierung, Mittelabfluss und Zielerreichung im Rahmen eines übergreifenden Programmmanagements.

Technischen Herausforderungen ergeben sich u.a. wie folgt:

Zeitgleich zur Digitalisierung der Gesellschaft findet ein technologischer Wandel statt ausgehend von weitgehend verteilten Client-Server-Infrastrukturen hin zu zentralen Cloud-Infrastrukturen bzw. Multi-Cloud-Konstrukten, sowie ein Übergang von großen Planungszeiträumen hin zu einem agilen Vorgehen in der Entwicklung. Zudem gewinnen zunehmend Nachhaltigkeitskriterien an Bedeutung.

Technische Standards sind nicht mehr allein auf den nationalen Blickwinkel beschränkt, zunehmend sind diese für eine Interoperabilität auf internationaler Ebene von Bedeutung.

Integration (auch von Bestandsverfahren) und Interoperabilität stellen generell weiterhin die größten technischen Herausforderungen dar.

Für die Interoperabilität muss eine Plattform- und Dienstearchitektur entstehen, die die Bereitstellung und den Zugriff auf zentrale Funktionskomponenten (Beispiel Single-Sign-on über OpenID Connect) mit entsprechendem Service Level und beigestellter Support-Organisation definiert.

Vereinbarte Standards wie XÖV spielen eine wichtige Rolle bei der Interoperabilität, sehen sich jedoch einer Weiterentwicklung der technischen Repräsentation ausgesetzt. Die Einigung auf fachliche Standards sollte in Form eines rein fachlichen Daten- bzw. Informationsmodells getrennt von der aktuellen technischen Repräsentation erfolgen, um die technische Verarbeitung an aktuellen technischen Standards auszurichten.

Die Nutzung zentral bereitgestellter technischer Ressourcen muss sich stark vereinfachen und sich als wirtschaftlich attraktiv erweisen, um auch im kommunalen Umfeld eine interessante Alternative darzustellen.

Die Cloud und ihre Möglichkeiten im Hinblick auf Standardisierung, Konsolidierung und Harmonisierung zu nutzen, stellt viele vor eine nicht unwesentliche Herausforderung, zumal ausgehend von einer bestehenden Betriebslandschaft die zusätzliche Einführung einer Cloud-Infrastruktur erst einmal eine neue, zusätzliche Betriebsumgebung darstellt.

Der Übergang hin zu einem Cloud-first-Vorgehen beinhaltet umfangreiche Veränderungen, wovon auch die Zusammenarbeit im Verbund und mit Software-Partnern betroffen ist.

Paketierung, Deployment-Prozesse sowie Betrieb orientieren sich zunehmend an Cloud- und Container-Architekturen.

Self-Service-Prozesse sind grundsätzlich nützlich und gewünscht, da sie unverzichtbarer Bestandteil einer Effizienzstrategie sind, bedürfen jedoch einer genauen Definition sowie ggf. einer Unterstützung der Anwender.

Eine weitgehende Automatisierung leistet die Übernahme von Routineaufgaben und unterstützt die Skalierung von Workloads, muss jedoch selbst erst einmal anforderungsgerecht und sicher umgesetzt werden.

Neue Technologien bringen ggf. neue Entwicklungs- und Betriebsverfahren mit, die erst zu etablieren sind.

Der Einsatz von Open Source bedarf wie bei jeder anderen Software auch einer Bewertung hinsichtlich Eignung, IT-Sicherheit, Zukunftssicherheit und vorhandenem Support.

IT-Sicherheit und Datenschutz müssen generell den sich aus dem jeweiligen Schutzbedarf ergebenden Anforderungen genügen, auch in einem zunehmend dynamischen Umfeld und unter Einsatz neuer Technologien.

Die zunehmende Bedrohung im Bereich Cyber-Security erfordert neue, hochwirksame Strategien bei der Abwehr dieser Bedrohungen, was zunehmend den Einsatz von Automatisierung und KI als elementarem Bestandteil eines Sicherheitsmanagements mit einschließt.

IT-Sicherheit wird zunehmend ein Bestandteil der einzusetzenden Software im Sinne von Security-by-Design und Security-by-Default (anhand von Pattern wie Zero-Trust, Need-to-Know oder Least-Privilege), und schließt auch Entwicklungsprozesse (DevSecOps) und Lieferketten (Supply Chain Security) mit ein.

Generell sind die Erfahrungen bei der Umsetzung von IT-Sicherheit mit neuen Technologien naturgemäß begrenzt. Nicht immer stehen konkrete Empfehlungen, etwa mit Blick auf die Umsetzung von IT-Grundschutz oder VSA, zur Verfügung. Hier sind zunehmend die Hersteller von Software gefragt.

Die Dynamisierung und Automatisierung von Entwicklungs- und Betriebsprozessen stellt die fortlaufende Nachverfolgung bei der Einhaltung von Vorgaben und Standards - insbesondere hinsichtlich der Einhaltung von IT-Grundschutz-Anforderungen - vor eine Herausforderung. Hier entwickeln sich maschinell abprüfbare Richtlinien (Policies) zum Standard.

Die Auslagerung von Workloads in externe Cloud-Infrastrukturen erfordert eine durchgehende Einordnung dieser Workloads in ein Klassifizierungsschema sowie ggf. zusätzliche Maßnahmen zur Sicherstellung von Vertraulichkeit, Resilienz, Integrität und digitaler Souveränität (etwa über Confidential Computing), die heute noch kaum etabliert sind.

Die Steuerung speziell von Multi-Cloud-Systemen erfordert eine dynamische Governance, um jederzeit die Einhaltung von Standards sowie die Kontrolle über die genutzten Cloud-Services gewährleisten zu können.

Verfahren mit unterschiedlichem Schutzbedarf sowie Bestandsverfahren und neue (cloud-native) Workloads sind ggf. in separierten Betriebsumgebungen mit jeweils angepasstem Service Level zu betreiben.

Bislang eher autark operierende IT-Dienstleister müssen für die zukünftige Aufgabenteilung (z.B. der Bereitstellung von EfA-Lösungen) interoperabel werden und auf gemeinsame zentrale Dienste (wie ein Servicekonto) zurückgreifen.

Zuständigkeiten sind in einer gemeinsam genutzten Cloud-Infrastruktur so abzubilden, dass ein Übergang von einer Fachdomäne zu einer anderen nur kontrolliert und abgesichert möglich ist. Ggf. ist eine Revisionssicherheit erforderlich.

G.B - original vom 28.01.2024

Durch passenden Zuschnitt der technischen Architektur kann es ermöglicht werden im Sinne des Paradigma "zentral Entwickeln - föderiert Betreiben" eine nachhaltige Umsetzung des "Einer für alle" Konzepts zu folgen und die Ausgaben der öffentlichen Hand für die Softwareentwicklung zu senken.

Entwicklung von Möglichkeiten der Beteiligung der Zivilgesellschaft über die digitale Zivilgesellschaft hinaus.

01. Erwartungen an das Zielbild

Datum der Veröffentlichung: 25.10.2023
Anzahl eingegangener Antworten: 46
Issue # in GitLab: #137
Leitfrage 01

Welche Erwartungen haben Sie an ein Zielbild der OZG-Rahmenarchitektur? An welchen Stellen kann das Zielbild zum Einsatz kommen?

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

DIHK.I.K - editiert am 28.11.2023

Diese Frage kann aus meiner Sicht nicht zielführend beantwortet werden, solange nicht ein Entwurf der OZG-Rahmenarchitektur vorgestellt wird, der die Fragen beantwortet:

was meint das BMI genau mit "OZG-Rahmenarchitektur"? Welche Artefakte gehören dazu, welche nicht? Auf welchen Ebenen spielt sich diese "Architektur" ab?

Und welche Erwartungen hat das BMI an diesen Entwurf, welche Ziele hofft es selbst, mit dem Entwurf zu verfolgen?

Dann können die Konsultationsbeteiligten gut antworten - ob sie den Begriff "OZG-Rahmenarchitektur" ähnlich oder wenn nein, wie anders, verstanden hätten - ob der Entwurf aus ihrer Sicht geeignet ist die Erwartungen des BMI zu erfüllen, oder was fehlt /geändert werden muss - ob sie weitere Erwartungen haben, und ob sie denken dass diese mit dem Entwurf erfüllbar sind bzw. was fehlt/geändert werden muss

PS: Unklar ist mir bspw. auch, ob das Zielbild ein Artefakt innerhalb der OZG-Architektur ist, oder ob Zielbild=Architektur

OZG.R - original vom 14.11.2023

Grundsätzlich dient diese Leitfrage zur offenen und unvoreingenommenen Erhebung der Erwartungen der Konsultationsbeteiligten Akteure. Die Spezifizierung und iterative Ausarbeitung des detaillierten Zielbildes der OZG-Rahmenarchitektur findet im Rahmen des Arbeitspaketes des FIT-ABs statt.

Mit freundlichen Grüßen

Ihr OZG-Rahmenarchitektur Team

M.P - editiert am 06.11.2023

Wir erwarten, dass das Zielbild der OZG-Rahmenarchitektur die Bedürfnisse der Bürgerinnen und Bürger angemessen berücksichtigt und sich als dynamisches Zielbild versteht, das sich im Laufe der Zeit weiterentwickelt und anpasst.

Das Zielbild sollte eine umfassende digitale Transformation ermöglichen, indem es sowohl Front-End- als auch Back-End-Prozesse integriert. Es strebt eine konsistente und einheitliche Architektur für Bund, Länder und Kommunen an, die auch die Bereitstellung länder- und bundesweiter Dienste sowie eine Aufteilung der Zuständigkeiten ermöglicht.

Eine ganzheitliche Sichtweise von Diensten bis hin zur Infrastruktur, einschließlich des digitalen Backbones und der Transportnetze, sollte gewährleistet sein. Es sollten Informationen zur Wiederverwendbarkeit von Diensten, zur Skalierbarkeit und zur Interoperabilität zwischen den IT-Systemen und den Verwaltungen von Bund, Ländern und Kommunen bereitgestellt werden. Zur Gewährleistung des Datenschutzes und der Informationssicherheit wird die Implementierung einer integrierten Daten- und IT-Sicherheitsplattform empfohlen.

Eine moderne und skalierbare IT-Sicherheitsplattform umfasst ein Identitäts- und Zugangsmanagement, eine Ende-zu-Ende-Netzwerksicherheit, Datenverschlüsselung und Schwachstellenmanagement. Darüber hinaus sollte sie Mechanismen zur Überwachung und Reaktion auf Sicherheitsvorfälle bieten und die Verwaltung von Sicherheitsinformationen und Ereignissen (SIEM) ermöglichen.

Das Zielbild sollte eine Lösung bieten, die Offenheit, Integration verschiedener Technologien und technologische Interoperabilität mit föderalen Strukturen gewährleistet. Es sollte die Integration von Cloud- und hybriden Lösungen ermöglichen, wobei Dienste sowohl in der Cloud als auch vor Ort bereitgestellt werden können und eine nahtlose Verbindung zwischen ihnen besteht. Ein hoher Automatisierungsgrad ist ebenfalls anzustreben, um die Bereitstellung, Verwaltung, Skalierung und Überwachung der Dienste zu erleichtern.

Zusammenfassend lässt sich sagen, dass das Zielbild eine flexible, offene und interoperable Lösung anstrebt, um den Anforderungen der OZG gerecht zu werden. Es sollte eine ganzheitliche Betrachtung der Architektur ermöglichen und gleichzeitig sicherstellen, dass Datenschutz, Informationssicherheit und Effizienz gewährleistet sind.

Cisco-Issue1-V2

T.G - editiert am 01.11.2023

Das Zielbild für die OZG-Rahmenarchitektur vermittelt eine Vision und setzt fachliche und technische Rahmenbedingungen für die Umsetzung von OZG Leistungen.

IBMs Vision der OZG-Rahmenarchitektur ist fachlich getrieben und ermöglicht Nutzenden unterschiedlicher Gruppen einen einfachen, effizienten und ergonomischen Zugang zu OZG-Leistungen. Sie ist die Basis für eine modulare, komponenten- bzw. baukastenbasierten Architektur und ermöglicht so eine Ende zu Ende Digitalisierung, Optimierung und Automatisierung von Verwaltungsleistungen. Durch die Einhaltung von Standards und offenen Schnittstellen integriert sie sich in vorhandene und zukünftige heterogene Systemumgebungen.

IBM unterstützt den Ansatz der Föderalen IT-Architektur, TOGAF als offenen Standard für Architekturbeschreibungen zu verwenden.

Wir regen an, die (technischen) Bausteine des Zielbildes, um fachliche Bausteine zu ergänzen, um daraus die strategischen Leitplanken (siehe „231024_Konsultationsprozess_Online-Webseminar_I, Seite 7) abzuleiten. Prozessmodelle und fachliche Bausteine sind wesentlicher Bestandteile einer Facharchitektur (TOGAF: Business Architecture).

S.W - editiert am 08.11.2023

Das Zielbild muss klar und deutlich formuliert sein, ohne wesentliche Aspekte der OZG-Umsetzung aus den Augen zu verlieren. Es muss verständlich werden, dass obwohl wir in einem föderalen System existieren, dieses jedoch zugunsten einer gemeinsamen Anstrengung von Bund, Ländern und !Kommunen! für dieses Zielbild hintenangestellt werden muss. D.h. oberstes Ziel sollte hier die konkrete Umsetzung mit einer Plattform für alle sein, bei der die grundlegendsten Bausteine der OZG-Architektur für alle Umsetzungsbeteiligten kostenfrei zur Verfügung stehen (Schnittstellen, Low-Code-Anwendungen, Signaturen, Authentifzierungen, Safe spaces,...) und nach den Prinzipien der Anwenderfreundlichkeit und maximalen Kompatibilität sofort genutzt werden können, um vor allem die vielen kleineren Kommunen unter 10.000 Einwohner_innen in die Lage zu versetzen, ihre Digitalisierung trotz enormen Kapazitätsproblem schnell und effektiv umsetzen zu können. Es muss deutlich werden, dass alle Gebietskörperschaften an einem Strang ziehen müssen, um nicht nur am Ende unzählige Einzellösungen zu haben, sondern es sichergestellt wird, dass egal wo man ist - sei es in Hamburg, Berlin, München oder Köln, Flensburg, Garmisch-Partenkirchen, Schwedt oder Lörrach - man sicher und professionell die gleiche Architektur nutzen kann. Es muss zudem deutlich werden, dass sich der Bund seiner finanziellen und kapazitativen Verantwortung bewusst ist, dass die Länder und vor allem die Kommunen dauerhaft in die Lage versetzt werden müssen, die OZG-Umsetzung erfolgreich zu bewältigen. Dazu werden OZG-Reaction Force Teams bereitgestellt, die zukunftsweisende Technologien in Windeseile bereitstellen und die Fähigkeiten zur Nutzung in großangelegten bundesweiten Workshops vermitteln.

S.M - original vom 03.11.2023

Bundesagentur für Arbeit: Die BA erwartet, dass weiterhin eigenständige Fachportale gibt, die über einen „Kontaktpunkt“ ansteuerbar sind.

Die Anmeldung soll über ein Nutzerkonto mit mehreren Alternativen zur Identifizierung/Authentifizierung möglich sein.

Wie in der Registermodernisierung vorgesehen, erwartet die BA, dass beim Datenaustausch die Daten von der register- bzw. datenführenden Stelle abgerufen werden können (Once-Only). Dieser Datenaustausch soll asynchron sein.

M.S - editiert am 12.01.2024

Aus Sicht der Open Source Business Alliance – Bundesverband für digitale Souveränität e.V. hängt der Erfolg der OZG-Umsetzung und einer schnellen, effizienten und nachhaltigen Verwaltungsdigitalisierung entscheidend vom flächendeckenden Einsatz von Open Source Software, offenen Standards und Referenzimplementierungen für diese offenen Standards ab.

Ein großer Teil der strategischen Architekturrichtlinien in den föderalen IT-Architekturrichtlinien steht mit dieser Position im Einklang (siehe u.a. SR7 „Sicherstellung der Herstellerunabhängigkeit“, SR8 „Einsatz von Open Source“, SR9 „Gewährleistung der Interoperabilität von IT-Lösungen“ und SR10 „Sicherstellung von loser Kopplung/Modularität“).

Unsere Erwartung an das Zielbild ist daher, dass sich diese Punkte aus den strategischen Architekturrichtlinien auch im Zielbild für die gemeinsame OZG-Rahmenarchitektur und in der Entwicklung der konkreten „notwendigen Standards, Schnittstellen sowie zentralen Basisdienste und -komponenten“ wiederfinden. Folgende Punkte möchten wir hierbei besonders hervorheben:

Open Source Software als Standard: In den föderalen IT-Architekturrichtlinien wird u.a. in SR8 „Einsatz von Open Source“ der Vorrang von Open Source Software formuliert: „Open Source Lösungen sind Nicht-Open Source Lösungen vorzuziehen, sofern geeignet und wirtschaftlich“. In der Praxis ist es aber so, dass oftmals weiterhin proprietäre Lösungen beschafft werden, obwohl gleichwertige Open-Source-Lösungen zur Verfügung stünden. Die Gründe hierfür liegen oft in einer Unsicherheit der Beschaffungs- und Vergabestellen, da sie über den in den föderalen IT-Architekturrichtlinien formulierten Vorrang von Open Source nicht informiert sind oder sogar überzeugt sind, eine rechtssichere Beschaffung von Open Source Software sei aus irgendwelchen Gründen grundsätzlich nicht möglich. Das Zielbild für die OZG-Rahmenarchitektur muss diese Diskrepanz zwischen Ziel und Wirklichkeit adressieren und Vorschläge machen oder Hilfestellungen geben, wie in der Praxis der in SR8 formulierte Vorrang von Open Source Software konkret umgesetzt werden kann.

Problematisch ist desweiteren die formulierte Einschränkung „sofern geeignet und wirtschaftlich“. Denn es gibt keine eindeutig verbindliche Definitionen, wann der vorrangige Einsatz von Open Source Software „geeignet und wirtschaftlich“ ist. Daher gibt es hier einen sehr großen Interpretationsspielraum. Anbieter und Behörden könnten sich unterschiedlichste Begründungen einfallen lassen, warum sie von einem vorrangigen Einsatz von Open Source Software sowie der Veröffentlichung des Quellcodes im Einzelfall Abstand nehmen. Das würde auch die Nachnutzung erheblich behindern, was sich wiederum auf die Wirtschaftlichkeit niederschlägt. Ohnehin muss man die Frage stellen, was darunter verstanden werden soll, ob der vorrangige Einsatz von Open Source Software im konkreten Einzelfall „wirtschaftlich“ ist. Aus Sicht der Bürgerinnen und Bürger ergibt sich beim Einsatz von Open Source immer eine bessere Wirtschaftlichkeitsbilanz, da öffentlich finanzierte Software ganz im Sinne von „Public Money, Public Code“ der Allgemeinheit sowie anderen Behörden zur Weiterverwendung zur Verfügung gestellt wird. Open Source Software trägt also erheblich zum Gemeinwohl bei. Die Wiederverwendbarkeit von Open Source Software kommt auch der Privatwirtschaft zugute und hat innovations- und wettbewerbsfördernde Effekte – die sich wiederum positiv auf das Angebot (und die Preise) auswirken, aus dem die öffentliche Hand auswählen kann. Wenn vergleichbare Verwaltungslösungen nicht in jeder Kommune immer wieder von Neuem entwickelt und bezahlt werden müssen, sondern einfach nachgenutzt werden können, ist das zudem ein verantwortungsvoller Umgang mit Steuergeldern. Die Formulierung „sofern geeignet und wirtschaftlich“ sollte also noch einmal auf den Prüfstand gestellt werden. * Verpflichtende offene Standards: Offene Standards sind eine wichtige Voraussetzung zur Sicherstellung von Interoperabilität und zur Vermeidung von Herstellerabhängigkeiten. Sie ermöglichen einen freien Fluss von Informationen und sind daher stets zu fordern und zu fördern. Kompatibilität und Interoperabilität werden mit Open-Source-Hard- und -Software gewährleistet, so dass dadurch ein souveräner Umgang mit Technologien ermöglicht wird. In den föderalen IT-Architekturrichtlinien werden offene Standards nur an zwei Stellen am Rande erwähnt. Für die Erreichung der dort formulierten Ziele wie u.a. „Sicherstellung der Herstellerunabhängigkeit“ und „Gewährleistung der Interoperabilität von IT-Lösungen“ müsste der Einsatz von offenen Standards aber eine deutlich zentralere Rolle einnehmen. Im Zielbild für die OZG-Rahmenarchitektur müssen verpflichtende offene Standards daher ganz besonders berücksichtigt und als Voraussetzung für eine gelingende OZG-Umsetzung sowie eine erfolgreiche föderale IT-Landschaft genannt werden.

Open-Source-Referenzimplementierungen: Damit aus vorgegebenen, veröffentlichten und dokumentierten offenen Standards in der Praxis auch tatsächlich ein interoperables (föderales) System mit verschiedenen, miteinander kompatiblen Lösungen wird, müssen für alle festgelegten offenen Standards immer jeweils auch Open-Source-Referenzimplementierungen der technischen Aspekte eines Standards budgetiert, projektiert und dokumentiert werden. Nur so können Vertreterinnen und Vertreter von Bund, Ländern und Kommunen sowie von Software-Anbietern genau wissen, wie ihre Lösungen auf den entsprechenden Standard passend programmiert sein müssen. Gleichzeitig erleichtert ein solches Vorgehen auch die Nachnutzung und Akzeptanz bereits vorhandener Entwicklungen. Für die praktische Umsetzung der strategischen Architekturrichtlinien SR9 „Gewährleistung der Interoperabilität von IT-Lösungen“ und SR10 „Sicherstellung von loser Kopplung/Modularität“ sind Open-Source-Referenzimplementierungen unerlässlich.

Basisdienste- und Komponenten: Die angestrebte Vereinheitlichung bzw. Zentralisierung von bestimmten Basisdiensten, wie sie im Gesetzentwurf für das Onlinezugangsänderungsgesetz formuliert ist, ist zu begrüßen. Basisdienste wie Bürgerkonto und Postfach sind somit allerdings in Zukunft kritische Infrastruktur für das Funktionieren der gesamten deutschen Verwaltung. Sollten diese einmal nicht funktionieren, wäre die Verwaltung komplett lahmgelegt. Gerade bei den zentral bereitgestellten Basisdiensten dürfen also keine bestehenden Abhängigkeiten fortgeführt oder zementiert werden. Umso wichtiger ist es, gerade bei den im Onlinezugangsänderungsgesetz aufgeführten Basisdiensten Open Source Software zwingend als Standard und als Mindestanforderung für die Sicherung der digitalen Souveränität vorzuschreiben – ebenso wie den Nachweis, dass diese Dienste parallel bei unterschiedlichen Betreibern betrieben werden können.

Offene Zusammenarbeit: Die Open Source Business Alliance unterstützt Prinzipien der Offenheit in allen Bereichen: Open Design, Open Development, Open Community, Open Access, Open Data, etc. Open Source lebt vom Engagement vieler und kann nur durch eine offene Zusammenarbeit seine maximalen Anpassungs- und Gestaltungsmöglichkeiten entfalten. Offene Design- und Entwicklungsprozesse sowie offene Kooperationsräume ermöglichen es Verwaltung, Forschungseinrichtungen, Unternehmen und Zivilgesellschaft, Einfluss auf Technologie zu nehmen und diese gemeinsam zu gestalten. Hierfür ist es entscheidend, dass Verbesserungen an Open-Source-Projekten willkommen sind und durch partizipative Prozesse innerhalb einer offenen Gemeinschaft in das ursprüngliche Projekt zurückfließen können. Diese Aspekte sollten daher auch in das Zielbild der OZG-Rahmenarchitektur einfließen.

Transparenz und Auditierbarkeit: Open Source Software ist eine zentrale Voraussetzung für von allen Interessierten nachvollziehbare IT-Systeme. Ein transparenter Einblick in Software durch dauerhafte, öffentliche Verfügbarkeit der Quellen kann Qualität und Sicherheit entscheidend befördern. Das Verhalten von Software wird so ersichtlich. Dies gilt für Softwaresysteme und Algorithmen ebenso wie für Daten, besonders dort, wo diese im Kontext sogenannter künstlicher Intelligenz eingesetzt werden. Nachvollziehbarkeit kann Sicherheitsrisiken verringern und Diskriminierung vermeiden. Deswegen setzen wir uns für offene Algorithmen und offene Daten ein. Diese Aspekte sollten daher auch in das Zielbild der OZG-Rahmenarchitektur einfließen.

Eine ausführlichere Darstellung unserer Positionen und Forderungen zu den hier genannten Punkten ist in unserer Stellungnahme zum Kabinettsentwurf zum Onlinezugangsänderungsgesetz zu finden: https://osb-alliance.de/wp-content/uploads/2023/06/20230613_OSBA_Stellungnahme_OZG20_Kabinettsentwurf.pdf

Das Zielbild zur OZG-Rahmenarchitektur kann insbesondere immer dann zum Einsatz kommen, wenn die Länder oder Bund und Länder gemeinsam Softwarelösungen entwickeln oder diese interoperabel aufeinander abstimmen wollen. Beispiele hierfür sind insbesondere

Der souveräne Arbeitsplatz für die öffentliche Verwaltung (siehe auch Antwort auf Leitfrage 4)

Die Entwicklung unterschiedlichster EfA-Leistungen

Die im Gesetzentwurf für das Onlinezugangsänderungsgesetz genannten zentralen Basisdienste- und Komponenten sowie zentrale Infrastrukturlösungen

Die Umsetzung der Deutschen Verwaltungscloud-Strategie / Multi-Cloud-Strategie

F.S - original vom 09.11.2023

Nach meinem (= CDO einer Kommune) Verständnis ist Rahmenarchitektur im Sinne von technischem Framework zu interpretieren. Eine OZG-Rahmenarchitektur würde danach über das bisherige System von EfA-Leistungen, die per fitstore oder govconnect bezogen werden können hinausgehen und im Sinne einer niederschwelligen Entwicklungsumgebung die Möglichkeit eröffnen, Lösungen (z.B. per Open Source - Lowcode - Ansatz) für sich maßzuschneidern und über ein Repository verfügbar zu machen. Es könnte sich also z.B. um eine Plattform zur Nutzung des Modul F oder des OZG-Hub (jeweils mit vorgeschalteter Sandbox) handeln.

H.T - editiert am 28.11.2023

Das Zielbild sollte sich auch mit begrifflichen Standards auseinandersetzen. Das Organisationskonto firmierte aus Sicht einer bayerischen Kommune innerhalb von zwei Jahren unter den Begriffen "Mein Unternehmensportal", "Mein Unternehmenskonto" und heißt jetzt "Unternehmensplattform Deutschland". Womöglich gab es in anderen Bundesländern weitere Begriffe.

Ähnlich die Bezeichnung für die Nutzerkonten, die auch Bürgerkonten (so heißt auch ein Produkt der Sparkassen),Servicekonto oder BundID heißen.

In einer Rahmenarchitektur sollten daher auch bundesweit einheitliche Begriffe etabliert werden. Schließlich sollen sich die Bürgerinnen und Bürger auch bei Nutzung von Verwaltungsleistungen außerhalb ihres Heimatortes gleichermaßen schnell zurecht finden.

Die Entscheidung, die Nutzerkonten der Länder einheitlich in der die BundID, gerne auch DeutschlandID oder wie auch immer zusammenzufassen, ist zu begrüßen.

A.S - editiert am 10.11.2023

Welche Erwartungen habe ich an das Zielbild?

Die größte Erwartung ist eine Vision. Eine das Zielbild der OZG-Rahmenarchitektur, sei sie nun technisch, organisatorisch oder sonstiges, darf nicht lediglich auf das fokussieren, was bereits vorhanden ist. Im Gegenteil, darf das Zielbild damit zwar gefüllt werden, muss sich jedoch an den tatsächlichen Bedarfen messen lassen. Es soll eben ein Zielbild sein, welches eine zukünftige Version der Verwaltungsarchitektur im OZG-Rahmen darstellt. Das vielleicht vorab.

Ganz konkret sind verschiedenste Punkte für den Erfolg und auch bisherigen Misserfolg der OZG-Umsetzung aufzugreifen und mit Zielvorstellungen zu belegen.

[x] Das oberste Ziel sollte die Vision einer einheitlichen, modernen, robusten, skalierbaren und offenen OZG-Architektur sein.

[x] Das Zielbild sollte sich daran orientieren als Grundskizze und Basismodel für die Entwicklung von OZG-Leistungen und E-Governmentanwendungen einsetzbar zu sein.

[x] Ein Zielbild sollte einen Fokus aufPrinzipien und Pattern im Rahmen der IT-verwaltungsrechtlichen Rahmenbedingungen anstatt konkreter Bausteine setzen.

[x] Das Zielbild kann und sollte auch aus den Fehlern und Hürden des bisher zurückgelegten Weges lernen.

[x] Das Zielbild darf zentrale E-Governmentfragen (auch ozg-übergreifend) nicht aus den Augen verlieren. Bspw: Wie wollen wir Datenaustausch zwischen Behörden modern und skalierbar standardisieren? Wie lösen wir die Schnittstellenfrage? Wie lassen sich zentrale Basiskomponenten wie API-Gateways, Integration Middlewares etc. flankiert von Open-Source Gedanken als kostenfreie Bausteine für alle Verwaltungen (bund, länder, kommunen) bereitstellen?

[x] Das Zielbild sollte auch für sekundär gelagerte Themen wie IT-Sicherheitskonzeptionen und integriertem Datenschutz (privacy by design) Antworten bereithalten.

An welcher Stelle sollte ein Zielbild zum Einsatz kommen?

Entwicklung von E-Governmentanwendungen

Entwicklung von zentralen Basiskomponenten

Beauftragung von DL für Consulting und Beratung der Behörden zur IT-Infrastruktur/IT-Architektur

Als Basis für die Erarbeitung der komplettierten OZG-Rahmenarchitektur

T.B - editiert am 12.01.2024

Ein Zielbild der OZG-Rahmenarchitektur setzt fachliche technische Rahmenbedingungen und skizziert ein in sich funktionierendes, aufeinander abgestimmten und zukünftige Neuerungen berücksichtigendes Gesamtartefakt. Es sollten alle Standards, Richtlinien und technische Module aufgezeigt werden (bspw. XTA/OSCI, FIT-Connect, XBezahldienste, SDG, OOTS, NOOTS, usw.). Zusätzlich sollten Zukunftsthemen mit skizziert werden (Anbindung Register im Zuge Registermodernisierung) und aktuelle/zukünftige Herausforderungen mit dargestellt werden (Rückkanal, Interoperabilität, Datenminimierung, IT-Security, IT-Governance). Es sollte eine Art Single-Source-of-Truth darstellen, die man nutzt, um "schnell etwas nachschauen zu können" oder auf einem Blick ein Verständnis der Gesamtarchitektur gewinnen zu können.

M.N.AKDB - editiert am 12.01.2024

Wir erwarten, dass das Zielbild der OZG-Rahmenarchitektur eine dynamische und anpassungsfähige digitale Transformation ermöglicht, die Front-End- und Back-End-Prozesse nahtlos integriert und eine einheitliche Architektur für Bund, Länder und Kommunen schafft und dabei auf die Vision von "Digital Only" einzahlt. Dabei liegt ein besonderer Fokus auf dem Datenschutz und der Informationssicherheit durch die Implementierung einer umfassenden IT-Sicherheitsplattform. Zudem wird eine technologische Offenheit und Integration verschiedener Technologien, einschließlich Cloud- und hybriden Lösungen, erwartet, um Interoperabilität und Automatisierung zu unterstützen. Das Zielbild muss klar und deutlich sowie handlungsauslösend formuliert sein.

Konkret sind dabei zu beachten, das in den aktuellen Föderalen Architekturrichtlinien (Version 1.0 vom 29.10.2021) wird als strategisches Ziel S1 die Digitale Souveränität berücksichtigt ist. Der dort referenzierte Beschluss 2021/09 des IT-Planungsrats war zugleich der Startschuss für die Deutsche Verwaltungscloud-Strategie (DVS). Wir erwarten, dass die daraus resultierende Deutsche Verwaltungscloud (DVC) ein Bestandteil der OZG-Rahmenarchitektur werden wird.

Weiterhin hegen wir die Erwartung, dass die vom IT-Planungsrat in seiner 42. Sitzung beschlossene föderale Digitalstrategie Maßstab für das Zielbild der OZG-Rahmenarchitektur wird und damit zur besseren Strukturierung und Orientierung der gemeinsamen Verwaltungsdigitalisierung beiträgt.

D.T.OZG.S - editiert am 12.01.2024

Grundsätzlich sollte das Zielbild der OZG-Rahmenarchitektur dazu dienen die flächendeckende, medienbruchfreie Ende-zu-Ende (E2E) Umsetzung des OZG und damit die Digitalisierung der deutschen Verwaltung zu beschleunigen. Sie sollte klare Ziele und Prinzipien für die föderale IT-Architektur definieren, die von den beteiligten Parteien des OZG verstanden und umgesetzt werden.

Dieses Zielbild bildet somit die technisch-architektonische Voraussetzung für eine erfolgreiche Umsetzung bzw. legt ihre Rahmenbedingungen fest. Sie muss darauf ausgerichtet sein, eine umfassende und zukunftsfähige Grundlage für die Modernisierung der digitalen Verwaltung in Deutschland zu schaffen. In diesem Zusammenhang sollte die Referenzarchitektur die aktuellen Ziele einer E2E-Digitalisierung genauso berücksichtigen wie das Fernziel einer proaktiven Verwaltung, die datengetrieben die Potentiale digitalisierter Antragsstrecken, Fachverfahren und Register nutzt, um sowohl Kunden als auch Verwaltungsmitarbeiter durch Automatisierung nachhaltig zu entlasten. So sollte es die OZG-Rahmenarchitektur ermöglichen, öffentliche Leistungen einfach und insbesondere sicher anzubieten. Dabei ist es imperativ, dass die OZG- Rahmenarchitektur nicht allein auf bestehende Systeme und veraltete Schnittstellenmodelle aufsetzt. Nur mit einem modernen OZG-Zielbild wird es möglich sein, Verwaltungsprozesse zu automatisieren und die Dienste effizient in Wertschöpfungsketten zu integrieren, was derzeit noch nicht vollständig realisierbar ist.

Aus Sicht der Deutschen Telekom sollte das Zielbild der OZG-Rahmenarchitektur unter den folgenden Prämissen entwickelt und fortgeschrieben werden:

Kontinuität und Governance: Eine kontinuierliche Fortschreibung der OZG-Rahmenarchitektur ist einzuplanen, um mit dem organisatorischen und technischen Fortschritt (Innovationskraft der internationalen IT-Wirtschaft) mitzuhalten und auf sich ändernde Rahmenbedingungen (technisch, rechtlich etc.) reagieren zu können. In diesem Zusammenhang ist auch der Konsultationsprozess mit den wesentlichen Stakeholdern zu verstetigen, um einen offenen, transparenten Dialog zu gewährleisten. Die Entwicklung (und Umsetzung) der Architektur sollte dabei mittels eines modernen, agilen Governance-Modells gesteuert werden – ältere EAM-Modelle sollten hingegen kritisch überdacht werden.

Versionierung und Zukunftsorientierung: Eine Versionierung der OZG-Rahmenarchitektur und ihrer einzelnen Architekturbausteine ist anzustreben, um trotz des kontinuierlichen Fortschreibens eine Planungssicherheit für realisierte und in Betrieb befindlich Implementierungen zu gewährleisten. Dabei sollte zwischen dem aktuellen Stand der eingesetzten Bausteine und einem zukünftigen Soll-Zustand der Rahmenarchitektur unterschieden werden, um einerseits den derzeitigen Status Quo abzubilden und es andererseits den Stakeholdern zu ermöglichen, sich auf ein gemeinsames Zielbild der zukünftigen OZG-Rahmenarchitektur zu verständigen.

Standardisierung und Interoperabilität: Im Zielbild sind insbesondere Festlegungen von Standards bezüglich der Kommunikation und der Datenformate einzuplanen. Dies ermöglicht die Etablierung einer föderalen modularen Architektur und Schaffung einer Grundlage für die Digitalisierung von Leistungen über verschiedene Verwaltungsebenen hinweg. Dabei sollten die bestehenden Standardisierungsvorhaben (z. B. XÖV) konsequent weiterentwickelt und ergänzt werden. Zentral definierte Architekturbausteine (Prozesse/ Anwendungen/ Technologien) sollten harmonisiert werden. Die Harmonisierung kann mithilfe interoperabler und standardisierter Systeme oder zentral bereitgestellter Basiskomponenten umgesetzt werden. Allerdings ist die Festlegung deutschlandspezifischer Standards und Rahmenbedingungen in der OZG-Rahmenarchitektur nur dann anzustreben, wenn keine nachnutzbaren internationalen oder europäischen Standards verfügbar sind.

Sicherheit und Datenschutz: Datenschutz und Sicherheit haben einen zentralen Stellenwert für die Zielarchitektur der OZG-Dienste. Die Einhaltung höchster Standards zum Schutz personenbezogener Daten ist von entscheidender Bedeutung. Darüber hinaus steht auch der berechtigte Anspruch von Bürgerinnen und Bürgern auf Selbst-Souveränität im Mittelpunkt. Die OZG-Rahmenarchitektur ist so zu gestalten, dass zu Beginn eines jeden digitalen Prozesses die sichere Identifikation und Authentifizierung der Nutzenden steht. Moderne Konzepte dezentraler Identitätslösungen und EUDI sollten damit integraler Bestandteil der Sicherheitsstrategie sein, sodass vom BMI / BSI zugelassene ID-Wallet-Systeme und kompatible EUDI-Wallets als Identitätsgeber einbezogen werden müssen. Als zentraler Vertrauensanker dienen dabei offizielle Ausweispapiere wie der Personalausweis bzw. Aufenthaltstitel, die mit der EU-Vertrauensliste verknüpft sind und über eID-Verfahren kryptografisch gesichert in europaweiten interoperablen ID-Wallets abgelegt werden. Die in diesem Zusammenhang notwendigen Komponenten müssen in einer Rahmenarchitektur mitgedacht werden: Sowohl eine ID-Wallet-App des Nutzers als auch „Custodial” Wallets, die im Backend-System eines vertrauenswürdigen ID-Wallet-Operators in einer hochsicheren und souveränen in Deutschland gehosteten Cloud-Umgebung betrieben werden. Confidential Computing zur sicheren Speicherung von digitalen Nachweisen und Ausweispapieren in interoperablen Formaten wie W3C VerifiableCredentials (VCs) sehen wir als Grundvoraussetzung einer sicheren, interoperablen und datenschutzkonformen Lösung an. Gerade hier sollten im Sinne der Vertrauensbildung Open Source Ansätze genutzt werden. Gleiches gilt für die Software des Identitätsherausgebers (ID-Issuers), die die Identität einer Bürgerin/eines Bürgers mit ID-Attributen wie Bund-ID, Bank-ID, Steuer-ID oder Mobilfunknummer ergänzt und als sichere Nachweise in den Wallets verfügbar macht, um auch die Prinzipien der Once-Only Anforderung der EU gerecht zu werden

Betriebsfähigkeit und Nachhaltigkeit: In Übereinstimmung mit den vorgenannten Prinzipien sollte das Zielbild eine Struktur vorgeben, die sicherstellt, dass digitale Dienste und Komponenten wiederverwendbar sind, dabei jedoch erforderliche Anpassungen einzelner Diensteanbieter berücksichtigen kann. Zusätzlich sollte ein modernes Zielbild den Aspekt der effizienten Ressourcennutzung und Energieeffizienz als separaten Teil formulieren, um sicherzustellen, dass Dienste Energie und Ressourcen nur in angemessenem Umfang verbrauchen.

Angesichts all dieser Anforderungen hat die OZG-Rahmenarchitektur darüber hinaus eine Ausgewogenheit zwischen den unterschiedlichen Ausprägungen von IT-Strategie bzw. IT-Philosophie zu gewährleisten (z. B. Open Source vs. Proprietär; Standard vs. Individuell; Agil vs. Wasserfall; on premise vs. Cloud). Sie sollte einerseits einen Handlungsrahmen vorgeben und andererseits im Sinne einer sicheren und souveränen Architektur für die Verwaltung keine unnötigen Einschränkungen machen. Genau so wenig darf sie außer Acht lassen, dass in den letzten Jahren bereits große Anstrengungen und Investitionen in den Auf- und Ausbau von Standards, Basiskomponenten, Architekturen, OZG- und EfA-Prozessen unternommen wurden. Das Zielbild kann und sollte deshalb nicht auf der „grünen Wiese“ entstehen, sondern von den bereits geschaffenen Rahmenbedingungen ausgehen, diese im Einzelfall hinterfragen und gegebenenfalls verbessern bzw. konsolidieren, zusammenfassen und erweitern.

Vielfältige Einsatzszenarien des Zielbildes der OZG-Rahmenarchitektur können aus den auch in Leitfrage 3 diskutierten Stakeholdern abgeleitet werden. So wird deutlich, dass die OZG-Architektur verschiedene Interessensgruppen ansprechen kann. Dafür sollte es möglich sein, die Rahmenarchitektur aus unterschiedlichen Perspektiven, zugeschnitten auf die Bedürfnisse einzelner Akteure zu formulieren, sodass sichergestellt ist, dass das Zielbild für alle Beteiligte transparent und zugänglich ist.

Allerdings bietet es sich an auf die Hauptnutzer der OZG-Rahmenarchitektur zu fokussieren. Dies sind diejenigen Akteure, die am eigentlichen praktischen Ausbau und Betrieb der digitalisierten Verwaltung in Deutschland beteiligt sind. Hier sind insbesondere die IT-Dienstleister der Verwaltung in Bund, Ländern und Kommunen zu nennen, die verantwortlich die OZG-Rahmenarchitektur mittels Hard- und Software (on premise oder in der Cloud), Netzen, Schnittstellen und Serviceprozessen mit eigenem und externem Personal praktisch umsetzen und operativ betreiben.

Aus Sicht der Deutschen Telekom ergeben sich damit folgende Nutzungsszenarien:

Erstellung und Fortschreibung IT-Dienstleister-spezifischer OZG-Rahmenarchitekturen unter Berücksichtigung der jeweils fallspezifischen Rahmenbedingungen, orientiert an den bestehenden und avisierten Architekturkomponenten

Ableitung von Anbindungs- und Integrationsszenarien an zentral bereitgestellte und betriebene OZG-Basiskomponenten

Vereinfachung der Ausschreibung von Architekturkomponenten unter Referenzierung auf die OZG-Rahmenarchitektur für ein einheitliches Verständnis von Leistungsbeschreibungen und Kriterienkatalogen auf Auftraggeber- und Auftragnehmerseite

Unterstützung bei der Entwicklung oder Implementierung von OZG-Basiskomponenten im Eigenbetrieb

Etablierung durchgängiger Serviceprozesse mit Ende-zu-Ende abgesicherten technischen und prozessualen Servicestrukturen

Förderung der proaktiven Weiterentwicklung von Dienstleistungen und Produkten in der freien Wirtschaft unter Einhaltung der Vorgaben der OZG-Rahmenarchitektur

Schulung und Ausbildung von Mitarbeitern auf Grundlage der OZG-Rahmenarchitektur

Einbringung der Interessen der deutschen Verwaltung in europäische und internationale, Gesetzgebungs-, Standardisierung- bzw. Normierungsgremien

Orientierung- und Prüfbasis für den frühzeiteigen Digitalcheck von Gesetzen im Rahmen laufender Gesetzgebungsverfahren und Ausgangspunkt für Gesetzesinitiativen zur Berücksichtigung der Möglichkeiten neuer Technologieansätze wie zum Beispiel KI-gestützte Verfahren

Frage01_OZGRahmenArchitektur_Konsultationsprozess

P.S - original vom 17.11.2023

Wir erwarten, dass das Zielbild der OZG-Rahmenarchitektur die folgenden Merkmale besitzt:

Verbindliche Orientierung ohne Einschränkung durch aktuelle, überwindbare Hindernisse

Die Rahmenarchitektur dient als in die Zukunft gerichteter „Leuchtturm“, an dem sich die Aktivitäten zur Umsetzung des OZG verbindlich orientieren. Sie ist weitestgehend unabhängig von aktuellen technischen und organisatorischen Hindernissen (vgl. Leitfrage 2). „Weitestgehend“ meint, dass Hindernisse, die unveränderlich sind, transparent gemacht wurden und behandelt sind. - Betrachtung von Migrationsszenarien zur Überwindung aktueller Hindernisse

Die Migration bestehender Architekturen zur Umsetzung der Rahmenarchitektur – verbunden mit der Überwindung von aktuellen Hindernissen – muss ergänzend betrachtet werden, um die Umsetzbarkeit der Rahmenarchitektur sicherzustellen und die Akzeptanz zu erhöhen.

Ende-zu-Ende-Digitalisierung

Das Rahmenarchitektur muss die ganzheitliche Ende-zu-Ende-Digitalisierung mit einem OZG-Reifegrad 4 adressieren. Dazu müssen neben den Zugängen zu den Verwaltungsleistungen auch deren vollständig digitale Abwicklung berücksichtigt sein, z. B. die Anschlussbedingungen aus der Registermodernisierung und Hilfestellungen zur Förderung der organisatorischen, fachlichen, technischen und rechtlichen Interoperabilität der Verfahren. - Abbildbarkeit auf europäische Vorhaben

Die Rahmenarchitektur muss die relevanten europäischen Vorhaben und Regelungen (bspw. SDG-VO) benennen und klar aufzeigen, wie diese berücksichtigt sind. - Beschreibung von Annahmen und Rahmenbedingungen

Die Rahmenarchitektur muss klar definieren, von welchen Annahmen und Rahmenbedingungen sie ausgeht (Beispiele könnten sein: abgeschlossene Umsetzung des IDNrG und Aufbau des IVÖV). - Definition des Geltungsbereichs (Scoping)

Die Rahmenarchitektur definiert eindeutig, in welchen Kontexten sie – im Idealfall verbindlich – einzusetzen ist und in welchen nicht. - Definition unterschiedlicher Sichten

Der erfolgreiche Entwurf und die erfolgreiche Kommunikation von Architekturen hängen maßgeblich von deren Dokumentation aus bedarfsträgergerechten Sichten ab. Die Rahmenarchitektur sollte fachliche/funktionale, technische, infrastrukturelle (auch Netze), organisatorische und rechtliche Aspekte betrachten. - Begleitende Steuerung und Durchsetzung

Die Rahmenarchitektur wird von einer ganzheitlichen Governance begleitet. Es ist klar definiert, wie die Weiterentwicklung, Umsetzung und Überwachung der Einhaltung der Rahmenarchitektur erfolgt. Der Fortschritt der Umsetzung ist transparent.

D.K - editiert am 19.11.2023

Unsere Erwartungen an ein Zielbild der OZG-Rahmenarchitektur ist eine klare und umfassende Vision für die Umsetzung der digitalen Verwaltung in Deutschland und sind eng mit unseren Grundsätzen verbunden, die da lauten:

Open Source: Der Einsatz von offener Software, um Flexibilität und Transparenz zu gewährleisten, ist unersetzlich. Wir sind davon überzeugt, dass die Zusammenarbeit im OZG-Kontext davon profitieren wird. Gerade im Sinne der Nachnutzung und wenn der Anspruch der Leistung „Einer-für-alle“ flächendeckend und ökonomisch sinnvoll umgesetzt werden soll, ist der Einsatz von Open Source Software dringend erforderlich, ganz im Sinne von „public money, public code!“ Durch offene Quelltexte können auch Sicherheitsrisiken gesenkt werden, da ein offener Blick in die Quellcodes möglich ist und Fehler schneller gefunden werden können.

Open Data: Die Bereitstellung von offenen Daten ist der Schlüssel zur Schaffung eines datengetriebenen, effektiven Verwaltungssystems. Dieser Aspekt sollte auch in der OZG-Rahmenarchitektur daher berücksichtigt werden, um einen Ökosystem-Ansatz zu ermöglichen.

Open Documentation: Eine klare und offene Dokumentation ist unerlässlich, um die Kommunikation und den Wissenstransfer in diesem komplexen Umfeld zu verbessern. Es ermöglicht allen Beteiligten die notwendigen Verfahren an ihre Bedürfnisse und die Bedürfnisse der Verwaltung anzupassen. Durch die offen zugängliche Dokumentation von Architekturkomponenten und Schnittstellen wird allen Beteiligten ein nachvollziehbarer Einblick in die Software gewährleistet. Davon profitiert nicht nur der Staat, der dadurch Vertrauen schafft und einen erheblichen Schritt in Richtung der Digitalen Souveränität geht.

Open Standards: Die Verwendung von offenen Standards sichert eine interoperable IT-Landschaft im öffentlichen Sektor und fördert die Entwicklung von innovativen Lösungen. Ebenso vermeiden sie für den Staat Abhängigkeiten von einzelnen Herstellern und sind wichtig, um eine digitale Souveränität zu erreichen. Der Staat darf sich nicht von einzelnen Herstellern abhängig machen und Im Zielbild der OZG-Rahmenarchitektur müssen daher offene Standards als Voraussetzung für eine erfolgreiche Umsetzung des OZG benannt werden.

Open API: Offene Schnittstellen sind der Schlüssel zur Integration und zur Schaffung einer nahtlosen, benutzerfreundlichen Verwaltung. Ebenso bieten sie im Sinne des Einer-für-Alle-Prinzips die Möglichkeit zur effektiven Nachnutzung und sind dadurch auch ökonomisch sinnvoll.

Die oben genannten fünf Kriterien sind die Grundpfeiler für eine zukunftsorientierte, effiziente und nutzerzentrierte öffentliche Verwaltung. Diese sollten sich entsprechend im Zielbild wiederfinden. Das Zielbild sollte die Anforderungen und Bedürfnisse der Bundesländer, Kommunen und weiterer beteiligter Akteure berücksichtigen und eine einheitliche, interoperable Architektur skizzieren. Es sollte die Grundlage für eine einheitliche und interoperable IT-Landschaft schaffen, die die Kommunikation und den Datenaustausch zwischen Bund, Ländern und Kommunen effizient unterstützt. Es kann bei der Planung und Umsetzung von Digitalisierungsprojekten auf Bundes- und Landesebene, sowie als Grundlage für die Auswahl von Softwarelösungen und die Gestaltung von Schnittstellen und bei der Erstellung von Fachkonzepten und Lösungsarchitekturen zum Einsatz kommen. Ebenfalls sollte es als Grundlage für die Kommunikation und Abstimmung zwischen den verschiedenen Ebenen der Verwaltung dienen.

D.S - original vom 19.11.2023

Das Zielbild sollte aufzeigen, wie idealer Weise die Architektur von Anwendungen und Transport von Daten langfristig aussehen soll. Dabei ist eine Detailtiefe zu vermeiden, da die technische Entwicklung der kommenden Jahre durch fortlaufende Innovationen kaum vorauszusagen ist. Wir brauchen hier Flexibilität, um auf aktuelle Entwicklungen reagieren und neue bisher unbekannte Wege zur Erreichung des Zielbildes entwickeln zu können. Um innerhalb des Prozesses eine ausreichende Planungssicherheit zu gewährleisten sollten Details daher in Etappen geplant werden. Die Etappen-Ziele sollten aber nicht Inhalt des Gesamt-Zielbildes sein, sondern jeweils zu Beginn einer Etappe geplant werden. Bei der Etappenplanung ist das Zielbild der Kompass, welcher anzeigt, ob die Etappenplanung in die Richtige Richtung läuft. Das Zielbild kann auch Leitplanken setzen (welche aber nicht zu eng definiert sein dürfen), um eine zu große Varianz bei den Lösungswegen zu vermeiden.

B.R - original vom 20.11.2023

Die OZG-Rahmenarchitektur sollte einen einheitlichen Rahmen für die Umsetzung der End-to-End Digitalisierung in den Verwaltungsbehörden schaffen. Dazu gehört eine einheitliche Lösung für die Kommunikation mit dem Bürger, sowohl vom Bürger an die Behörde, als auch von der Behörde an den Bürger (z.B. service-bw, sicherer Mailverkehr, Datenaustausch und Bereithaltung, Once-Only Prinzip etc.), für die Identifikation (z.B. eID, Signatur, etc.), Bezahlvorgänge (ePayment), so dass dann die weitere digitale Bearbeitung im Haus mit Fachverfahren, RPA etc. umgesetzt werden kann. Dieser einheitliche Rahmen sollte idealerweise bundeseinheitlich Lösungen anbieten, z.B. beim Zugang für den Bürger. Es benötigt weiterhin klare Schnittstellenbeschreibungen für die Anbindung der Online-Anträge an Fachverfahren, wie diese zu implementieren und entwickeln sind.

TSA.S.W - original vom 20.11.2023

Die Erwartung an ein Zielbild der OZG-Rahmenarchitektur als TSA Public Service GmbH ist zunächst die Definition der organisatorischen und technischen Architektur zur Umsetzung des OZG.

Dabei sollte ein ausschließlich ein Rahmenwerk vorgegeben werden, das keine inhaltlichen oder fachlichen Vorgaben beschreibt. Dies betrifft insbesondere Festlegungen auf Lizenzarten, Dienstleister oder Hersteller, denn der Fokus der Rahmenarchitektur sollte auf der Praktikabilität von Lösungen liegen. Um dies zu unterstützen, sollte die verbindliche Anwendung von Standards Teil des Rahmenwerks sein.

In einem weiteren Fokus ist es notwendig, über das Rahmenwerk zum einen Augenhöhe zwischen den verschiedenen föderalen Ebenen herzustellen als auch zwischen der Verwaltung und den Praktikern beteiligter Unternehmen und Verbände.

M.M - editiert am 21.11.2023

Klare Definition der Hauptakteure:

vom "Kunden" (Bürger, Firma, Verein, ...) her denken und den Prozess eigentlich für diesen passend machen. Hier soll man sich doch nicht erst zusammensuchen müssen, was relevant ist, sondern anfangen mit “ich will …” und bekommt dann alles, was man dazu braucht. ich will nicht, dass Gesetze und Verordnungen bestimmen, wie die Umsetzung konkret aussieht, sondern dass der Bedarf vorgibt, wie die Lösung aussehen kann. An der Stelle brauche ich dann die semantische Interop. und durchgängige Digitalisierung, weil ich nur damit schnell auf geänderte Anforderungen der Kunden reagieren kann und passende Prozesse/Oberflächen/… erstellen kann.

Verwaltungsmitarbeiter sollte nicht vergessen werden. Diese handeln immer auf der Grundlage von Gesetzen und benötigt geeignetes Werkzeug.

Anbieter von Verwaltungsdienstleistungen haben zwar jeweils ein Monopol, aber eben auch eine Verpflichtung.

Unterstützung kleiner Firmen und Startups

mit offenen Standards vom Gesetzestext zur Ende-2-Ende digitalisierten Leistung

FIM als Basis für die Zusammenarbeit verankern. Ausgehend von Stamminformationen lassen sich belastbare und rechtssichere Entwürfe für Referenzimplementierungen und efA-Dienste erstellen, deren Nachnutzbarkeit bereits auf konzeptioneller Ebene gewährleistet ist.

FIM um Entscheidungsebene erweitern mittels RuleMapping

Datenübertragung mittels FitConnect

semantische Interoperabilität gewährleisten durch Beschreibung und Verknüpfung von Wissen über die Leistungen der öffentlichen Verwaltung, deren Gesetzesgrundlagen und der dazugehörigen technischen Ebene

FIM-Stammprozesse liefern eine maschinenlesbare Beschreibung von Verwaltungshandeln und der dafür benötigten Datenstrukturen über Referenzen auf Dokumentensteckbriefe, Stammdatenschemata oder sogar Feldgruppen. Die in FIM-Stammdatenschemate benutzten Gruppen und vor allem Felder sind zu großen Teilen domainübergreifend harmonisiert und gleiche Datenstrukturen in verschiedenen Dokumenten sind deshalb bereits heute als gleich zu erkennen. Ergänzungen durch Wissensgraphen, die u.a. auf diese Elemente referenzieren, können den Kontext erklären und beim weiteren Entwurf unter Nutzung technisch harmonisierter Elemente unterstützen.

Veröffentlichung des Zielbildes als OpenData und OpenAccess

Meine Erwartung wäre insb. kein statisches, sondern ein lebendes Dokument. Digitalisierung und damit auch das OZG ist ein recht dynamisches Feld, in dem Dokumente, die in langwierig Prozessen entstanden sind, oft schon bei Veröffentlichung überholt sind. Es braucht hier also Prozesse, um Änderungen im breiten Konsens durchführen zu können. Das erhält die Praxisrelevanz und Akzeptanz der verschiedenen Stakeholder.

Zum Einsatz sollte ein solches Leitbild an allen Stellen im Lebenszyklus von Prozessen. Nicht nur in der Umsetzung, sondern eben auch schon dort, wo Prozesse bzw. Vorschriften entwickelt oder definiert werden werden. Das schließt insb. auch die Gesetzgebung mit ein. Hier sollen keine Vorgaben gemacht werden, die die Ziele des Zielbildes behindern oder verhindern könnten.

S.H - original vom 20.11.2023

Aus kommunaler Sicht, Großstadt 750.000 Einw.:

Das Zielbild muss für alle umzusetzenden Stellen als eine Richtlinie gelten, die auch realistisch umsetzbar ist. Auf allen föderalen Ebenen.

Derzeit existiert überwiegend auf kommunaler Ebene kein Architekturmanagement, die solche Richtlinien verstehen und in Umsetzung übersetzen können. Daher: Eine Hilfe zur Umsetzung sollte an die Hand geben. Man sollte nicht davon ausgehen, dass alle dieselbe „Sprache“ sprechen. -Wenn Richtlinien top down nicht verpflichtend werden, wird es bei Fragmentierung bleiben. Eine Governance muss sicherstellen, dass diese Richtlinien bis in kleinste Fachbereiche in den Kommunen verpflichtend werden. Regulierung vs. Föderalismus vs. Flexibilität und Innovation?

Offenheit in technischen Tools - Raum für Freiheit und Anpassbarkeit im Rahmen von Standards ermöglichen.

Übersicht und Wiederverwendbarkeit. Nutzung von denselben Artefakten schon in Planungs- und Modellierungsprozessen. Nachvollziehbare, nachlesbare Referenzarchitekturen und- Artefakte Bspw. Liste von aktuellen und geplanten Schnittstellen, die zu bedienen sind. In einer Mandantenfähigen Repository nachlesbar.

Bereits auf Fachressortebene in Bund/Land drauf achten, dass weniger Übersetzungsarbeit im Nachgang geleistet werden muss, in dem bereits bei Formulierungen durch IT-Architekten (als Übersetzer) mit am Tisch sichergestellt wird, dass verständliches Vokabular in den „Fachlichkeit“ als auch „IT-Sprech“ verwendet wird.

Minimalziel wären schon wohldefinierte, funktionierende, offene, nachvollziehbare Schnittstellen, dass eine Flexibilität zur Umsetzung dahinter noch gegeben ist. Bspw. klare Datenformate, Services/Dienste für Datenformate, saubere Fehlerantworten bei Datenformaten, Fehlerdurchnummerierung,..

E.S - editiert am 20.11.2023

Die Erwartungen des Bitkom sind verschieden:

Zentral für uns ist aber, dass digitale (Verwaltungs)Prozesse als Ganzes gesehen und berücksichtigt werden, Front- und Back-End. Das Zielbild muss konkret und operationalisiert, mit weiteren Initiativen in dem Bereich abgestimmt sein und ergänzend zu diesen Initiativen wirken. Das Zielbild sollte eine Grundlage für die Entwicklung und Weiterentwicklung von Basiskomponenten darstellen, die Anbindung von Einzelanwendungen an Fachinformationssysteme im Fokus haben und Betrieb und Weiterentwicklung von entwickelten Lösungen unterstützen. Gleichzeitig bietet sich die Möglichkeit, dass das Zielbild für gängige Herausforderungen standardisierte Lösungen anbietet. Zudem muss der Nutzerfokus immer im Fokus stehen. Dazu gehört die Festlegung von konkreten Prinzipen und Komponenten für das Design und den Service.

Gleichzeitig bietet es sich an, Fragen zu Prozess- und Antragsvereinfachungen durch das Zielbild abzudecken. Dazu gehört auch die Thematisierung von kompatiblen Lösungen für die Registermodernisierung und die barrierefreie Einbindung von digitalen Identitätslösungen. Zudem sollte die Zentralisierungsfrage gestellt werden: Wie und was möchte man zentralisieren und was überlässt man den Ländern? In unseren Augen sollte Dezentralität auf ein Minimum reduziert und Basisdienste wie Bürgerkonten und Paymentmethoden zentral vorangetrieben werden. Dazu gehört auch, dass bei wichtigen und neu entwickelten Komponenten neben einer reinen Dokumentation ebenfalls der Code zentral zur Verfügung gestellt wird.

B.S - original vom 20.11.2023

Aus Sicht der GKV:

Die gesetzliche Krankenversicherung (GKV) bietet bereits voll etablierte und regelhaft genutzte digitale Kommunikationskanäle zwischen den Versicherten und ihren Krankenkassen an. Diese umfassen eine Vielzahl von Verwaltungsleistungen, etwa die Beantragung der beitragsfreien Mitversicherung von Ehepartnern, die Erstattung von Fahrkosten des Krankentransports oder die komplexe Information, Unterstützung und Beratung der Versicherten in Gesundheitsfragen. Damit erreichen die Versicherten ihre jeweilige Krankenkasse be-reits heute unmittelbar auf digitalem Wege. Dabei stellen die Kontakte zwischen Versicherten und Krankenkassen vielfach keine einseitigen Verwaltungsanfragen dar, sondern sind häufig komplexe Beratungsprozesse, bei denen die Versicherten über längere Zeiträume unmittelbar digital begleitet werden. Aus einer unmittelbaren Kommunikation von Ver-sicherten mit ihrer Krankenkasse ergeben sich insofern erhebliche Vorteile.

Grundlage für diese bereits sehr erfolgreiche Digitalisierung von Verwaltungsleistungen ist eine nutzerzentrierte Herangehensweise, welche auch bei der Ausgestaltung der OZG Rahmenarchitektur Grundlage für alle Überlegungen sein sollte. Daneben ist eine einheitliche, zentrale Authentifizierungsmethode der Bürger im digitalen Prozess wesentlich, um die Akzeptanz zu erhöhen und Aufwände für alle Beteiligten möglichst gering zu halten.

SEITENBAU - editiert am 12.01.2024

Unsere Erwartung als Softwareentwicklungsdienstleister an das Zielbild der OZG-Rahmenarchitektur ist, dass diese als Grundlage für Lösungskonzepte, Empfehlungen und Beratungen genutzt werden kann. Wir möchten zu Lösungskonzepten nachweisen können, dass diese im Sinne der OZG-Rahmenarchitektur sind und damit Entscheidern (Bund, Ländern, Kommunen) eine geeignete Grundlage für begründbare und effiziente Entscheidungen bzgl. der Gestaltung einer Ende-zu-Ende-Digitalisierung geben.

D.h. das Zielbild... - ist leicht zugänglich und verständlich. Sie spricht Techniker und Nicht-Techniker an. Verwendet dazu einen geeigneten Wortschatz und Übersichten. Sie lässt sich leicht durchsuchen. - Relevante Inhalte lassen sich konkreten Fragestellungen intuitiv zuordnen. - hat einen Bekanntheitsgrad und Akzeptanz bei der Zielgruppe. - kann auf relevante Fragestellungen angewendet werden und wird ausreichend konkret.

An folgenden Stellen könnte diese zum Einsatz kommen:

Vergleich von Lösungsvarianten: Aus dem Zielbild abgeleitete Bewertungskriterien werden bei der Beurteilung von Lösungsvarianten berücksichtigt. Das können "Make-or-Buy"-Entscheidungen, die Bewertung von alternativen Systemen, Standards, Komponenten oder technische Konzeptmöglichkeiten sein.

Begründung von Entscheidungen: Getroffene Entscheidungen sind im Bezug auf die OZG-Rahmenarchitektur nachvollziehbar.

R.W - original vom 20.11.2023

Die AWV fokussiert sich in ihren Anmerkungen zum Konsultationsprozess in erster Linie auf die Anforderungen von Kommunikation und Lösungen zwischen Wirtschaft und Verwaltung.

Als Zielbild halten wir eine Rahmenarchitektur auf zwei Ebenen für sinnvoll, welche folgende Bedingungen erfüllt:

Zum einen legt sie auf einer Metaebene Architektureigenschaften fest, die alle OZG-Lösungskonzepte erfüllen müssen. Dazu gehören Fragen der Konnektivität, der Interoperabilität, der Vermeidung von Doppelarbeit, der Wiederverwendbarkeit und Austauschbarkeit sowie der Skalierbarkeit.

Auf einer technischen Ebene legt die Rahmenarchitektur eine Art Framework für die Facharchitektur und die Informationssystemarchitektur verbindlich fest. Diese Schnittstellen, Module und Regelungen sind immer dann zu nutzen, wenn ein OZG-Projekt eine (Teil-) Aufgabenstellung enthält, für die diese Module geeignet sind.

Wir stellen uns eine Rahmenarchitektur insofern dynamisch vor, als dass auch neue Module hinzugeführt werden können, wenn diese im Rahmen von OZG-Projekten entwickelt und in einem Abstimmungsprozess als OZG-relevant eingestuft worden sind. (Dies setzt eine hohe Transparenz der Entwicklung von OZG-Leistungen voraus)

An konkreten Punkten halten wir für sinnvoll:

Nutzung von genau einem Nutzerkonto für möglichst alle Onlineangebote, sinnvolles Rechtemanagement für große und kleine Unternehmen, Rechteübertragung

Einheitliche Identifizierung und Authentifizierung für möglichst alle Onlineangebote

Festlegung von einheitlichen Schnittstellen und Datensatzstrukturen für alle Onlineangebote

Möglichkeit einer machine2machine-Kommunikation für möglichst alle Onlineangebote, ggf. alternative Angebote für Unternehmen ohne entsprechende IT-Infrastruktur

Berücksichtigung unterschiedlicher Konstellationen beim IT-Nutzungsgrad, Rechtevergabe und Know-how bei den Unternehmen/Organisationen, die im Austausch mit der Verwaltung stehen

Das Zielbild setzt im ersten Schritt den Schwerpunkt auf noch nicht digitalisierte Leistungen der öffentlichen Verwaltung. Bereits erfolgreiche digitale Lösungen bleiben davon unberührt.

Bewährte Best Practice Ansätze und Erfahrungen von Hidden Champions aus dem deutschen E-Government berücksichtigen. Dabei geht es nicht nur um softwarentwicklungstechnische und einführungstechnische, sondern auch um betriebliche Aspekte.

A.S - editiert am 20.11.2023

Aus Sicht der DigitalService GmbH des Bundes: - Wir erhoffen uns von dem Zielbild eine starke Vision - und nicht nur technische Details - für die zukünftige Rahmenarchitektur. Insbesondere sollte dieses nicht im klein klein am Status Quo arbeiten, sondern die großen Sprünge zeigen, auf die man dann hinarbeiten kann. Das Zielbild sollte zum Einsatz kommen, um dabei die strategische Entwicklung der Akteure, Produkte und Plattformen zu informieren und aufzuzeigen, wohin wir uns in den kommenden Jahren bewegen. - Hierbei erhoffen wir uns speziell auf der Paradigmen-Ebene klare Entscheidungen. Was soll zentral oder dezentral gelöst werden? Wird auf rein staatliche Lösungen gesetzt oder sollen Wirtschaft und Zivilgesellschaft durch offene Schnittstellen mitwirken können? - Außerdem erhoffen wir uns klare Bekenntnisse zur Cloud, Modularisierung, ganzheitlichem Open Source (keine reine Source-Code-Spiegeldung, doch mit Betriebskonzept usw…) sowie der Wichtigkeit, die Nutzendenperspektive der Öffentlichkeit und Softwareentwickler:innen zu bedenken. - Zudem hoffen wir auf einen Government-as-a-Platform Ansatz mit funktionierenden Basiskomponenten, mit Qualitätsmerkmalen und guter Developer-Experience.

S.G - original vom 20.11.2023

Die Erwartungen der VISION Consulting GmbH an ein Zielbild der OZG-Rahmenarchitektur bestehen in der Schaffung eines klaren, umfassenden, aber auch flexiblen Rahmenwerks für die Umsetzung der digitalen Verwaltung in Deutschland. Hierzu gehört insbesondere die Festlegung von - Standards (z.B. Schnittstellen) - Richtlinien (müssen von allen befolgt werden) - Leitlinien (können befolgt werden) - Best Practices - Werkzeugen

Hierbei sind ebenfalls Festlegungen zu treffen, wie die bereits vorhandenen Systeme/Funktionen zukünftig entsprechend der OZG-Rahmenarchitektur migriert werden können (falls sie nicht bereits den oben genannten Vorgaben entsprechen). Zur Vermeidung von Doppelentwicklungen sollten des Weiteren zentrale Übersichten geschaffen werden über - Systeme/Funktionen, die bereits eingeführt und im Betrieb sind (idealerweise als Warenkorb zur Nachnutzung) - Systeme/Funktionen, die aktuell entwickelt werden - Systeme/Funktionen, die in anderen EU-Mitgliedsstaaten bereits eingeführt und im Betrieb sind

Hierbei ist darauf zu achten, keine zu große technische Detailtiefe vorzugeben, damit eine Nutzung der sich ständig weiterentwickelnden IT (Low-Code-Plattformen, Cloud, KI) möglich ist.

J.E - original vom 20.11.2023

Grundsätzlich haben wir Schwierigkeiten mit dem gewählten Titel „Zielbild der OZG-Rahmenarchitektur“: OZG fokussiert rein begrifflich zu sehr auf den Online-Zugang und die Begriffe Rahmenarchitektur und Zielbild sind leider nicht genau spezifiziert und lassen viele Interpretationen zu. In unserer Vorstellung könnte ein Zielbild einer „Architekturvision (gemäß TOGAF) für die Digitalisierung der Verwaltung“ entsprechen, die sich aus übergreifenden strategischen Zielen ableiten lässt und rechtliche, betriebswirtschaftliche, organisatorische und technologische Rahmenbedingungen beachtetet. Wir erwarten, dass diese Vision komplett digitale Verwaltungsprozesse (von den Nutzenden am Frontend bis zur Datenspeicherung und Archivierung im Backend) nach dem Prinzip „Digital first“ adressiert und Perspektiven der unterschiedlichen Nutzerinnen und Nutzer außerhalb und innerhalb der Verwaltung berücksichtigt. Aus dieser Vision abgeleitet könnten Architekturen der Digitalisierung der Verwaltung mit den benötigten funktionalen (Architektur)-Bausteinen für verschiedene Architekturebenen (Geschäftsarchitektur, Informations- und Datenarchitektur, Technologiearchitektur) in kontinuierlichen IT-Bebauungsplanungsprozessen (weiter)-entwickelt werden.

S.L.B - original vom 20.11.2023

Die Bundessteuerberaterkammer wünscht sich Vereinheitlichungen und Konkretisierungen auf technischer und ebenso auf organisatorischer Ebene, die im Einklang mit dem Gesetzesentwurf und den parallel existierenden (EU-)Verordnungen, wie der Single-Digital-Gateway-Verordnung (SDGVO), stehen.

Das Zielbild sollte von einer Vision auf eine konkrete Umsetzungsstrategie schließen lassen, anhand derer sich Organisationen und Unternehmen aller Größen orientieren können und so die Umsetzung der OZG-Anforderungen verbindlich regeln. Zudem können diese Anforderungen leichter und abschätzbar in ein geplantes Vorhaben umgewandelt werden. Damit kann das Zielbild auf mehreren Ebenen wirken: Einerseits zur Klarstellung und Vermittlung des Vorhabens an sich und zum anderen auf Detailebene als Vorlage zur Anwendung von Spezifikationen und Richtlinien bis auf Komponentenebene der Lösungsarchitektur.

Ein Ziel des Gesetzes ist die Benutzerfreundlichkeit und Zugänglichkeit, die sich in der Zielarchitektur auch als Vorgaben zur Gestaltung von Oberflächen und Workflows wiederfinden lassen sollten.

F.K - editiert am 28.11.2023

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen:

Zentrale Komponenten aus den verschiedenen Gesetzen (OZG, SDG, RegMoD) wie BundID, Register, Nutzerfeedbackkomponente sollten einheitlich und definiert und ihre Beziehung zueinander aufgezeigt und abgestimmt werden

Das Zielbild sollte öffentlich dokumentiert sein

Notwendigkeit des „Sehens“ und Berücksichtigens aller Akteure (die von OZG betroffen sind) mit ihren jeweiligen Herausforderungen

Bisher waren im OZG-Kontext in erster Linie Bundes- / Landes- und kommunale Einrichtungen im Blick; die besondere Stellung, Situation sowie die Herausforderungen von Hochschulen sollten mehr Berücksichtigung finden, denn diese sind technisch eigenständige, weit entwickelte, unabhängige Bereiche der öffentlichen Verwaltung

Die Gesetzeslage sollte allgemein auf ein gemeinsames Ziel der Digitalisierung / Digitalen Transformation in Deutschland (Harmonisierung digitalisierungs-relevanter Gesetze) ausgerichtet werden.

E.H - editiert am 27.01.2024

Antwort von Bundesamt für Migration und Flüchtlinge (BAMF): - Eine gemeinsame Definition für Ende-zu-Ende-Digitalisierung finden. Dabei ist zu berücksichtigen, dass der Antragsprozess mit Informationsbereitstellung und Auffindbarkeit der Informationen für den Antrag beginnt. Der Antragsprozess kann enden mit Bescheid-Zustellung / Beendigung des Rechtsweges / Archivierung oder Kassation/Vernichtung des Vorgangs. - Es geht um die Schnittstelle zum Endnutzer / Portal / Software der Behörden/Unternehmen ebenso wie um E-Akte - DZAB - Bundesarchiv (oder Aussonderung). - Backend-seitige Einschränkungen müssen auch "vorn" mitgedacht werden (z.B. zwei PDF-Typen im Bundesarchiv zugelassen), Konvertierungsschritte sind denkbar, bergen aber auch Probleme. - Essentiell wichtig sind semantische Beschreibungen der Datenstrukturen -> Datenatlas und semantisches Datenmodell. - Die Registermodernisierung ist zu integrieren; denn Register (z.B. AZR) gehören zum Ende-zu-Ende-Prozess. Um das Once-Only-Prinzip zu leben und einmal vorhandene Daten für andere Verwaltungsverfahren nachnutzbar zu machen, könnte eine weitestgehende Harmonisierung der unterschiedlichen Register/ Datenbanken zielführend sein. Wie sich dem Problem auf andere Art genähert werden kann, bleibt zu diskutieren. Von Fachseite wären hier einfache praktikable Lösungen wünschenswert. - Um die Entwicklung der fachlichen Prozesse von der technischen Verarbeitung entlasten zu können, hat sich bewährt die Querschnittsaspekte entweder zentralisiert oder - wo das nicht sinnvoll oder möglich ist - als Blaupause zur Wiederverwendung in mehreren Verfahren auszuprägen. Damit das gelingen kann, sind die Anforderungen an technische Randbedingungen verfahrensübergreifend festzulegen, u. a. in Art und Umfang für: o Schemaprüfungen übermittelter Datenstrukturen o zugelassene Formate in Anhängen (vgl. unten) in exakter Spezifikation inkl. Versionen und Ausprägungen (Konformitätslevel, Auflösung, Farbtiefe, ettc.). o Integritätsprüfung übermittelter Inhalte o einheitliche Authentifizierung nicht nur auf der Endkunden-(Bürger-)Seite sondern auch zwischen den Frontend-Verarbeitungen (Bürgerportal(e)) und Verfahrensprozessen (Behörden) unter Berücksichtigung europäischer Normen und damit der eIDAS Grundprinzipien o Aufbewahrungs- bzw. Archivierungspflichten der übermittelten Inhalte nach Art der Daten o Mechanismen zur Quittierung übermittelter Inhalte, sowie Aktionspläne und Meldewege bei deren Versagen - Weil in jedem Verarbeitungsverfahren Fehler passieren können (egal ob technisch oder fachlich), sollte zu jedem OZG-Verfahren die Abgrenzung der Zuständigkeiten für einheitliche Clearing-Schleifen sowohl innerhalb der Fachprozesse auf Seiten der Implementierer als auch im Austausch mit dem Bundesportal enthalten sein. - Datensparsamkeit sollte nicht nur als Gebot des Datenschutzes verstanden, sondern aktiv als Mittel zur Reduktion von Redundanzen genutzt werden. - Anhängende Dokumente sollten in informationszentrischen Verfahren nur als Belege verstanden werden, und die Anforderung ihrer Übermittlung sollte auf den Zeitpunkt des Bedarfs verschoben werden können, z. B. fachlich in Form einer Zwischenkommunikation, technisch in Form einer Referenz auf einen zugriffsgeschützten zentralen (Cloud-)Speicher (getrennt nach Verfahren aus DS-Gründen). - Bzgl. solch einer Architektur (Ende-zu-Ende im OZG-Kontext) sind Erfahrungen und konkrete Umsetzungsbeispiele im BAMF vorhanden und können zur Veranschaulichung dienen. - Das Delegations- und Vertretungskonzept "On Behalf Of Semantik" ist im Zielbild zu integrieren. Im Kontext einer medienbruchfreien Kommunikation müssen sowohl das Vertrauensmodell als auch die Validierung der Berechtigungsscheine digital abgebildet werden, einschließlich dynamischer Ausstellung und Entzugsmöglichkeiten. (mehr zu diesem Aspekt findet sich auch in der Antwort zu Leitfrage 02) - Eine Idee und Erwartung - insbesondere für die Erprobung und Machbarkeitsprüfung im behördenübergreifenden Kontext - ist, hier in PoCs (mit breiter Nutzendenbeteiligung, vgl. Leitfrage 03) erst einmal zu testen und dann erst Konzepte final freizugeben, in Folge von MVPs und Sandbox-basierten Erprobungen.

A.K - original vom 20.11.2023

Im Idealfall ist ein Zielbild nicht nur ein Bild in einem Dokument, sondern ein gemeinsames Verständnis zu den Bausteinen der Ziellandschaft und dazu, wie diese ineinandergreifen. Wenn auch die Umsetzungen immer wieder gegen dieses Zielbild gehalten werden und eine Übereinstimmung hergestellt werden kann (zwischen verfügbaren Lösungen und ihrer Repräsentanz im Zielbild), dann können Lösungen einfacher nachgenutzt werden, Dopplungen werden besser vermieden und der Mehrwert der Einhaltung von Standards und Interoperabilität kann schneller greifbar werden.

T.K - editiert am 27.11.2023

Sammlung CDO-MID Sachsen-Anhalt und Vertreter von Kommunen des Landes:

• Der Föderalismus darf – wie jetzt - nicht als Bremse der Digitalisierung wahrgenommen werden. Er soll im Sinne des Wettbewerbs um die beste Leistung dazu dienen, die besten Dienste bundesweit nachnutzen zu können. Die Digitalisierung staatlicher Dienstleistungen muss schnell und spürbar vorankommen. Studien wie der eGovernement Monitor 2023 legen nahe, dass gute digitale Dienste die (Demokratie-)Zufriedenheit der Bürgerinnen und das Vertrauen in den Staat erheblich steigern können.

• Die Rahmenarchitektur muss dazu beitragen, Dienste kosteneffizient und v.a. schneller an den Start zu bringen. Barrieren wie fehlende Standards (technische, rechtliche und organisatorische) müssen abgebaut werden.

• Die Rahmenarchitektur muss rechtlich verbindlich sein. Digitalisierung muss auch für Kommunen als Pflichtaufgabe definiert und umgesetzt werden.

• Die OZG-Rahmenarchitektur räumt der IT-Sicherheit – neben der Nutzerfreundlichkeit für Bürger, Unternehmen und Verwaltungsmitarbeiter – Priorität ein. Ich denke beides in Kombination mit einer guten Kommunikation an die Zielgruppen/ Kampagne erhöht die Nutzerrate erheblich.

• Die OZG-Rahmenarchitektur sollte den finanziellen Rahmen schaffen für die Nutzung von EfA-Leistungen nach 2027 (Planungssicherheit) unter wirtschaftlichen Gesichtspunkten. Derzeit misstrauen viele Kommunen nämlich noch dem EfA-Prinzip, insbesondere weil die Finanzierung nach 2027 noch unklar ist und sie nicht überzeugt davon sind, dass sich eine EfA-Leistung auch ohne finanzielle Unterstützung von Bund und Land fortführen lässt.

• Die OZG Rahmenarchitektur sollte so „weitsichtig“ sein, dass Standards kontinuierlich fortentwickelt werden können und dabei gleichzeitig verlässlich genutzt werden können (keine ständigen Wechsel in einer sich ständig veränderten Welt).

• Barrierefreiheit ist sehr wichtig (Mehrsprachigkeit, Behinderungen, Lese-Rechtschreibschwächen). OZG-Leistungen müssen für den Bürger auffindbar sein (leichte Sprache als Standardeinstellung).

• Ein erste Konsolidierung der heterogenen IT-Infrastruktur - auch um dem Fachkräftemangel im IT-Bereich entgegen zu wirken

• Eine einfachere Nachnutzung von Leistungen - Ende-zu-Ende, also nicht nur das Webformular

• Den Plattformgedanken vorantreiben - ich verweise hier gern auf eine Kurzstudie des NEGZ: Government as a Platform in Deutschland – NEGZ · Nationales E-Government Kompetenzzentrum

• Verwaltungscloud als wichtiges Element

• Es müssen klare Strukturen in Bund/ Ländern und Kommunen vorherrschen. Gerade die Zusammenarbeit zwischen Länder und Kommunen über eine zentrale Instanz ist immens wichtig und hilft bei der Steuerung der OZG-Umsetzung. Hier das Beispiel KITU 2.0 (kommunale Genossenschaft für IT) Aktuell würde das vor allem bei der Bewältigung der vielen Nachnutzungsangebote welche auf die Kommunen einprasseln helfen. Vor allem aber kleinere Kommunen könnten einen großen Nutzen aus einer zentralen Instanz ziehen welche alle relevanten „OZG-Kompetenzen“ bündelt. Es muss Klarheit geschaffen werden in der Finanzierung der umzusetzenden Maßnahmen. Kommunen müssen wissen welche Kosten sie einplanen müssen und welche vom Land getragen werden.

• Standardisierungen führen zur Reduktion von Kosten und Einsparung bei der Einführung von OD (IT-Seite und auch in den Fachbereichen im Amt)

• Kosteneinsparung durch Nutzung von zentral bereitgestellten Basiskomponenten (schnellere Bereitstellung, Weiterentwicklung und Angebotserweiterung wäre wichtig)

• Basiskomponenten bundesweit standardisieren (Stichwort Abweichungen ePayBL beim Betrieb in Sachsen im Vergleich zu Sachsen-Anhalt)

• Verschlankung der IT-Landschaft - Fokus auf die Weiterentwicklung zentraler Komponenten

• Verbesserung der IT-Sicherheit

• Erkennbarkeit aller staatlichen Leistungen als Dachmarke wie vom BMI gewünscht und auch Einheitlichkeit in der Darstellung der OD/Portale

• wenn möglich nur 1 Verwaltungsportal für alle Leistungen als zentraler Einstiegspunkt auf Bundesebene für den Bürger

AS - original vom 20.11.2023

Holistische Sichtweise und ein hoher Grad an Praxisnähe

Wir erwarten von einem Zielbild, dass es den gesamten Prozess der Digitalisierung von Verwaltungsleistungen berücksichtigt - von der Gesetzgebung bzw. Ausführungsbestimmung über die Umsetzung der digitalen Leistung bis hin zur Bearbeitung und Abwicklung. Es betrachtet Akteure aller (Verwaltungs-)Ebenen – insbesondere die ausführende, häufig kommunale Ebene – sowie alle Phasen eines Software-Lifecyles (d.h. auch Support- und Wartung). Ein hoher Grad an Praxisnähe ist wichtig. In Anlehnung an etablierte Industrie-Standards sollten die in dem Zielbild beschriebenen Architekturen modular und anpassbar gestaltet werden, um im projektspezifischen Kontext skalier- und individualisierbar zu sein. Bei der Entwicklung von Onlinediensten sollte das Zielbild helfen, Komplexität zu reduzieren und eine tragfähige Governance zu etablieren. Das kann durch Inhalte gelingen, die klare Zuständigkeiten benennen, Begriffe eindeutig definieren und belastbare Blaupausen für Strukturen und Prozesse anbieten.

Standardisierung und Offenheit stärken und ausweiten

Die Grundprinzipien von Standardisierung und Offenheit ermöglichen einen hohen Wiederverwendungsgrad und reduzieren Entwicklungs- und Betriebskosten. Das Zielbild sollte hierzu klare Vorgaben enthalten und den Nutzen hervorheben. Im Bereich Standards sollten alle relevanten Dokumente und Projekt-Artefakte ähnlich dem XRepository offen zugänglich und nutzbar sein. Das Zielbild sollte auf eine verständliche und frei verfügbare Dokumentation setzen. Letztlich geht es darum, die Interoperabilität innerhalb des gesamten Ökosystems zu stärken. Neue Anbieter sollten ihre Lösungen auf Basis offener Spezifikationen entwickeln und in das Ökosystem einbringen können, ohne an den Grenzen von Plattformen und Schnittstellen zu scheitern.

J.P - original vom 21.11.2023

Antworten Team PwC: - Entwicklung eines standardisierten Rahmenarchitekturmodells, an dem sich alle föderalen Ebenen zur Umsetzung des OZG orientieren können/müssen. - Schaubild / Übersicht zur OZG-Rahmenarchitektur – niedrige Komplexität - Klare und verbindliche Vorgaben vom Bund für den Bund, die Länder und die Kommunen hinsichtlich der Verwendung von Standards (z.B. XÖV), Methoden (z.B. FIM), Tools (z.B. FIT-Connect) usw. - Eindeutige Zuständigkeiten – auch und gerade bei gemischten Leistungstypen (z.B. Leika-Typ 2/3). - Schaffung von Klarheit und Verbindlichkeit - Rechtliche Verankerung des Zielbildes im OZG oder an anderer geeigneter Stelle - Eine zum Zielbild passende Governance-Struktur mit Zuständigkeiten und Prozessen, um die Umsetzung sicherzustellen - Einfache, verständliche Handreichungen des Zielbilds für alle beteiligten und für die Umsetzung verantwortlichen Ebenen

IT.E.B.S.S - original vom 22.11.2023

Vielleicht wäre es sinnvoll, je ein Zielbild für die Reifegrade 3 und 4 zu erstellen. Dabei wäre es angebracht, die Realität zu berücksichtigen, statt allgemein theoretische, gut klingende Visionen zu formulieren. Bedeutet: - welche Infrastrukturen sind zentral nutzbar in Bund, Land und Kommunen - welche Netze müssen / sind angebunden - welche Identifizierungsmechanismen sind nutzbar (vor allem auch für Maschine-zu-Maschine) - wer ist die vertrauenswürdige Stelle, welche die Berechtigungen für die Kommunikation erteilt - welche Standards sind wo sinnvoll einsetzbar? XÖV ist bei Leistungen, die nur von einer Stelle erbracht werden überflüssig. Generell sollte ohnehin auf Datenaustauschformate verzichtet werden und wenn möglich lediglich eine Ja/Nein Frage gestellt und beantwortet werden (siehe Reifegrad D im OOTS). Dies ist auch der einzig gangbare Weg für Datensparsamkeit. Es werden nicht alle Daten aus einem Melderegister benötigt, wenn die eigentlich Frage lautet: "ist die Person volljährig".

Für Reifegrad 4, der ja Once-Only beinhaltet, sollte keine separate Vision entworfen werden, sondern mit NRW MWIKE gesprochen und Registermodernisierung sowie SDG berücksichtigt werden. Für Reifegrad 4 fehlen aber aktuell sämtliche Basis-Infrastrukturen. - wo sind Daten / Nachweise auffindbar? (Stichwort Datenatlas) bzw. wer hat welche Daten, was bedeuten diese und welche APIs existieren, um darauf zugreifen zu können - wie wird der Zugriff geregelt (Identifizierung / Berechtigung usw.) siehe oben

M.K - editiert am 22.11.2023

Antworten des Programmbereichs OZG-EU-OOTS der Gesamtsteuerung Registermodernisierung

Unsere Erwartungen an ein Ziebild der OZG Rahemenarchitektur unterteilen sich grundlegend in verschiedene fachliche und zeitliche Anforderungsebenen, welche im Folgenden kurz skizziert werden:

1. Eine Vision und Mission: Grundlegend sollte das Zielbild der OZG-Rahmenarchitektur zunächst eine Vision beschreiben. Anhand eines Big Pictures sollten in Eckpunkten ein Ziel, dessen Begründung und Leitlinien zur Erreichung vorgegeben werden. Auch sollten die einzelnen Architekturbausteine im Ist und Soll definiert werden. Aufbauend auf dieser Basis sollte anschließend eine Detailansicht erstellt werden.

Einsatzmöglichkeiten: 1. Schaffung eines gemeinsamen föderalübergreifenden Verständnisses der Ziele der OZG-Umsetzung 2. Entscheidungsgrundlage für die Auswahl von Technologien, Standards und Lösungen 3. Kommunikation auf Fachkongressen 4. Kommunikation auf politischer Ebene 5. Grundlage einer Umsetzungsplanung

2. Strategische Umsetzungsplanung Das Zielbild sollte neben der Vision auch die Grundlage für ein Projekt liefern und beantworten, wie die Vision erreicht wird. Dazu sollte das Zielbild weiter konkretisiert und in strategische und operative Ziele heruntergebrochen werden. Die Ausarbeitung kann dabei beispielsweise in einer eigenen Programmstruktur nach dem Vorbild der Registermodernisierung oder in Zyklen unter Beteiligung aller Stakeholder erfolgen. Das Ziel sollte hierbei sein, möglichst schnell und effizient in die Ausarbeitung klarer Verantwortlichkeiten und Strukturen zu gelangen. Die Planungen sind dabei mit den zentralen Digitalisierungsvorhaben zu synchronisieren und eine übergreifende Architekturgovernance zu schaffen, welche die Grundlage für Architekturentscheidungen im Bezug auf Standards, Basisdienste, Frameworks und weiteren Aspekten darstellt.

Einsatzmöglichkeiten: 1. Ausgangspunkt für evtl. weitere gesetzliche Anpassungen 2. Vorlage für eine Gap-Analyse zur Entwicklung und Kommunikation eines Transformationspfads 3. Als Benchmarking-Tool zur Fortschrittsmessung der Umsetzung der OZG-Rahmenarchitektur sowie der Einzelleistungen 4. Als Compliance-Tool zur Sicherstellung der gesetzlichen und regulatorischen Anforderungen 5. Schulung und Training: Das Zielbild kann als Schulungsmaterial für Mitarbeiter und Partner dienen, um ein Verständnis für die OZG-Rahmenarchitektur und ihre Ziele zu vermitteln.

3. Kerninhalte Inhaltlich wird eine zukunftsorientiert, tragfähig, adaptierbar, hochgradig standardisierte Rahmenarchitektur erwartet, welche verschiedene Architekturebenen sauber trennt. Sie muss fachliche und technische Rahmenbedingungen definieren, sollte zyklisch fortgeschrieben werden und bestehende Infrastrukturen berücksichtigen. Sie sollte eine Komposition von Architektur- und Lösungsbausteinen sein. Deren Beziehung muss auf wohl definierten Schnittstellen basieren und sollte die dezentralen Portallösungen auflösen und in ein Gesamtkonzept zusammenführen. Außerdem muss ein Schwerpunkt auf das Ziel der End-2-End Digitalisierung gelegt werden. Diese Struktur gilt es iterativ fortzuschreiben.

M.H - editiert am 26.11.2023

Universtität Duisburg-Essen, HISinOne-Cm.nrw:

Die Erwartungen an eine OZG-Rahmenarchitektur sind aus der Sicht der Hochschulen von dem Bedürfnis nach einer nahtlosen, internationalen digitalen Vernetzung, die den besonderen Anforderungen des Bildungssektors gerecht wird geprägt. Hochschulen erwarten eine Architektur, die nicht nur die nationale Verwaltungsdigitalisierung umfasst, sondern auch eine grenzüberschreitende Zusammenarbeit und den Austausch von Bildungsinhalten, Forschungsdaten und administrativen Prozessen erleichtert. Dies setzt voraus, dass die Rahmenarchitektur flexible und interoperable Standards sowie Schnittstellen bietet, die eine effektive Integration verschiedener Bildungssysteme ermöglichen. Zudem ist es für Hochschulen essentiell, dass die Architektur hohe Sicherheitsstandards für den Datenschutz und die Datensicherheit berücksichtigt, um die Vertraulichkeit und Integrität von Forschungs- und Studierendendaten zu gewährleisten.

In Anbetracht dessen, dass viele Bildungseinrichtungen bereits digital gut aufgestellt sind – im Kontext der Hochschulverwaltung durch sog. Campusmanagementsysteme—, sollte die Rahmenarchitektur bestehende Systeme ergänzen und unterstützen, anstatt sie zu ersetzen. Damit würde sie eine solide Grundlage für eine fortschrittliche und vernetzte digitale Bildungslandschaft bilden.

Die Vision ist eine Neuorientierung des OZGs, die eine partnerschaftliche Gemeinschaftsaufgabe aller Beteiligten darstellt und setzt voraus, dass die entwickelten Lösungen nicht nur technisch ausgereift, sondern auch in der Praxis anwendbar und nutzerfreundlich sind. Eine solche gemeinschaftliche Anstrengung kann dazu beitragen, den Zugang zur Hochschulbildung effizienter, transparenter und zugänglicher zu gestalten und somit eine spannende und erzählenswerte Bildungsreise zu etablieren. Es ist dabei unerlässlich, dass die Rahmenarchitektur eine vollständige End-to-End-Digitalisierung in den Fachverfahren der Bildungseinrichtungen unterstützt. Dies bedeutet, dass jeder Schritt in den Prozessen – von der Anmeldung bis zum Abschluss der Studiengänge – nahtlos und digitalisiert ablaufen sollte. Eine solche durchgängige Digitalisierung würde die Effizienz und Benutzer:innenfreundlichkeit der Verwaltungsprozesse an den Hochschulen erheblich verbessern und so einen integralen Bestandteil einer modernen, digitalen Bildungslandschaft darstellen.

L.S - original vom 24.11.2023

Für das Zielbild der Rahmenarchitektur kann im Sinne der Realisierung von Plattformmehrwerten nur eine „Ende-zu-Ende“-Digitalisierung zielführend sein und wäre unsere Erwartung für das Zielbild. Hierfür müssen insbesondere auch IT-Dienstleister aller Größen, national und international eingebunden werden. Ohne klare und weitgehende Standardisierung der Infrastruktur, könnten die föderalen Strukturen und individuellen Realumsetzungen bremsend wirken und erneut Komplexitäten erhöhen.

Drei für uns wichtige Bereiche, würden wir im Zielbild erwarten:

• KI sollte (wo sinnvoll) als grundlegende Technologie und Lösungskomponente in ALLE OZG-Verfahren aufgenommen werden. Auf reine Piloten und Alibi-Lösungen muss verzichtet werden, um Wirkliche Entlastungen für alle Nutzenden und die Verwaltung selbst freizusetzen.

• Der Bereich Sicherheit sollte mit den aktuellen Technologien neu gedacht werden, um von der grundsätzlichen Vorgabe der physikalischen Trennung hin zu modernen Konzepten und Rechte und Rollenmodellen für Plattformlösungen zu kommen.

•Ein sinnvoller Nordstern bei der Entwicklung der neuen Strategie kann die Orientierung an Rahmenwerken von anderen Ländern sein, so etwa Dänemark, Estland, aber auch UK oder Italien. Hier sind (auch öffentlich verfügbare) Prinzipien für Beschaffung und Strategie dokumentiert, die landesweit gelten, z.B.

https://www.gov.uk/guidance/government-cloud-first-policy https://innovazione.gov.it/notizie/articoli/en/the-italian-cloud-strategy/

A.M - original vom 27.11.2023

Antworten ekom21 KGRZ Hessen

Grundsatz der Einfachheit mit klarer Nutzen- und Nutzungsorientierung. Weniger ist mehr. Alle Bausteine, für die es derzeit noch keine konkreten Use-Cases und Nutzungsanforderungen gibt, werden erst dann weiter ausgestaltet, wenn konkreter Bedarf besteht. Dies muss auch für EU-Vorgaben gelten, für die es noch keine Anwendungen mit relevanter Größenordnung gibt.

Die Rahmenarchitektur soll einem pragmatischen Bottom-Up Ansatz folgen, der sich an einer Schichtenarchitektur orientiert. Beginnend mit Infrastruktur-Themen (Betriebsformen, Cloud-Nutzung, Datennetze, Verzeichnisdienste,… ) über Standard-Schnittstellen und Kommunikationsintermediäre (OSCI;XTA,FIT-Connect) zu Basiskomponenten (Payment, Authentisierung, Nutzerkonten, ..).

Die Rahmenbedingungen für die „höheren Schichten“, (Prozessplattformen, Fachverfahren, Portale) beschränken sich weitgehend auf die Herstellung der Interoperabilität (Kommunikation, Datenaustausch, XöV, -Alternativen) und sind sehr offen gestaltet.

Wichtig wär es, parallel zur Ausgestaltung der Rahmenarchitektur die dazu erforderlichen Basiskomponenten zentral zur Verfügung zu stellen und deren Einsatz zu fördern, um Nutzungsanreize zu schaffen.

Das Zielbild darf keinem Greenfield-Ansatz folgen, sondern muss sich an den bisher erfolgreichen OZG- / EfA-Projekten orientieren. Für bereits bestehende landesweit genutzte OZG-Infrastrukturen müssen angepasste Übergangszeiträume für die Umsetzung neu entstandener Kriterien der Rahmenarchitektur festgelegt werden.

Die iterative Fortschreibung von Festlegungen in der Rahmenarchitektur wird begleitet von Proof of Concepts. Die erfolgreiche Erprobung in der Praxis ist Voraussetzung für die finale Aufnahme in der Rahmenarchitektur.

Die Architektur muss so gestaltet werden, dass die gesellschaftlichen Veränderungen bei der Mediennutzung (Devices, Plattformen, Usability, Interaktion,..) strukturell berücksichtigt und dynamisch aktualisiert werden können.

D.H - original vom 28.11.2023

Wir erwarten, dass im Rahmen des Konsultationsprozesses konkret über aktuelle Entwürfe der bei FITKO vermutlich bereits vorliegenden Architekturrichtlinien und Entwürfe einer OZG-Rahmenarchitektur diskutiert wird.

Wenn Sie möchten, dass der Konsultationsprozess tatsächlich Wirkung entfalten kann, sollten Sie bald entsprechende Entwürfe bereit stellen und nicht nur wie in https://docs.fitko.de/arc/policies/foederale-it-architekturrichtlinien/abbildung-4 auf zukünftige Versionen verweisen.

K.G - original vom 07.12.2023

Antwort der VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister:

Das Zielbild einer OZG-Rahmeninfrastruktur sollte aus Sicht der VITAKO eine dynamische und anpassungsfähige digitale Transformation ermöglichen, die Front-End- und Back-End-Prozesse nahtlos integriert und eine einheitliche Architektur für Bund, Länder und Kommunen schafft. Dabei liegt ein besonderer Fokus auf dem Datenschutz und der Informationssicherheit durch die Implementierung einer umfassenden IT-Sicherheitsplattform. Zudem werden eine technologische Offenheit und Integration verschiedener Technologien, einschließlich Cloud- und hybriden Lösungen, erwartet, um Interoperabilität und Automatisierung zu unterstützen. Das Zielbild muss klar und deutlich sowie handlungsauslösend formuliert sein. Sowohl Bürger*innen als auch Unternehmen sollten Verwaltungsdienstleistungen vollumfänglich in Anspruch nehmen können, unabhängig davon, auf sie von Bund, Land oder Kommune zur Verfügung gestellt werden. Wünschenswert wären in diesem Kontext: - einheitliche Benutzeroberfläche, unabhängig davon, auf welcher instanziellen Ebene/hierarchischen Struktur (Bund, Land, Gemeinde) man sich befindet - eine den aktuellen Sicherheitsstandards entsprechende interoperable IT-Infrastruktur - standardisierte sowie offene Schnittstellen - medienbruchfreie und somit effiziente Datenverarbeitung

Die Umsetzung des OZG-Gesetzes soll bestmöglich unterstützt werden, um letztendlich die digitale Transformation der Verwaltung voranzutreiben.

IT-Dienstleistungen für Kommunen werden von unterschiedlichen Akteuren erbracht. Dies sind IT-Abteilungen als interne Organisationseinheiten, die Kommunalverwaltungen selbst, kommunale IT-Dienstleister, die für mehrere Kommunen tätig sind, IT-Dienstleister des Landes als Leistungserbringer und privatwirtschaftliche Unternehmen, die mit Leistungen beauftragt werden. Die Erwartungen an eine OZG-Rahmenarchitektur sind, dass die Kommunen eine Orientierung erhalten, welche Leistungserbringer für welche Leistungsbausteine/Leistungskomponenten tätig sind bzw. werden können.

Das OZG-Zielbild kann an verschiedenen Stellen zum Einsatz kommen, um die Realisierung des OZG möglichst optimal zu unterstützen, z.B.: - Kommunen und öffentliche Verwaltungen: Das OZG-Zielbild kann von Kommunen und öffentlichen Verwaltungen genutzt werden, um den aktuellen Stand der Digitalisierung ihrer Verwaltungsleistungen zu analysieren und Verbesserungspotenziale zu identifizieren. - Das Zielbild kann dort eingesetzt werden, wo Kommunen strategische und operative Entscheidungen treffen müssen, wer mit welchen Leistungen beauftragt wird. Es dient als Orientierungshilfe für die Entwicklung des digitalen Verwaltungsangebots. - Bundes- und Landesbehörden: Das OZG-Zielbild kann von Bundes- und Landesbehörden als Grundlage für die Erarbeitung von Verwaltungsleistungen dienen, die gemäß OZG digitalisiert werden müssen. Es hilft dabei, eine einheitliche und nutzerorientierte Gestaltung der digitalen Dienste sicherzustellen. - IT-Dienstleister: Das OZG-Zielbild kann von IT-Dienstleistern verwendet werden, um ihre Produkte und Services an den Anforderungen des OZG auszurichten. Es unterstützt sie bei der Entwicklung von Lösungen, die den Bedürfnissen der Verwaltungen und Bürger*innen gerecht werden.

A.K - editiert am 23.12.2023

Zugegebenermaßen wenig spät, aber laut Orga dürfen Kommentare ja auch noch nach den jeweiligen "Stichterminen" eingebracht werden. Hier nun die Antwort von Red Hat auf die Leitfrage 1:

Maßgeblich für ein Vorhaben wie die OZG Rahmenarchitektur sind gewöhnlich die Zielsetzungen des OZG Vorhabens. Eine Rahmenarchitektur soll - wie jede Architektur - eine Vorlage dafür bereitstellen, wie diese Zielsetzungen umzusetzen sind.

Die Architektur nimmt gewissermaßen methodisch die Umsetzung vorweg, indem sie die Grundstruktur des umzusetzenden Systems beschreibt, das sich wiederum aus einer Vielzahl von Einzellösungen zu einer Gesamtlösung zusammenfügt.

Die Architektur wird in allen Phasen der Erstellung auf die Eignung zur Zielerreichung überprüft und falls erforderlich angepasst.

Bei der OZG Rahmenarchitektur sind somit die Ziele im OZG Gesetz festgeschrieben. Weitergehende operative Zielsetzungen und Handlungsfelder sind lediglich dem IT-Planungsrat und möglicherweise dem IT-Architekturboard bekannt. Zudem ist die Frage, was genau eine Rahmenarchitektur i.S. der OZG Rahmenarchitektur beinhaltet, und was diese leisten soll, im Konsultationsprozess offen gehalten. Ohne Kenntnis der weitergehenden Zielsetzungen besteht die grundlegende Erwartungshaltung demnach vor allem darin, dass zum einen die Zielsetzungen aus dem OZG bereits adäquat in einen Handlungsrahmen überführt wurden, und dieser Handlungsrahmen mit operativen Zielen ausgestaltet wurde.

Die Grunderwartung knüpft sich also daran, dass die (nur dem IT-Planungsrat bzw. dem IT-Architekturboard) bekannten Ziele und Handlungsfelder im Zielbild der OZG Rahmenarchitektur systematisch, konsistent, nachweisbar und - zwecks Erfolgsaussicht - mit dem entsprechenden Erfahrungshintergrund verfolgt bzw. abgebildet werden.

Daneben gelten allgemeine Erwartungen zum Zielbild, die grundsätzlich auf jede Rahmenarchitektur im föderalen Umfeld zutreffen:

Das Zielbild sollte den Betrachtungsgegenstand (hier: OZG Rahmenarchitektur) sinnvoll definieren und ggf. abgrenzen und die Machbarkeit sicherstellen.

Das Zielbild sollte die deutsche Verwaltungsrealität berücksichtigen. Dies betrifft insbesondere die Leistungsfähigkeit der jeweiligen Einrichtung bzw. Körperschaft auf den unterschiedlichen Verwaltungsebenen.

Das Zielbild sollte Festlegungen treffen, wo nötig, und im Übrigen Raum im Sinne weitestgehender Freiheit und Offenheit in der Umsetzung schaffen und einen produktiven Wettbewerb fördern.

Strategische Zielsetzungen sind von operativen Zielsetzungen zu trennen.

Das Zielbild sollte im Rahmen des Möglichen Vereinfachungen anstreben, anstatt Sachverhalte zu verkomplizieren.

Das Zielbild sollte mit realistischen Finanzierungsmodellen harmonieren.

Das Zielbild sollte sich an bestehenden, bewährten Lösungen und Erfahrungswerten orientieren, um die sichere Umsetzbarkeit sowie ggf. den Investitionsschutz gegenüber bereits entwickelten Lösungen zu gewährleisten. Das Rad muss nicht immer wieder neu erfunden werden. Gelegentlich ist die Verbesserung eines bestehenden Services sinnvoller und wirtschaftlicher als eine Greenfield-Entwicklung. Dies setzt jedoch die Bereitschaft voraus, sich mit bestehenden Lösungen und Erfahrungen auseinanderzusetzen.

Daneben sollte das Zielbild aktuelle und insbesondere offene Standards, Methoden und Technologien berücksichtigen, um von aktuellen Entwicklungen zu profitieren und zukunftsfähige Lösungen zu unterstützen. Dies beinhaltet auch den präferierten Einsatz von professioneller Open Source.

Das Zielbild sollte schnelle, pragmatische Lösungen unterstützen (Beispiel MVP), wo dies geboten ist, etwa um notwendige Erfahrungen zu sammeln oder Deadlock-Situationen zu vermeiden. Dabei ist jedoch im Blick zu behalten, dass unvollständige Lösungen niemals als Dauerlösung geeignet sind. Dies gilt insbesondere für wichtige zentrale Komponenten.

Generell ist ein transparenter Prozess anzustreben, um im Einzelfall anhand klarer Kriterien zwischen Nachnutzung bestehender Lösungen und Neuentwicklung zu entscheiden. Dies bezieht sich auch auf “Make or buy”.

Im Zielbild sollte geprüft werden, ob aus der OZG Rahmenarchitektur ggf. Verbindungen zu anderen Vorhaben bestehen (Beispiel europäische Initiativen), von denen das OZG Vorhaben profitieren kann, bzw. die durch das OZG Vorhaben gefördert werden.

Das Zielbild sollte die föderale Struktur abbilden, ohne eine unnötige föderale Komplexität zu zementieren, die sich nicht aus rechtlichen oder sachlichen Notwendigkeiten heraus ableitet.

Das Zielbild sollte alle Erfolgsfaktoren einbeziehen, die für die erfolgreiche Umsetzung und den damit erzielten Nutzen von Bedeutung sind (einschl. Lebenswirklichkeit, einheitliche Nutzererfahrung, Akzeptanz und Barrierefreiheit)

Das Zielbild sollte auf eine tragfähige Balance von Resilienz und Wirtschaftlichkeit hinwirken.

Das Zielbild sollte die Rolle bereits vorhandener IT-Dienstleister (und hierbei insbesondere die der öffentlichen IT-Dienstleister) in einem übergreifenden, kooperativen Betriebsmodell anhand von Kriterien wie Service Level, Datenschutz, Flexibilität, Innovation, IT-Sicherheit und Souveränität berücksichtigen.

Das Zielbild sollte darauf ausgerichtet sein, die Gesamtkomplexität durch eine Aufteilung in Teilprojekte oder Module zu reduzieren, die wiederum durch eine Rahmenarchitektur in Verbindung mit einer übergreifenden Governance zusammengeführt werden, wobei letztere wiederum die Durchsetzung vorgegebener Standards sicherstellt. Teilprojekte und Module sollten in einem übergreifenden Programmmanagement koordiniert geplant und umgesetzt werden, das durch den IT-Planungsrat kontrolliert wird.

Das Zielbild sollte stets die technische Machbarkeit einbeziehen, und nicht von unklaren Prämissen ausgehen, die ggf. über keine abgesicherte Grundlage verfügen (wie etwa das Voraussetzen einer leistungsfähigen, souveränen und regulatorisch abgesicherten Cloud-Infrastruktur wenn diese nicht verfügbar ist).

Das Zielbild sollte darauf vorbereitet sein, dass sich Notwendigkeiten und damit auch Zielstellungen ggf. ändern.

Das Zielbild sollte die Mitwirkung fähiger, erfahrener Projekt-/Programmmanager und Architekten fördern.

Das Zielbild sollte darauf hinwirken, dass Handlungsfelder, in denen ggf. noch Klärungsbedarf besteht, frühzeitig identifiziert und anhand von Proof-of-Concepts, Erprobungsräumen und Laboren mit den notwendigen Erkenntnissen angereichert werden.

Das Zielbild sollte Anreize schaffen, Zuständigkeiten und Verantwortlichkeiten zu übertragen bzw. zu übernehmen oder auch abzugeben und so die Zusammenarbeit neu zu definieren.

Das Zielbild sollte Transparenz herstellen, anstelle Bewertungen, Entscheidungen und Wissen auf einen kleinen, inneren Kreis zu begrenzen.

Das Zielbild sollte darauf hinwirken, mögliche Handlungsalternativen und Vorschläge zu überprüfen und zu bewerten anstelle a priori zu postulieren oder ungeprüft zu übernehmen. Dies betrifft ggf. auch Hype-Themen, Buzzwords oder vermeintliche Best Practices aus anderen Anwendungsgebieten. Gleichzeitig sollten jedoch die Bereitschaft und die Offenheit bestehen, sich mit neuen und ggf. ungewohnten Ansätzen zu befassen und von erfolgreichen Vorhaben zu lernen.

Das Zielbild sollte wichtige gesellschaftliche Entwicklungen und Herausforderungen - etwa hinsichtlich des Einsatzes von Künstlicher Intelligenz - berücksichtigen, analysieren, bewerten und verantwortlich behandeln.

Ein Zugang zu Verwaltungsleistungen sollte weiterhin auch nicht-technisch möglich sein.

Das Zielbild sollte eine offene Kommunikation im Sinne eines kontinuierlichen, zielgerichteten, demokratischen Austauschs beinhalten, um Interessen abzugleichen und Widerstände abzubauen, Konsens zu erzielen und so das gemeinsame Vorhaben zum Erfolg zu bringen.

Insgesamt ist festzuhalten, dass OZG ursprünglich als Hebel zur längst überfälligen durchgehenden Digitalisierung unter Einbeziehung der Nutzer geplant und in Form eines Gesetzes formuliert wurde, um rechtliche Hindernisse möglichst im Vorfeld zu beseitigen.

Die große Aufgabe hat in der ersten Phase manche überfordert. Einige Leistungen ließen sich schnell umsetzen, andere stellten sich als Herausforderung dar. Die Anbindung an Backend-Systeme, die für eine durchgehende Digitalisierung unverzichtbar ist, wurde vernachlässigt. Viele Fragestellungen sind weiterhin offen. Wir werden uns daran messen lassen müssen, ob wir in der Lage sind, transparent zu analysieren und daraus die für die Zukunft entscheidenden Erkenntnisse zu ziehen. Die große Aufgabe bleibt, und sollte auch im Zielbild als solche benannt werden.

G.B - original vom 28.01.2024

Die Befähigung der Bürger:innen digital souverän und Möglichkeiten nach Stand der Technik von einer digitalen Daseinsvorsorge zu profitieren welch die Rechte aller Betroffenen, Bundesbürgerinnen, EU-Bürgerinnen, Bürger*innen aus Drittstaaten unabhängig von Aufenthaltsstatus unterstütze.

Eine Befähigung der öffentichen Hand zeitgemäßes transparentes und nachvollziehbares Regierungshandeln umzusetzen und sich digital zu artikulieren und damit neue Maßnahmen wie die Kindergrundsicherung, die Auszahlung von Einmalzahlungen und Klimageld sowie die Weiterentwicklung von Rechtsnormen, bspw. im Bereich von Ersatzfreiheitsstrafen umzusetzen ohne Grundrechte zu verletzen oder auf technisch unausgereifte Lösungen zurückzugreifen.

Bausteine

08. Funktionsbausteine

Datum der Veröffentlichung: 06.12.2023
Anzahl eingegangener Antworten: 40
Issue # in GitLab: #145
Leitfrage 08 Funktionsbausteine

Es wurden einzelne Funktionsbausteine* für Verwaltungsprozesse identifiziert.

Sind aus Ihrer Sicht Zuschnitt und Bezeichnung eindeutig und stimmig?

Sehen Sie weitere Funktionsbausteine, welche noch nicht abgebildet sind? Bitte beschreiben Sie die Relevanz dieser anhand von Beispielen.

*Definition Funktionsbausteine: stellen eine Bündelung gleichartiger technischer Funktionalitäten ohne Komponentenbezug dar.

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

Leitfrage_08_Zusatzmaterial

Update vom 13.12.2023:

Leitfrage_08_Zusatzmaterial_Update_13

D.H - editiert am 18.12.2023

Der Baustein "Identitätsfeststellung" sollte möglicherweise nicht nur die erstmalige Identitätsfeststellung, sondern auch die nachfolgende "Authentifizierung", die möglicherweise mit einem Pseudonym erfolgen kann, umfassen. Insofern sollte man diesen Baustein vielleicht besser "Identitätsfeststellung und Authentifizierung" nennen.

D.H - editiert am 18.12.2023

Im Baustein "Authentizitätsprüfung von Daten/Dokumenten", was technisch letztlich der Validierung von fortgeschrittenen und qualifizierten elektronischen Signaturen und Siegeln entspricht, sollte man auch die Erstellung von Signaturen und Siegeln berücksichtigen. Der Baustein könnte letztlich "Erstellung und Validierung von elektronischen Signaturen und Siegeln" genannt werden.

D.H - editiert am 09.12.2023

Aus meiner Sicht fehlt ein Basisdienst für den "Beweiswerterhalt kryptographisch signierter Dokumente" gemäß BSI TR-03125 geben.

D.H - editiert am 19.12.2023

Da vermutlich bis auf Weiteres auch noch papiergebundene Anträge eingehen werden, sollte es einen Basisdienst für das "Ersetzende Scannen" gemäß BSI TR-03138 (RESISCAN) geben.

T.G - editiert am 28.01.2024

IBM: Es ist schwierig, den aktuellen Arbeitsstand der Funktionsbausteine inhaltlich zu bewerten. Ohne Kenntnis der zugrundliegenden Datenbasis für Nutzendenreisen und Prozessmodellen kann unserer Einschätzung nach keine strukturierte Validierung der vorliegenden Arbeitsergebnisse erfolgen.

Unser Verständnis ist, dass sich Funktionsbausteine aus „Nutzendenreisen und Prozessmodelle“ ableiten (vgl. „Methodik der Erarbeitung Zielbild der OZG Rahmenarchitektur“). Diese in der „Bottom-Up“ Planung identifizierten Bausteine sind anschließend nutzendenübergreifend zu generalisieren. Analog ist mit Prozessen zu verfahren. Auch wenn Antragsprozesse den mehrheitlichen Anteil im OZG Kontext darstellen, sind weitere Prozesse (z.B. Widerspruchsverfahren) denkbar. Wir empfehlen daher, Prozessunterstützung zu generalisieren und sie z.B. in Form von Universalprozessen vorzusehen.

Der Funktionsbaustein ist aktuell wie folgt definiert: „…Bündelung gleichartiger technischer Funktionalitäten ohne Komponentenbezug dar.“

Dies steht unserer Meinung nach im Widerspruch, dass Funktionsbausteine das „WAS“ beschreiben (vgl. „Überblick Methodik der Erarbeitung Zielbild der OZG-Rahmenarchitektur“).

Wir regen an, dass Funktionsbausteine rein fachlich und somit ohne technische Bezug definiert werden. Ziel ist es somit, fachliche Bausteine zu identifizieren, die durch unterschiedliche technische Bausteine umgesetzt werden können.

Gerne möchten wir trotzdem auf Grund unserer empirischen Erfahrung, beispielhaft punktuelle Vorschläge einbringen. Aus Sicht der Antragstellenden sehen wir (fachliche) Funktionsbausteine für Antragstellende:

- Dokumentenspeicher: Speicherung von Dokumenten (z.B.: Anträge, Nachweise etc.). Nutzenden können Dritten (z.B.: Verwaltung, etc.) bedarfsweise Lese-Zugriffe auf Dokumente gewähren.

- Postfach: Sichere elektronische Zustellung von Dokumenten und Bescheiden.

- Assistenzsysteme: (Intelligente) Assistenzsystem unterstützen Nutzenden in unterschiedlicher Weise z.B. durch Chat, Suche, Vorausfüllen von Anträgen, etc.)

- Universelle Prozessunterstützung: Fachliche Bausteine zur Unterstützung universeller Fachprozesse. Hierzu gehören u.a. Prozessstatus, Vertreterregelung, Freigabeprozesse (z.B. für Antragstellende Organisation), Fristen, etc.

- Antragstellung: Umsetzung von intelligenten Formularen. Stammdaten können automatisch vorausgefüllt werden. Es besteht die Möglichkeit Formulare im Dokumentenspeicher zwischenzuspeichern.

- Rollen- und Berechtigung: Möglichkeit der Anlage von unterschiedlichen Rollen z.B. Vertreter, Beteiligte (z.B. für Freigabeprozesse).

M.M - editiert am 12.01.2024

Aus Sicht der Arbeitsgruppe Offenes Design digitaler Verwaltungsarchitekturen (opendva.de, FSU Jena und Partner) fehlt ein wichtger Punkt: * Zentrale Bereitstellung aller relevanten Informationen. * Begründung: * Ein Hindernis für eine übergreifende (und damit interoperable) Digitalisierung der Verwaltung ist die Kenntnis aller relevanten Normen, bereits vorhandener Komponenten und klare (ggf auch formale) Definition zentraler Begrifflichkeiten. Ohne eine zentrale Anlaufstelle besteht die Gefahr unterschiedlicher Interpretationen durch verschiedene Stakeholder (auch aufgrund mangelnder Information) und so einer Zerfaserung in der Umsetzung * Weiterhin sollten etablierte Standards genutzt und so ausgebaut werden, dass sie nicht nur kanalneutral sind sondern auch wirklich digital interpretierbar sind. Damit wird der Austausch zwischen und innerhalb der Bausteine standardisiert. * FIM liefert bereits genügend Material für die Funktionsbausteine “Identitätsfeststellung”, “Kommunikation”, “Verkündung von Bescheiden”, “Authentizitätsprüfung von Daten/Dokumenten”, “Datentransport” und “Abruf von Daten und Nachweisen”. Die dabei benutzten Verfahren sollten auch in den künftigen Funktionsbausteinen angewendet werden. * FIM liefert 8 Referenzaktivitätengruppen (RAG), die auf Teilprozessebene zur Beschreibung von Prozessschritten in Verwaltungsprozessen geeignet sind. Diese müssen beachtet werden, da sie (a) bewährt und (b) dem bestehenden XöV-Standard XProzess (ab Version 2.0) zugehörig sind. Zur Dokumentation siehe “FIM-Baustein Prozesse, Fachkonzept, Version 1.01 vom 31.07.2020”, verfügbar im FIM-Portal, Bereich “Dokumente”. FIM-Stamminformationen sollen gemäß Programmmanagement-Dokument des OZG als Ergebnis aller OZG-Leistungen vorliegen und werden außerdem für EfA-Lösungen im Steuerungsindikator 10 gefordert. Sie sollten also als vorhanden vorausgesetzt werden und könnten dann stets benutzt werden. Dass sie in der Praxis nicht immer vorliegen bedeutet nur, dass die Arbeit im jeweiligen Themenfeld gemäß der OZG-eigenen Kriterien nicht abgeschlossen ist und fehlende Ergebnisse nachzuliefern sind. FIM beschäftigt sich mit der Abbildung von Verwaltungsleistungen auf Basis der Rechtsgrundlagen und aus Sicht der vollziehenden Verwaltung. Die RAG betreffen damit sinngemäß die Funktionsbausteine “Identitätsfeststellung”, “Kommunikation”, “Verkündung von Bescheiden”, “Authentizitätsprüfung von Daten/Dokumenten”, “Datentransport” und “Abruf von Daten und Nachweisen”. * Für den kommenden Standard XProzess 3.0 (aktuell noch in der Abstimmung zwischen FIM-Baustein Prozesse, BMI und Nutzendenbeirat) ist zusätzlich zu den für FIM benötigten RAG die Unterstützung der Modellierung mit getypten Referenzaufgaben (RA) vorgesehen, die zur Modellierung von Prozessen auf Detaillierungsstufen unterhalb von Stamminformationen geeignet sind. Zur Dokumentation siehe "FIM-Baustein Prozesse, QS-Kriterien für OZG-Referenzprozesse, Version 1.01 vom 23.03.2023", verfügbar im FIM-Portal, Bereich "Dokumente". Die RA betreffen betreffen damit sinngemäß die Funktionsbausteine "Antragstellung", "Identitätsfeststellung", "Kommunikation", "Verkündung von Bescheiden", "Authentizitätsprüfung von Daten/Dokumenten", "Datentransport" und "Abruf von Daten und Nachweisen". Wegen der Verankerung im kommenden Standard sollten auch die RA bei der feineren Spezifikation der Funktionsbausteine beachtet werden. Mit ihnen lassen sich in Nachnutzung der FIM-Stammprozesse sogenannte Referenzprozessmodelle erstellen, die in Verbindung mit Stamm- oder Referenzdatenschemata (im XöV-Standard FIM-Datenfelder standardisiert) geeignet sind, direkt ausführbare Prototypen zu generieren. Die dabei benutzten Verfahren sollten auch in den künftigen Funktionsbausteinen angewendet werden.

S.M - editiert am 22.12.2023

Bundesagentur für Arbeit: Generell wird die Darstellung unterstützt. „Entwicklung ohne umfangreiche Programmierkenntnisse“ entspricht aus der Sicht der BA eher einer Methodik als einem Funktionsbaustein und ist aus unser Sicht kein zwingender Bestand-teil oder Voraussetzung für eine OZG-Rahmenarchitektur.

T.L.S.P - original vom 18.12.2023

Sofern die Bausteine entsprechend einer logischen bzw. herkömmlichen Prozessabfolge angeordnet werden sollen, schlagen wir vor, den Baustein „Datentransport“ zwischen „Regelbasiertes Anstoßen von Verwaltungsleistungen“ und „Zustellung an Vorgangs- und Sachbearbeitung (Dienststellennummer)“ anzuordnen.

Darüber hinaus schlagen wir vor, den Baustein „Datentransport“ wie folgt zu ergänzen: „Datenkonvertierung, -routing und -transport“. Über diese Ergänzung wird abgebildet, dass Daten den richtigen Weg vom Sender zum Empfänger finden, sowie, das Daten vor dem Transport ggf. in ein Schema bzw. Format überführt werden, dass vom Empfängersystem verarbeitet werden kann. So lange Daten und Schnittstellen nicht einem einheitlichen Standard folgen, wird dieser Schritt notwendig sein. Zudem würde der Schritt selbst bei einem einheitlichen Standard erforderlich sein. Nämlich dann, wenn es zu Weiterentwicklungen von Standards kommt und den Systemen ein Zeitraum zur Migration von einem Standard auf den nächsten bzw. einer Version auf die nächste eingeräumt werden soll.

P.S - editiert am 02.01.2024

Die gewählten Bezeichnungen, deren Zuschnitt und die Darstellung sind ohne weitere Erläuterung nicht eindeutig. Je nach Hintergrund können die Begriffe unterschiedlich verstanden werden. Ob die Begriffe stimmig und vollständig sind, können wir daher nicht bewerten. Bspw. ist der Begriff „Kommunikation“ zu unspezifisch: Ist damit die Kommunikation zwischen Behörde und Antragstellenden oder zwischen technischen Systemen gemeint? Wie grenzt sich dies von „Verkündung von Bescheiden“, „Datentransport“ und „Nachweisabruf“ ab?

In die bereitgestellte Abbildung (Leitfrage 08 Zusatzmaterial.pdf) kann eine Struktur hineingedeutet werden (bspw. hinsichtlich Anordnung und Größe der Rechtecke), die auch nützlich für die Bewertung der Vollständigkeit wäre, sie geht aber nicht eindeutig daraus hervor.

Wir empfehlen für jeden Baustein eine klare Definition, Abgrenzung und Beispiele zu erstellen und die Struktur der Abbildung explizit zu machen.

Zur Einordnung der Funktionsbausteine wäre es zudem hilfreich, wenn bereits jetzt die noch nachfolgenden Beschreibungselemente der Rahmenarchitektur und deren Abhängigkeiten bekannt wären (ein „Metamodell“ der Rahmenarchitektur).

A.K - editiert am 28.01.2024

Hier der Beitrag von Red Hat.

Zur Eindeutigkeit und Stimmigkeit:

Eine Rahmenarchitektur ist sicherlich kein Selbstzweck, sondern stets auf ein bestimmtes Ziel hin ausgerichtet. Dieses Ziel ist hier nicht konkret benannt, das erschwert natürlich insgesamt eine Bewertung.

Grundsätzlich bietet es sich an, auf gängige Architekturmodelle zurückzugreifen, die sich schon im realen Einsatz bewährt haben, da liegt man dann schon mal nicht komplett falsch.

Das Vorgehen zur Entwicklung einer Architektur (und das gilt auch für eine Rahmenarchitektur) startet normalerweise bei den Geschäftszielen und -prozessen, bzw. den zu unterstützenden Aufgaben und Tätigkeiten auf Geschäftsebene. Bei OZG sind dies die jeweiligen umzusetzenden Verrichtungen bzw. Leistungsangebote für Bürger und Unternehmen. Soweit diese über konsolidierte und abgestimmte Prozesse beschrieben sind, kann hieraus (etwa mittels eines EAM Frameworks wie TOGAF) eine Enterprise Architektur abgeleitet werden, die wiederum als Vorlage für eine technische Architektur dient. Letztere kann sich als logische Architektur auf die funktionalen Aspekte der als Implementierungsarchitektur auf Implementierungsvarianten beziehen.

Hier ist nicht eindeutig definiert, auf welche Art von Architektur die OZG Rahmenarchitektur abzielt, was genau die Ausgangslage ist, und wo sich diese im Gesamtprozess einfügt.

Für eine Rahmenarchitektur bedarf es zusätzlich einer Abgrenzung bzw. einem Schnitt, worin genau der Rahmen liegen soll, und was nicht mehr Teil des Rahmens sein soll.

Die Festlegung von Funktionsbausteinen sollte sich in jedem Fall an den Prozessanforderungen und den benötigten Fähigkeiten sowie an den auf dem Markt verfügbaren Lösungen orientieren, um diese ggf. im Rahmen der Umsetzung der Architektur berücksichtigen zu können. Dies sollte auf einem Abstraktionsniveau erfolgen, das eine Auswahl unter mehreren verfügbaren Lösungen ermöglicht. Wo keine bereits passenden Lösungen vorhanden sind, sollte eine Eigenentwicklung in Betracht gezogen werden.

Abhängig von der Marktverfügbarkeit geeigneter Lösungen erfolgt der Service-Schnitt also entweder anhand marktgängiger Lösungen oder im Falle einer Eigenentwicklung durch direkte Ableitung aus den Fachprozessen. Auf diese Weise wird sichergestellt, dass in jedem Fall Lösungsalternativen existieren.

Bei einer Eigenentwicklung bietet sich an, die Funktionsbausteine anhand der tatsächlichen Prozessabläufe und Fähigkeiten zu ermitteln. Legt man mehrere Prozessabläufe übereinander, so finden sich hinsichtlich der benötigten Funktionen in der Regel Gemeinsamkeiten, die sich wiederum in gemeinsam genutzten Services verorten lassen. Die Umsetzung erfolgt idealerweise mithilfe von Frameworks und Bibliotheken aus dem Open Source Bereich.

Die im Schaubild dargestellten Bausteine spiegeln einen Teil dessen wider, was im Rahmen eines Antragsverfahrens benötigt wird. Es ist allerdings nicht ersichtlich, in welcher Beziehung die Bausteine zueinander stehen und welche Aufgabe durch den jeweiligen Baustein im Einzelnen abgebildet werden soll. Grob scheinen drei Domänen eine Rolle zu spielen: das Antragsverfahren selbst, die Entwicklung der hierzu erforderlichen Softwarekomponenten, sowie ein Betrieb, der möglicherweise auf die Antragsplattform, oder auf die Entwicklungsplattform, oder auf das Fachverfahren selbst abzielt. Es steht zu vermuten, dass alle drei gemeint sind. Im Betrieb wird wiederum unterschieden zwischen “Betrieb von IT-Anwendungen und Systemen” und “Betriebsunterstützung” bei der wohl (mit Blick auf ITIL) eher ein IT-Servicemanagement gemeint ist. Diese Unterscheidung ist nicht ohne Weiteres nachvollziehbar.

Insofern muss die Frage, ob Zuschnitt und Bezeichnung hier eindeutig sind, wohl eher mit “nein” beantwortet werden.

Zu fehlenden Diensten:

Es fällt etwas schwer, weitere Dienste zu identifizieren, die in dieses Schema passen, einfach weil die Systematik nicht klar ist.

Etwas einfacher wird es für Infrastrukturdienste (Virtualisierung, Container-Plattform, Identitätsmanagement etc.) und Dienste des Anwendungsmanagements (Anwendungsspeicher/Registry, Onboarding von Anwendungen, Inbetriebnahme, Anwendungsmonitoring etc.), da diese generell nicht enthalten sind. Diese wären also vollständig zu ergänzen.

Hier stellt sich wiederum die Frage nach dem Betrachtungsfokus der Rahmenarchitektur. Natürlich kann man Infrastruktur und Anwendungsmanagement komplett ausblenden, allerdings ist genau dies auch bereits im Rahmen von OZG 1.0 erfolgt, und hat letztlich dazu geführt, dass die wichtigen Infrastrukturfragen, etwa hinsichtlich der Eignung von Cloud-Angeboten öffentlicher IT-Dienstleister oder auch von Hyperscaler-Angeboten für Antragsverfahren sowie die regelkonforme und souveräne Nutzung von Multi-Cloud bis heute mit Blick auf OZG weitgehend ungelöst sind.

Natürlich besteht die Möglichkeit, auf andere Rahmenwerke wie die Deutsche Verwaltungscloud-Strategie (DVS) zu verweisen. Allein es liegt an der OZG Rahmenarchitektur, hier aus fachlicher Sicht entsprechende Anforderungen an die benötigte Infrastruktur - einschließlich Betriebsprozesse - zu formulieren. Als Vorschlag für eine Systematik hier folgender Entwurf für eine technische Rahmenarchitektur (angelehnt an die Architekturvorgaben der Deutschen Verwaltungscloud-Strategie):

Diese Systematik ist erst einmal unabhängig davon, ob logische Funktionsbausteine oder konkrete Lösungsalternativen (als Eigenentwicklung oder als Produkt) eingesetzt werden. Die Darstellung orientiert sich dabei an folgenden Maßgaben:

Akteure werden anhand ihrer jeweiligen Domänen identifiziert

Governance leistet die Steuerung nahezu aller Domänen

Die gesamte Digitalisierungskette wird Ende-zu-Ende abgebildet

Sachbearbeiter steht stellvertretend für Antrags- bzw Anliegenprüfung

Clearingstelle behandelt Fälle, die nicht technisch lösbar sind

Nutzungs- und Steuerungsbeziehungen werden kenntlich gemacht

Nutzung und Administration sowie Fach- und IT-Administration werden jeweils separiert dargestellt

Die Aufteilung in horizontale Ebenen veranschaulicht den Abstraktionslevel und gleichzeitig die Wer-benutzt-was-Beziehung

Antragsverfahren wird separiert von den (verfahrensunabhängigen) internen oder externen Fachdiensten wie Servicekonto, Bezahlverfahren, Authentizitätsprüfung Registerzugriff oder Bescheidzustellung

Zentral bereitgestellte Entwicklungsumgebungen (Developer-Stack, Entwickler-Cloud) sind berücksichtigt

Fachdomäne (grau) und IT-Domäne (rot) werden separiert dargestellt, um eine grundsätzliche Unabhängigkeit und damit Wahlmöglichkeit zu demonstrieren

Infrastrukturebene wird als Cloud-Services (wahlfrei hinsichtlich des Infrastruktur-Providers) konform zur Deutschen Verwaltungscloud-Strategie (DVS) ergänzt

Die wichtigsten Funktionsbausteine für die Infrastrukturebene sind im Entwurf dargestellt. Bei der Ergänzung von Funktionsbausteinen für die Bereiche Fachverfahren und Fachdienste ist zu berücksichtigen, dass auch dort wichtige, ebenenübergreifende Aufgaben wie IT-Sicherheit selbstverständlich repräsentiert sind. Der Entwurf enthält keine Festlegungen zu Topologie oder Verortung, diese sind im Idealfall im Rahmen regulatorischer Vorgaben sowie unter Absicherung durch geeignete Verträge frei bestimmbar. Nicht abgebildet ist der Aufbau der Zugangskette (Consumer-> technischer Zugang -> Frontend -> Backend). Die Liste der Cloud-Services ist natürlich nicht vollständig, diese Liste lässt sich je nach Anwendungsfall nahezu unbegrenzt verlängern.

Sobald die Systematik der OZG Rahmenarchitektur insgesamt deutlicher wird, ist auch eine Kommentierung bzw. Ergänzung der Funktionsbausteine in der Fachdomäne möglich.

T.G - original vom 21.12.2023

Sehr gute Anregungen zur Erstellung von Architekturen!

A.K - original vom 21.12.2023

Vielen Dank!

D.H - original vom 28.01.2024

Ja, das ist aus meiner Sicht schon ein sehr guter Entwurf. Aus meiner Sicht sollten aber noch Kleinigkeiten geändert werden: 1. Man sollte zwischen den Nutzern und Diensten eine explizite Zugriffsschicht vorsehen, die in Form von Webapplikationen (Portalen) bzw. Smartphone Apps realisiert werden können. Diese Frontends nutzen Fach- und Basisdienste. 2. Man sollte zwischen Fach- und Basisdiensten unterscheiden (Fachdienste sind anwendungsspezifische Microservices, Basisdienste sind generische Dienste (z.B. Identitätsmanagement und Signatur), Fachdienste nutzen Basisdienste, Basisdienste sorgen für die Integration mit Registern und den EU-Diensten. 3. Man sollte die Integration mit den Europäischen Strukturen, Diensten und Standards (z.B. bzgl. eIDAS und SDG) und Register ergänzen. Die Register sollten über einheitliche Schnittstellen, z.B. auf Basis von OAuth 2.0 (RFC 6749) zugreifbar gemacht werden. 4. Governance sollte ein "übergeordnetes Kästchen" sein; insofern wäre es aus meiner Sicht besser , die Nutzer:innen in den verschiedenen Rollen (Bürger:in, Unternehmer:in, Verwaltungsangestellte(r), Betreiber:in) unten am Bild anzuordnen, dies soll auch die Betonung des "benutzerzentrierten Ansatzes" unterstreichen. 5. Der Betrieb der entsprechenden Dienste kann, wie skizziert, auf verschiedenen (geeignet zertifizierten) Plattformen erfolgen, wobei man sich sinnvollerweise auf geeignete Basistechnologien wie z.B. Kubernetes, Helm, OCI, OpenAPI etc. einigen sollte. 6. Um die verschiedenen Organisationen, Dienste und Ressourcen im "Verwaltungsökosystem" auffindbar und nutzbar zu machen, sollte es wie in Gaia-X einen "SSI_Self_Description_EN_V3" geben, in dem standardisierte, maschinenlesbare Selbstbeschreibungen (z.B. auf Basis von "Verifiable Credentials") geben.

Ein Bild, wie ich mir das insgesamt vorstelle folgt asap (ggf. aber erst morgen).

D.K - original vom 29.12.2023

Zugang zu Bürgerinnen & Bürger sowie Organisationen & Unternehmen (Frontoffice- Sicht zum Kunden):

Portale/Apps/Snippets (zur Darstellung, Findung in Suchmaschinen, Direktverlinkung)

Das beinhaltet die:

Informationsdarstellung zu Verwaltungsleistungen (Inhalte verständlich darstellen)

Identifizierung von Verwaltungsleistungen auf das Bürger- oder Unternehmensproblem (Die Textanfrage ist passend zu welchem LeiKa-Code?)

Identifizierung von zuständigen Stellen (Wer ist für den LeiKa-Code in meiner Region zuständig?)

Vorab-Klärung von Fragen (Welche Unterlagen sollen vorhanden sein, welche Gebühren fallen an (= s. LeiKa))

Antragstellung mit Ausfüllhilfen und Assistenten; Vorab-Ausfüllung von Anträgen mittels vorhandener Stamm- und Registerdaten

Basisdienste (Technisch darin enthalten bzw. im Prozess verbaut ist):

Authentifizierung, Identitätsfeststellung in verschiedenen Vertrauensniveaus

Bezahlung bi-direktional

Kommunikation bi-direktional (hier kann auch der Rückweg der Bescheide in die Kommunikation einbezogen werden)

Registerabfragen (im Antragsprozess einbetten, um unnötige Datenabfragen zu sparen)

Dokumentenupload und Prüfung

Anstoßen von Folgeprozessen auf Basis von Regeln (z.B.: nach der Gewerbeanzeige folgt der Antrag für die Steuernummer)

Entwicklung und Betrieb (Verwaltung im Backoffice, Zugang für die Verwaltung):

Datentransport

Abholung von der zuständigen Stelle

Zusätzlicher Abruf von Daten und Nachweisen über Drittregister

Pflege von lokalen Parametern (liegt in der Zuständigkeit der zuständigen Stelle, das macht hier keinen Sinn – außer es ist gemeint, die Daten im ZuFi zu regionalisieren, was aber seit Jahren bereits über die Landesredaktionen gelöst ist)

NEU eingefügt werden sollte: Workflow zur internen digitalen Bearbeitung in der Behörde und Behördenübergreifend (mit dem entsprechenden Kommunikationskanal zurück)

Authentifizierung von Behörden und Behördenmitarbeitern (verbunden mit zuständigen Stellen und deren Fachverfahren, damit behördenübergreifende Zusammenarbeit ermöglicht wird)

Entwicklung und Betrieb (Technischer Hintergrund):

Betrieb

Betriebsunterstützung

OpenCoDE zur Ablage der Software im Front- und Backoffice, Community der Entwickler und Anwender

Softwareentwicklung, Tests, die Bereitstellung: CI/CD, automatischen IT-Sec-Prüfungen, Lizenz-Compliance-Prüfungen

Die Softwareentwicklung ohne Programmierkenntnisse kann mittels LowCode (Formulare, Workflows, etc.) erfolgen.

SEITENBAU - editiert am 08.01.2024

Update (08.01.2024): Der Kommentar bezieht sich noch auf die ältere Version des Zusatzmaterials (Leitfrage 08 Zusatzmaterial.pdf). Einige der unten genannten Punkte haben sich mit der neuen Version erledigt oder abgeschwächt.

Allgemeines

Verständlichkeit/Intuitivität der Darstellung: Aktuell scheint die Grafik die Funktionsbausteine nach Zeilen zu strukturieren (1. Nutzendensicht, 2. Funktionale Bausteine, 3. Zustellung, 4. Entwicklung und Betrieb). Um die Verständlichkeit zu verbessern, würden wir vorschlagen, diese (oder eine andere geeignete) Strukturierung der Bausteine explizit sichtbar zu machen (z.B. durch Anzeige und Beschriftung von Bereichen oder Achsen).

Umfang und Abgrenzung des Betrachtungsraums: Ebenfalls würde wir vorschlagen, dass eine Definition des Betrachtungsraums ergänzt wird. An folgenden Fragen möchten wir aufzeigen, dass uns der Umfang des Betrachtungsraum nicht unmittelbar klar wird:

Sind Antragsbearbeitung/Fachverfahren Teil des Betrachtungsraums?

Inwieweit ist die Entwicklung Teil des Betrachtungsraums? Warum gibt es den Baustein "Entwicklung ohne umfangreiche Programmierkenntnisse", aber keinen Baustein für die Entwicklung mit darüber hinausgehenden Programmierkenntnissen?

Bewertung von Zuschnitt und Bezeichnung

Zu folgenden Funktionsbausteinen möchten wir eine Rückmeldung geben:

Identifizierung passender Verwaltungsleistungen & Vorab-Klärung von Fragen: Wir gehen davon aus, dass es sich hier um die Sicht des Nutzenden handelt. Die oben angesprochene Verständlichkeit der Darstellung könnte ausschließen, dass hier nicht möglicherweise die Kommune bei der Wahl eines Online-Dienstes gemeint ist.

Antragstellung: Die Antragstellung umfasst auch einige der Funktionsbausteine aus der Zeile zwei der Darstellung. Damit wäre der Zuschnitt aber nicht eindeutig abgegrenzt. Ist hier nicht eher "Antragsdatenerfassung" durch den Nutzenden gemeint?

Kommunikation: Hier schlagen wir die Präzisierung "Kommunikation zum Antragsteller" vor, falls das gemeint war (vgl. auch Abgrenzung Betrachtungsraum oben.) Je nach Definition des Betrachtungsraums könnte auch ein eigener Baustein für die andere Kommunikationsrichtung ergänzt werden.

Bi-Direktionale Zahlung: Welcher Anwendungsfall ist hier mit der Rück-Richtung der Zahlung gemeint? Auch hier spielt vermutlich die Abgrenzung des Betrachtungsraums eine Rolle. Werden keine Fachverfahren betrachtet, gibt es möglicherweise keine Rück-Richtung.

Zustellung und Datentransport: Wie grenzen sich die beiden Bausteine zueinander ab? Wir schlagen vor, dass eine entsprechende Präzisierung ergänzt wird.

Pflege von lokalen Parametern: Was soll mit diesem Funktionsbaustein ausgedrückt werden? Ist hiermit die Aktivierung eine Online-Dienstes durch die zuständige Stelle gemeint? Was sind "lokale Parameter"? Parameter für Zustellung/Zuständigkeit (z.B. Destination-ID, Zertifikate bei Fit-Connect, Payment-Parameter etc.) und/oder Customizing (Logo, Impressum, Angaben zum Datenschutz, Support, fachliche Parameter wie bestimmte Gebühren, Hebesätze)

Testen und Bereitstellung von Eigenentwicklungen: Dieser Funktionsbaustein lässt zu viel Interpretationsspielraum. Was sind Eigenentwicklungen, aus welcher Sicht ist das "Eigen"? Warum wird Entwicklung selbst nicht erwähnt oder wird hier auf den nebenstehenden Baustein (ohne umfangreiche Programmierkenntnisse) bezogen?

Zugang zu Fachverfahren: Auch hier könnte der Interpretationsspielraum noch verkleinert werden. Wer benötigt warum Zugang? Annahme: Integrations-, Rollout, Test- und Supportzwecke.

Betriebsunterstützung: Was ist genau gemeint und warum wird nur hier ITIL erwähnt?

Aus unserer Sicht nicht abgebildete Bausteine

Rollout: Beim Rollout (z.B. eines Online-Dienstes) müssen mehrere Stakeholder tätig werden und u.a. folgende Aufgaben lösen: Test der Integration, Aktivierung, Pflege und Tests der fachlichen und technischen Parameter, Freischaltungen (fachlicher, technischer Natur) und ggf. Publizieren (z.B. Verlinken auf Service-Portalen).

Abstimmung SLAs: Bei einer angestrebten kooperierenden Architektur wichtig, wenn mehrere kollaborierenden Systeme auf einander angewiesen sind.

Wartung von Entwicklungen: Falls nicht in einer der bereits genannten Funktionsbausteine integriert, gehört die Wartung dazu.

Bearbeitung einer Antragstellung, falls der Betrachtungsraum das umfassen soll.

F.K - original vom 05.01.2024

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen:

Wir finden die Bausteine zu stark aus technischer Sicht geplant. Stattdessen ist uns die konzeptionelle Sicht sehr wichtig aus Kundensicht (Verwaltung) inklusive Anforderungsmanagement, sowie die zukünftige Entwicklung (nicht nur aus technischer Sicht ). Beispiel Hausbau: Planung und Konstruktion nach bestem Wissen und Gewissen; nach Fertigstellung stehen weiterer Unterhalt und Wartung an, sind Reparaturen/Renovierungen notwendig und aus Erfahrungen können Lessons Learned gezogen werden um Fehler/Mängel zu korrigieren und entsprechende zukunftsgerichtete, ggf. Nachhaltige Anpassungen vorzunehmen. Außerdem ist manchmal eine Renovierung oder ein Anbau gewünscht.

Daher schlagen wir vor den ganzen Verwaltungsprozess ganzheitlich abzubilden:

Ebene Nr. 1 -> Als Bürger-Ebene benennen -> Feedback vergleichbar zu NFK

Ebene Nr. 2 -> Als Verwaltungshandelns-Ebene benennen

Ebene Nr 3. -> Als Technische-Verarbeitungs-Ebene benennen

Ebene Nr. 4 -> Als Technische Betrieb und Entwicklungs-Ebene benennen

Entwicklung ohne umfangreiche Programmierkenntnisse -> Verstehen wir als Low Code.

Kollaboration und Kommunikation unter Entwicklern

Ergänzen um Training

Changemanagement & Priorisierung in Abstimmung mit dem Kunden

Weitere Ebene (Nr. 5) darunter oder als Querschnittsebene rechts, senkrecht (ist Voraussetzung für Ebene Nr. 4, in der der die technische Umsetzung erfolgt)

Als OZG-Steuerungs-Ebene benennen

Management des Leistungskatalogs (hinzufügen, ändern, löschen)

FIMbasierte OZG-Referenzinformationen (FIM, OZG-Referenzinformationen, Leistungsbeschreibungen, Datenfelder, Prozesse etc. hinzufügen, ändern, löschen)

Fortbildung/Wissensmanagement & Vernetzung & Kommunikation zu Mitarbeitern (zu FIM, OZG etc.) -> Anforderungsmanagement

Qualitätssicherung (außerhalb von Technik) & Evaluation, z.B. der Leistungen, des gesamten Prozesses

D.T.OZG.S - editiert am 29.01.2024

Vorbemerkung:

Aus Sicht der Deutschen Telekom AG sollten internationale Standards für das IT-Architekturmanagement eingesetzt und adaptiert werden. TOGAF ist ein solches Framework und bietet methodische und strukturelle Tools, eine Enterprise-Architektur zu entwerfen und umzusetzen. Eine Architektur nach TOGAF abstrahiert die vorliegende Aufbau- und Ablauf-Organisation, Anwendungen und Technologien in Fähigkeiten („Capabilities“). Capabilities werden üblicherweise auf unterschiedlichen Ebenen / Leveln definiert; d.h. eine Capability in Level 1 besteht aus mehreren einzelnen Capabilities. Entscheidend ist, dass die Capabilities in Bezug auf die Struktur in homogenem Detaillierungsgrad erfolgt.

Diese Abstraktionsschicht fördert die detailliertere Trennung einzelner Architektur-Bausteine, der Identifizierung fehlender Bausteine, eliminiert Überschneidungen und optimiert das Management der OZG-Rahmenarchitektur.

Zu a)

Die vorliegenden Bezeichnungen der Funktionsbausteine sind interpretationsfähig, da sie keine Beschreibung beinhalten. Entscheidend für den Erfolg der OZG-Rahmenarchitektur ist ein einheitliches Verständnis der (Funktions-) Bausteine. Unterschiedliche Interpretationen einzelner Bausteine werden die Definition und die Umsetzung der OZG-Rahmenarchitektur beeinträchtigen. Die OZG-Rahmenarchitektur sollte Bausteine so beschreiben, dass eine unterschiedliche und falsche Interpretation vermindert wird.

In Bezug auf die tatsächliche Bereitstellung der Fähigkeit / der Funktion sollten Entwicklungs- und Betriebsmodelle an dieser Stelle nicht präjustiziert werden. Die Entscheidungen bspw. bzgl. föderalem / zentralen Betrieb, Open-Source vs. Closed Source sollten nach Evaluierung innerhalb des Funktionsbausteins im Rahmen der Implementierung getroffen werden.

Die definierten Funktionsbausteine bieten eine gute Diskussionsgrundlage. Die nachstehenden Fragestellungen bestehen aus Sicht der Deutschen Telekom. Weitere Fragestellungen könnten ggf. entstehen, falls unser Verständnis der Funktionsbausteinen von dem (impliziten) Umfang abweicht.

Umfasst „Antragsinitiierung und -stellung“ auch Fähigkeiten, Verwaltungsleistungen automatisiert bzw. antragslos zu starten (siehe z. B. Projekt „ELFE, Einfache Leistungen für Eltern“)?

Umfasst „Identitätsfeststellung“ auch Fähigkeiten zur Autorisierung von Anwender:innen (oder ausschließlich die Feststellung der Identität)?

Mithilfe moderner Wallet-Lösungen (eIDAS2.0) können Nutzer:innen sich digital identifizieren und Nachweise für einzelne Organisationen selbstbestimmt freigeben. Dies würde gem. des derzeitigen Zuschnitts der Funktionsbausteine vermutlich „Identitätsfeststellung“ und „Abruf von Bescheiden und Nachweisen “ zuzuordnen sein. Wie wird mit dieser Problematik umgegangen?

Das „Siegeln und Signieren“ umfasst insbesondere Fähigkeiten zur Sicherstellung der Integrität und der Authentizität von Daten. Aufgrund des eher technischen Schnitts dieses Funktionsbausteins sind Überschneidungen zu „Identitätsfeststellung“ und „Abruf von Daten und Nachweisen“ wahrscheinlich (vgl. auch vorherige Nummer).

Die „antragsbezogene Folgekommunikation“ beinhaltet auch die Bereitstellung von Bescheiden/Nachweisen. Der „Abruf von Daten und Nachweisen“ ist eine antragsbezogene Kommunikation. Wie erfolgt die Abgrenzung zwischen den Funktionsbausteinen?

Ist die (antragsbezogene) Unterstützung von Anwender:innen Bestandteil von „Antragsinitiierung und -stellung“, „antragsbezogene Folgekommunikation“ oder eines noch nicht definierten Funktionsbausteins?

Umfasst „antragsbezogene Folgekommunikation“ Fähigkeiten zur Bereitstellung eines Bearbeitungsstatus und verschiedene die verschiedenen erforderlichen Kommunikationskanäle?

Umfasst „Zustellung an Vorgangs- und Sachbearbeitungen“ auch die Kommunikation von Vorgangs- und Sachbearbeitung an antragsstellende Personen? Falls ja, wie erfolgt eine Abgrenzung zu „antragsbezogene Folgekommunikation“ und „Abruf von Daten und Nachweisen“?

Zu b)

Wie bereits erläutert ist die Durchführung einer Gap-Analyse aufgrund der fehlenden Beschreibungen und damit verbundener unterschiedlicher Interpretationsweisen anspruchsvoll.

Nach derzeitigem Verständnis sind folgende Funktionsbausteine nicht vorhanden und sollten innerhalb der OZG-Rahmenarchitektur ergänzt werden.

Fähigkeit (bzw. Funktionsbaustein)

Beschreibung

IT-Sicherheit

IT-Sicherheit ist eine Fähigkeit, die querschnittlich bereitgestellt werden muss. Der Funktionsbaustein umfasst die Fähigkeiten, das Management der IT-Sicherheit zu gewährleisten.

IT Sicherheit ist beispielsweise in Bezug auf die Erstellung von Sicherheitskonzepten, Notfallmanagement sowie Responsible Disclosure-Meldungen relevant. Bei dieser Fähigkeit / Funktionsbaustein handelt es sich um eine unterstützende Fähigkeit im Sinne von TOGAF („supporting Capability“).

Datenschutz

Datenschutz ist eine Fähigkeit, die querschnittlich in verschiedenen anderen Funktionsbausteinen berücksichtigt werden muss. Dieser Funktionsbaustein umfasst die Fähigkeiten, das Management von Datenschutz-Anforderungen und -Pflichten zu gewährleisten.

Datenschutz ist beispielsweise bei dem Design von Onlinediensten, dem Betrieb von Anwendungen und der Durchführung von Auskunftsersuchen des Betroffenen gem. Art. 15 DSGVO relevant. Bei dieser Fähigkeit / Funktionsbaustein handelt es sich um eine unterstützende Fähigkeit im Sinne von TOGAF („supporting Capability“).

Antragsbearbeitung

Antragsbearbeitung stellt Fähigkeiten zur tatsächlichen Bearbeitung des Antrags zur Verfügung. Der Funktionsbaustein umfasst die Fähigkeiten automatisierte Entscheidungen zu treffen, Ermessen auszuüben und Entscheidungen zu dokumentieren.

Im Rahmen eines vollständig digitalisierten Prozesses (Ende-zu-Ende) ist die Antragsbearbeitung und Bereitstellung von Registern wesentlicher Funktionsbaustein. Der Baustein sollte in der OZG-Rahmenarchitektur genannt werden (auch wenn die Implementierung gem. Leitplanken ggf. verwaltungsspezifisch erfolgt).

Vertraulichkeitsschutz

Vertraulichkeitsschutz stellt Fähigkeiten bereit, es verschiedenen Organisationen zu erlauben, die Vertraulichkeit von personenbezogenen Daten über verschiedenen Beteiligten hinweg sicherzustellen.

Vertraulichkeit muss über die verschiedenen Organisationen, Prozesse, Applikationen und Technologien bereitgestellt werden. Die Verwaltung muss die Fähigkeit besitzen, die Inhaltsdaten über die verschiedenen Beteiligten hinweg Ende-zu-Ende zu verschlüsseln (statt Transportverschlüsselung). Bei dieser Fähigkeit / dieser Funktionsbaustein könnte eine der Fähigkeit „Datenschutz“ untergeordnet werden.

Detektion

Detektion stellt die Fähigkeit bereit, widerrechtliche Verarbeitungstätigkeiten zu erkennen und zu behandeln.

Die Verarbeitung der Daten muss über verschiedene Organisationen hinweg rechtskonform erfolgen. Die öffentliche Verwaltung muss nachweisen, dass wie die (personenbezogenen) Daten verarbeitet wurden (Sicherheitsvorfälle, Audit-/Reporting). Bei dieser Fähigkeit / Funktionsbaustein handelt es sich um eine unterstützende Fähigkeit im Sinne von TOGAF („supporting Capability“). Bei dieser Fähigkeit / dieser Funktionsbaustein könnte eine der Fähigkeit „IT-Sicherheit“ untergeordnet werden.

Nutzungsanalyse

Nutzungsanalyse beschreibt die Fähigkeit, die Nutzung der Online- und Basisdienste zu erheben, um aus den Daten Optimierung für die Nutzung zu planen und umzusetzen. Die Nutzungsanalyse umfasst qualitativ und quantitative Aspekte (NFK und Webanalyse).

Die Nutzungsanalyse ist bspw. relevant für Onlinedienste-anbietende Behörden zur Erkennung von Abbruch-Quote auf bestimmten Seiten („Exit-Rate“) oder zu Bewertung von qualitativem Feedback.

Beteiligung und Kommunikation

Beteiligung und Kommunikation beschreibt die Fähigkeit, den Lebenszyklus von Online- und Basisdienste mithilfe der Beteiligung von bzw. Kommunikation an Dritte (Stakeholder) zu optimieren.

Beteiligungen und Kommunikation zu Online- und Basisdiensten sind im Rahmen des gesamten Lebenszyklus erforderlich. Bei dieser Fähigkeit / dieser Funktionsbaustein handelt es sich um eine unterstützende Fähigkeit im Sinne von TOGAF („supporting Capability“).

D.U - original vom 06.01.2024

Aus Sicht der Infora GmbH/Materna SE halten wir die Bausteine der Kategorien "Zugang für Bürgerinnen und Bürger sowie Organisationen und Unternehmen" und "Basisdienste" grundsätzlich für richtig. Die Kategorie ist im Grunde den (allgemein nutzbaren) Basisdiensten (für die Sachbearbeitung) zuzuordnen. Davon zu unterscheiden sind ggf. identifiziere fachaufgabenspezifische Dienste (vgl. Rahmenarchitektur IT-Steuerung Bund mit Fachdiensten).

Folgende Aspekte sollten insbesondere noch berücksichtigt werden:

Betriebs- und Entwicklungsthemen sind unabhängig von der OZG-Rahmenarchitektur für die öffentliche Verwaltung relevant. Der Entwurf lässt jedoch offen, wie die Bausteine der Reihe "Entwicklung und Betrieb" in das Thema Rahmenarchitektur und deren Funktionsbausteine hineinspielen. Wir empfehlen, hierzu eine gesonderte Darstellung mit den zugehörigen organisatorischen Aspekten vorzusehen.

Auf Antragstellenden-Seite fehlt unseres Erachtens das Suchen von Dienstleistungen (im Portalverbund o.ä.). Der Abruf von Daten und Nachweisen stellt für uns einen Basisdienst dar. Dieser Funktionsbaustein ist relevant für alle Beteiligte, also Antragsstellende sowie Antragsbearbeitende.

Grundsätzlich sollte der Dienste-Zuschnitt immer in E2E Prozessen gedacht werden, um für jeden Stakeholder einen Mehrwert und damit Akzeptanz zu generieren – sowohl für die Verwaltung als Organisation als auch deren Mitarbeitenden. Der Bereich “Zugang für Verwaltung” sollte um einen eigenen Baustein zur Bescheiderstellung und Antragsbearbeitung erweitert werden.

Bei den Basisdiensten sollten der Basisdienst E-Akte/DMS vorgesehen werden. Auch sollten andere Arten der Datenhaltung, die nicht veraktungspflichtig sind, berücksichtigt werden.

Ein weiterer übergreifender Funktionsbaustein ist die Barrierefreiheit, die auch Komponenten als Basisdienste umfassen sollte.

E.S - original vom 08.01.2024

Für den Bitkom e.V.

Sind aus Ihrer Sicht Zuschnitt und Bezeichnung eindeutig und stimmig?

Ja, der Zuschnitt ist eindeutig und stimmig. Zu begrüßen wären Beispiele, welche Lösungen / Verfahren / Funktionalitäten ganz konkret durch die einzelnen Funktionsbausteine abgebildet werden.

Sehen Sie weitere Funktionsbausteine, welche noch nicht abgebildet sind? Bitte beschreiben Sie die Relevanz dieser anhand von Beispielen.

Ein weiterer Funktionsbausteine bzw. eine weitere Funktionalität wäre es, auch nicht-antragsbezogene Kommunikation mit Behörden über die Postfächer der Nutzerkonten stattfinden zu lassen. So werden Kommunikationen und Informationen in einem Medium gebündelt.

Der Funktionsbaustein „Identitätsfeststellung“ sollte um den Punkt der „Autorisierung“ ergänzt werden. Dies ist besonders bei Bevollmächtigungen und Stellvertretungen notwendig und ist aus unserer Sicht nicht durch die „Identitätsfeststellung“ abgedeckt.

Wir schlagen außerdem folgende ergänzenden Funktionsbausteine (für den Bereich Entwicklung und Betrieb) vor:

Rechtsbehelfsverfahren: Die Möglichkeit eines Rechtsbehelfs (außergerichtlich: Widerspruch/Einspruch | gerichtlich: Antrags- und Klageverfahren) ist bei den bisherigen Funktionsbausteinen nicht abgebildet. Welche Prozesse und Grundlagen sind notwendig, um ein solches durchzuführen? Wer ist dazu berechtigt?

Umgang mit Gesetzesänderungen: Gesetzesänderungen führen nicht selten zu geänderten LeiKas und somit zu geänderten Onlinediensten. Wie soll das abgebildet werden und welche Prozesse sind geplant?

Nicht Technischer Support (115): Wie kann einen Nutzer Unterstützung erhalten, wenn er in einem Antrag oder nach Antragstellung Hilfe benötigt.

Datensparsamkeit und -sicherheit: Security ist ein wichtiger Punkt um Vertrauen zu den Nutzern aufzubauen.

Veraktung und Archivierung: Das Festhalten von Anträgen und Entscheidungen ist notwendig für eine revisionssichere und datenschutzgerechte Datenhaltung. Gleichzeitig muss sichergestellt werden, dass Akteneinsicht (siehe § 29 VwVfG) möglich ist.

Soweit von der OZG-Rahmenarchitektur erfasst: sämtliche Vorgänge ab Abgabe der Antragsdaten durch den Nutzenden (Speicherung der Antragsdaten; Bearbeitung des Antrags, Software-unterstützte Sachverhaltsermittlung des Amtswalters; bei mehrstufigen Verwaltungsakten [Beispiel: Baugenehmigung - untere Bauaufsichtsbehörde erlässt Baugenehmigung; Gemeinde muss gemeindliches Einvernehmen erteilen: Kollaboration mit anderen Behörden; [datenschutzgerechte] Archivierung der Vorgangsdaten; Löschen der Vorgangsdaten nach dem datenschutzrechtlichen Löschkonzept).

S.L.B - original vom 08.01.2024

Aus Sicht der Bundessteuerberaterkammer ist die Abbildung von (Organisations-)Strukturen wichtig, damit die Ende-zu-Ende Betrachtung gelingen kann. Um die Wichtigkeit der Organisationen und den dahinterstehenden Vertretungssituationen zu verdeutlichen, sollte ein separater Funktionsbaustein „Vertretung/Bevollmächtigung“ eingeführt bzw. ggf. ein bestehender Baustein (wie Identitätsfeststellung) dahingehend konkretisiert werden. Neben der Identitätsfeststellung ist auch die Authentifizierung/Autorisierung zu berücksichtigen und könnte ggf. als gemeinsamer Baustein abgebildet werden. Oftmals vertreten Steuerberater Unternehmen und Organisationen vollumfänglich. So werden beispielsweise Gewerbeanmeldungen oder ganze Unternehmensgründungen als Vertreter abgewickelt, die Steuerberater werden im Vorfeld dazu bevollmächtigt.

Anzuregen wäre als Funktionskategorie nicht nur den Zugang oder den Abruf von Daten zu betrachten, sondern auch die Bearbeitung von Daten. Nur so gelingt eine medienbruchfreie Abwicklung „Ende-zu-Ende“.

Es ist leider nicht erkennbar nach welchen formalen Strategien die Funktionsbausteine abgeleitet wurden und in welchem Verhältnis diese zueinanderstehen. Eine abschließende Einschätzung fällt daher schwer.

S.H - original vom 08.01.2024

Aus Sicht einer Großstadtkommune (Stadt Frankfurt am Main) noch ergänzend zu den bisherigen Kommentaren, die wir inhaltlich alle unterstützen.

Vorliegende (auch die neue) Darstellung im Hinblick auf die Definition der Funktionsbausteine in der vorliegenden Art ohne Begleitinformationen schwierig; Erläuterung aller unterhalb der Bausteine verorteten Funktionen wichtig - u.a. für:

- die zweifelsfreie Abgrenzung der Bausteine untereinander

- die Vollständigkeitsprüfung

- eine treffende Definition der Oberbegriffe = Name Funktionsbaustein

- die Basis zur Weiterentwicklung/Fortschreibung

- die Transparenz im laufenden Konsultationsprozess und die Weiterentwicklung * Die organisatorischen Prozesse und Anforderungen im Blick behalten, Gesamtbild nicht aus dem Auge verlieren (Was folgt worauf, d.h. aus dem Rechtsrahmen -> das Wie, technisch, organisatorisch)‘ * Zuschnitt und Bezeichnung nicht eindeutig und stimmig -> In neuem Bild fehlen vorherige Bausteine/sind aus neuen Begrifflichkeiten so nicht zweifelsfrei ablesbar (s.gelbe Markierung nachstehendes Bild) * Bausteine nicht vollständig:

Ebene Bürger/Unternehmen

- Ist mit „Anliegensklärung“ die Vorklärung im Sinne der Beratung gemeint? (Hilfe-/ Beratungsfunktionen, Definition der Hilfelösungen bspw. auch Chat, Support?) -> Kann hier auch als Oberbegriff verstanden werden; klarer herausstellen.

- Antragsbescheidung

- Vorabklärungsbezogene Kommunikationsmöglichkeit (zwischen Dienste-Nutzern = Bürger, Unternehmen/Organisation mit zuständiger Stelle = öffentl. Stelle/Verwaltung/Support)

- Nutzerkomfort: bspw. Übersicht und Status der jeweiligen Verwaltungsvorgänge (inkl. Historie), Einsicht/Zugriff auf Bescheide, Nachweise -> bspw. Rechteumsetzung/-wahrnehmung nach DSGVO

Ebene Basisdienste (ergänzen)

- Enthält „Kommunikation“ jetzt „Antragsbezogene Folgenkommunikation“ auch Postfachfunktionalität? (vgl. rechtssichere Kommunikation)

- Rückkanal zum Antragsteller (neben Bescheidung auch sonstige Einstellung von Informationen)?

- Support

- Fehlerhandling

- Datenschutzcockpit

- Barrierefreiheit

aus erstem Entwurf, Gap zu Entwurf 2 (s.o.)

R.F - original vom 08.01.2024

Für die Cassini Consulting:

Der Zuschnitt und die Bezeichnungen sind grundsätzlich stimmig. Wir regen in dieser Darstellung kleinere Ergänzungen an: - Widerspruchsverfahren als eigener Zugang, da die antragsbezogene Folgekommunikation i.d.R. einen solchen komplexen Fall wie ein Widerspruchsverfahren nicht gänzlich abbildet. - Erweiterung des Funktionsbausteins "Identitätsfeststellung" um die Authentifizierung - Als weiterer Basisdienst ist aus Sicht der antragstellenden Person der "Abruf von vorhandenen Daten und Nachweisen" relevant. Häufig haben Bürger:innen, Organisationen und Unternehmen erforderliche Angaben im Rahmen von anderen Antragsverfahren eingereicht oder Dokumente von der öffentlichen Verwaltung erhalten. Eine Verwendung dieser bereits vorliegenden Informationen für ein Antragsverfahren trägt dazu bei, die benötigte Zeit für das Antragsverfahren auf Seiten der Antragstellenden zu reduzieren und die Datenqualität zu erhöhen (Once-Only-Prinzip)

Die aktuelle Darstellung der Funktionsbausteine ist v.a. aus technischer Sicht getrieben. Wir sprechen uns dafür aus, den Gedanken der Nutzendenreise stärker einfließen zu lassen. Die konsequente Orientierung an den antragstellenden Personen und Organisationen trägt dazu bei, die Serviceorientierung der öffentlichen Verwaltung zu erhöhen. Der Begriff "Antragsbezogene Folgekommunikation" greift unseres Erachtens zu kurz, da ein Antrag in der Regel nur der Startpunkt eines Prozesses ist, bei welchem Verwaltung und Bürger:innen miteinander kommunizieren. Zudem schließen sich nach positiver Bescheidung des Antrags häufig weitere Anträge an. Die Nutzendenreise sollte sich nicht nur auf einen Antrag, sondern sich auf das gesamte Anliegen der Bürger:innen beziehen.

Beispiele: - Sofern ich als Bürger umziehe, muss ich nicht nur meinen Wohnsitz ändern, sondern auch noch meinen PKW und Hund ummelden. - Wenn ich Opfer eines Diebstahls geworden bin und meine Ausweisdokumente verloren habe, muss ich den Diebstahl anzeigen und die Dokumente neu beantragen. Dies sind aktuell zwei verschiedene Verfahren, da unterschiedliche Behörden adressiert werden. Aus Sicht der Bürger:innen ist dies ein Anliegen. - Sofern ich eine Tätigkeitsanzeige für eine bestimmte anzumeldende Tätigkeit aufgebe, benötige ich eine Bescheinigung in Steuersachen. Auch dies sind aktuell zwei getrennte Verfahren, welche nicht aufeinander referenzieren.

N.L - editiert am 09.01.2024

Die identifizierten Funktionsbausteine adressieren unserem Verständnis nach verschiedene Ebenen der Abläufe. Während bspw. „Kollaboration und Kommunikation unter Entwicklern“ die Entwicklung einer Dienstleistung tangiert, kann der Funktionsbaustein „Identitätsfeststellung“ einen Prozessschritt innerhalb eines Fachverfahrens betreffen.

Es bedarf einer klaren Definition, Ableitung und Zuordnung der einzelnen Funktionsbausteinen. Die Abstraktionsebenen und Anwendungsbereiche sollten trennscharf unterschieden werden, bspw. zwischen Anwendungsfällen, fachlichen Prozessen und technischen Anforderungen. Auf diese Weise können die Inhalte der jeweiligen Funktionsbausteine klarer definiert werden und auch technische oder konzeptionelle Anforderungen einfacher erfüllt werden. Als Referenz können andere Building Block-Ansätze aus dem Digital Public Infrastructure System verwendet werden, wo zentrale Funktionalität identifiziert und beschrieben werden. Die GovStack-Initiative etwa, Leuchtturmprojekt der deutschen Digitalstrategie, beschreibt die technischen Anforderungen einzelner Bausteine so offen, dass diese Spezifikationen von unterschiedlichen Softwareprovidern erfüllt werden können. Die Anforderungen selbst werden auf Basis von Anwendungsfällen und konkreten Nutzendenreisen erstellt. Über diese Grundlage kann die Generalisierbarkeit der Inhalte der Bausteine gewährleistet werden.

Für uns ist unklar, ob jeder Prozess und jedes Fachverfahren später ausschließlich mit den Funktionsbausteinen abbildbar sein soll, oder welche Rolle diese bei der Erstellung digitaler Dienste spielen sollen. Soll über die Aneinanderreihung von Funktionsbausteinen später eine digitale Anwendung entstehen können? Wenn dies der Fall sein soll, könnten neben den technischen Anforderungen noch die Ebenen der Workflows und Capabilities hinzugefügt werden, um weitere Abstraktionslevel über die Funktionsbausteine zu bedienen.

Farina Owusu und Nico Lück (GovStack Initiative)

E.H - editiert am 27.01.2024

Antwort von Bundesamt für Migration und Flüchtlinge (BAMF):

Die in Leitfrage_08_Zusatzmaterial.pdf genannten Bezeichnungen der Funktionsbausteine bergen viel Interpretationsspielraum, da sie keine Detailbeschreibung enthalten. Dies erschwert eine klare Aussage, ob noch zusätzliche Funktionsbausteine benötigt werden. Positiv anzumerken ist die Benennung der Identifizierung passender Verwaltungsleistungen & Vorab-Klärung von Fragen. Hier wurde das Feedback aus der Leitfrage 1 erkennbar. Ansonsten ist aus unserer Sicht eine Trennung zwischen den Punkten bis "Abruf von Daten und Nachweisen" und ab "Pflege von lokalen Parametern" erforderlich. Während es bei ersteren um klare Funktionalitäten geht, ist bei letzteren die Frage der technischen Struktur der Lösung umfassender zu betrachten. Von den im Dokument genannten "Funktionsbausteinen" halten wir mindestens in Teilen insbesondere "Kommunikation und Kollaboration unter Entwicklern", "Entwicklung ohne umfangreiche (Maßstab?) Programmierkenntnisse" und "Betrieb von IT-Anwendungen/-Systemen" für hinterfragenswert, dies sind typisch non-funktionale Themenblöcke.

Für die Funktionalitäten schlagen wir daher vor, ein Capability Mapping nach EAM TOGAF durchzuführen. Dieses Verfahren ermöglicht eine klarere Differenzierung der Funktionsbausteine, die Identifizierung fehlender Komponenten und die Eliminierung von Überschneidungen.

Vorteile eines Capability Mapping:

Klarere Differenzierung der Funktionsbausteine

Identifizierung fehlender Komponenten

Eliminierung von Überschneidungen

Verbesserung der Übersichtlichkeit und Transparenz des IT-Konzepts

Folgende "Capabilities" konnten wir nicht eindeutig zuordnen bzw. diese sind nicht explizit genannt und sollten den Funktionskomponenten zugeordnet werden:

Ablage bzw. Verwaltung der Anträge und Bescheide → zentral und dezentral

Veraktung und Aussonderung abgeschlossener Vorgänge

Verfolgen des Bearbeitungsstatus inkl. aktive Push-Benachrichtigung über Kommunikations- bzw. Benachrichtigungskomponente

Interaktive Kommunikation über verschiedene Kommunikationskanäle, definiert durch die Nutzenden und nicht durch Absender-Komponente (Telegram, BundesMessanger, SMS, WhatsApp, eMail, DIDComm, usw.), (eventuell Zuordnung zu Baustein Kommunikation - Bitte verifizieren, ob dieser Aspekt auch vom Baustein umfasst ist!) Sicherheit: End2End Content-Verschlüsselung (nicht nur Protokollverschlüsselung)

Audit- und Reportingfunktionen zur Nachvollziehbarkeit, wer, was wann gemacht hat (signiert und manipulationssicher)

Funktionsprinzip OnceOnly mit Registeranbindung bzw. Nutzung der dezentral verwalteten Credential-Abfrage (EUDI Wallet) zur Widerverwendung der getätigten Eingaben (eventuell Zuordnung zu Baustein Authentizitätsprüfung von Daten/Dokumenten - Bitte verifizieren, ob dieser Aspekt auch vom Baustein umfasst ist!)

Bereitstellung von Bescheiden in unterschiedlichen Medien-Formaten (JSON, XML, PDF, SD-JWT, mDoc, VerifiableCredential, usw.). (eventuell Zuordnung zu Baustein Verkünden von Bescheiden oder Abruf von Daten und Nachweisen - Bitte verifizieren, ob dieser Aspekt auch vom Baustein umfasst ist!) API-Zugriff für die medienbruchfreie Kommunikation mit strukturierten Daten (nicht nur PDF) zur Umsetzung von End2End-Prozessketten

Signatur/Siegel laut eIDAS (QES / QESiegel)

Schlüsselverwaltung → es werden nicht nur Schlüssel für QES laut eIDAS benötigt, sondern zusätzliche Schlüssel zur End2End-Content-Verschlüsselung, zum Sicherstellen der Nachrichten-Authentizität bzw. Integrität

Souveränes und deszentrales Hosting neuer OZG-Dienste (freie Wahl des Anbieters bzw. eigenes Hosting der OZG-Dienste)

Zertifizierung- und Konformitätsprüfung von angebotenen OZG-Diensten

Management des Zugangs (Vertretung, Firmen-Repräsentanten) usw.

Eine erste Gap-Analyse führt zu den fehlenden Funktionsbausteinen bzw. die Funktionen lassen sich in der bestehenden Funktionsübersicht nicht verlustfrei eingliedern:

Verwaltung von Anträgen und Bescheide

Fachliche Audit-Funktion - Nachvollziehbarkeit

Fristenüberwachung mit Integration in den Funktionsbaustein Kommunikation bzw. Benachrichtigungskomponente Signatur- und Validierungsfunktion

Verschlüsselung inkl. Schlüsselmanagement

Verwaltung von Vertreterfunktionen bzw. Funktionen zur Verwaltung der Zugriffsberechtigung

Zertifizierung- und Konformitätsfunktionen inkl. Validierungsfunktion der OZG-Services usw.

Für die weiteren Punkte halten wir die Strukturierung als "Ökosystem" für entscheidend. Dabei sollte in Anbetracht auf die föderale Struktur der Leistungserbringung mit einer möglichst geringen Anzahl an Komponenten gearbeitet werden, die nur zentral bereitgestellt werden können.

Einmal/Zentral bereitzustellende Komponenten: - Kollaborationsplattform zur gemeinsamen Entwicklung und Pflege von Komponenten - "App-Store" zu Bereitstellung fertiger Komponenten ggf. auch durch Marktteilnehmende

Komponenten, die dezentral betrieben, aber innerhalb eines zentralen Frameworks bereitgestellt werden können: - Identity-Management für Externe (NKB) - Informationen zu Leistungen (FIM-Portal) - Beantragung von Leistungen (Bundesportal) - Darstellung des Bearbeitungsstandes von Leistungen - Kommunikation der Antragsstellenden - Bezahlkomponenten der Antragsstellenden

Komponenten, die rein dezentral betrieben werden können und in einem "Ökosystem" (Kollaborationsplattform/App-Store) und gemeinsame Standards/Schnittstellen verfügen müssen: - Workflow zur Bearbeitung von Anträgen - Komponenten für einzelne Bearbeitungsschritte - Komponenten für die Validierung/Once-Only - Identity-Management für Interne - Ermittlung des Bearbeitungsstandes von Leistungen - Kommunikation der Behörde - Ablage und Dokumentation des Verwaltungshandelns - Aktenhaltung und Aussonderung

J.P - editiert am 09.01.2024

Antworten Team PwC (bezogen auf die erste Version der Funktionsbausteine):

• Eine Beurteilung dieser Funktionsbausteine auf Basis deren Bezeichnung ohne nähere Erläuterung ist generell schwierig. Bsp. kann ein Funktionsbaustein „Kommunikation“ sehr unterschiedliche Aspekte beschreiben (Kommunikation zwischen Behörde und Bürger; Kommunikation zwischen Behörde A und Behörde B; usw.). Weiterhin wäre eine Kategorisierung sinnvoll, da bspw. Funktionsbausteine, wie „Kollaboration und Kommunikation unter Entwicklern“, nicht Teil eines Verwaltungsverfahrens sind.

• Bezüglich der Funktionsbausteine sollte sich u. a. an dem analogen Ablauf eines Verwaltungsverfahrens bzw. an den Verwaltungsverfahrensgesetzten orientiert werden.

• Bzgl. „Zuschnitt und Bezeichnung“: Die Formulierung „Antragstellung“ ist aus der praktischen Umsetzungserfahrung heraus zumindest unpräzise, da es neben Anträgen im Kontext des OZG auch alternative Prozessauslöser gibt, wie etwa Anzeigen, Mitteilungen, Nachweise usw. Unser Vorschlag ist, dass dieser Pluralität durch eine entsprechende Nachschärfung der Formulierung (z.B. generisch „Input“ oder „Prozessauslöser“) Rechnung getragen wird.

• Bzgl. „Zuschnitt und Bezeichnung“: Die Formulierung „Verkündung von Bescheiden“ ist aus der praktischen Umsetzungserfahrung heraus zumindest unpräzise, da es neben Bescheiden im Kontext des OZG auch alternative Prozessergebnisse gibt, wie etwa Ausweise (z.B. Behindertenausweis), Mitteilungen, Nachweise usw. Unser Vorschlag ist, dass dieser Pluralität durch eine entsprechende Nachschärfung der Formulierung (z.B. generisch „Outcome“ oder „Prozessergebnis“) Rechnung getragen wird.

• Bzgl. „weitere Funktionsbausteine“: Es fehlt eingangs eine entsprechende Normenanalyse, um den rechtlichen Rahmen einer Verwaltungsleistung entsprechend erfassen zu können.

AS - original vom 09.01.2024

Die “Funktionsbausteine” in der aktualisierten Darstellung bilden die Anforderungen für die Antragstellung durch Bürger:innnen und Organisationen bereits gut ab, wenngleich die gewählte Abstraktionsebene teilweise unklar ist (einige bilden Prozessphasen ab, andere funktionale Bausteine oder Lösungsoptionen) und die verwendeten Begriffe viel Interpretationsspielraum bieten.

Aus unserer Sicht fehlen allerdings Bausteine zur Umsetzung der Antragsbearbeitung auf Behördenseite. Angebote, die Kommunen und Ländern erlauben, ihre Leistungen effizient durch Nachnutzung bestehender oder zentral entwickelter Lösungen zu digitalisieren finden in der Darstellung bisher noch keine Beachtung. Als Beispiel sei hier ein Projekt wie “Modul-F” als Lösungsangebot genannt.

Das Zielbild könnte zudem einen Baustein zur Kollaboration an Dokumenten beinhalten, da sich komplexe Leistungen nicht immer auf ein „einfaches“ Antragsformular reduzieren lassen.

Der Baustein “Abruf von Daten und Nachweisen” findet nicht allein auf der Verwaltungsebene statt, sondern wandert mit der Registermodernisierung, SDG und ähnlichen Initiativen immer weiter in die Sphäre der Antragstellenden. Dies sollte auch grafisch deutlich werden.

Im Bereich “Entwicklung und Betrieb” sind die Bausteine “Testen und Bereitstellung ...”, “Beschaffung und Bereitstellung ...” und “Betrieb von Systemen” nicht klar voneinander abgegrenzt. Der Punkt “Beschaffung und Bereitstellung...” kann entfallen oder er muss klarer definiert werden.

“Entwicklung ohne Programmierkenntnisse” ist kein Funktionsbaustein, sondern eine von mehreren Lösungsoption und sollte entfallen.

C.R - editiert am 09.01.2024

Aus Sicht von BearingPoint möchten wir Folgendes anmerken:

(Eine) Grundlage für Funktionsbausteine sind die identifizierten Nutzendenreisen der jeweiligen (relevanten) Nutzendengruppen. Zusätzlich sind Nutzendenreisen-übergreifende Funktionsbausteine zu identifizieren (z.B. "Basisbausteine" oder Basisprozesse wie Entwicklung, Test, Deployment, Betrieb, Update etc.). Beispielhaft für eine Nutzendenreise von Bürgern und Unternehmen zur Kommunikation mit der Verwaltung könnte eine Übersicht wie folgt aussehen:

Wir unterstützen die Vorgehensweise Funktionsbausteine mittels eines geeigneten Vorgehens (z.B. TOGAF) aus den Nutzendenreisen abzuleiten. Dazu gehört es auch entsprechende Basis- und Querschnittsdienste zu identifizieren. Auch unterstützen wir die von anderen Teilnehmern geäußerte Sicht, dass die Funktionsbausteine zunächst rein fachlich definiert werden. Eine Betrachtung von technologischen Aspekten ist dann (erst) bei der jeweiligen (konzeptionellen) Umsetzungsbetrachtung relevant, wobei bis zu einer Technologiebetrachtung noch entsprechende Zwischenstufen zu betrachten sind. Je nach gewählter (Enterprise-)Architektur-Methodik wären dies am Beispiel von TOGAF:

Geschäftsfunktion (= Funktionsbaustein) genutzt für Geschäftsprozess (verwendet von Nutzenden/Rolle)

--(realisiert von)--> Geschäfts-Service

--(unterstützt von)--> Applikations-Service

--(unterstützt von)--> Technologie-Service

Die von den anderen Teilnehmern genannten, weiter möglichen "Funktionsbausteine" sind teilweise auf unterschiedlichen Architekturebenen verortet. Ein "Dokumentenspeicher" ist bspw. (je nach konkreter Auslegung) eher ein Geschäftsservice oder sogar bereits ein Applikationsservice. Eine dazu passendende Geschäftsfunktion (und somit fachlicher Funktionsbaustein) könnte z.B. sein: "Ablage und Abruf von Dokumenten".

Ohne eine einheitliche Definition im Sinne eines Content-/Enterprise-Metamodells (z.B. basierend auf TOGAF, siehe Beispiel oben mit Geschäftsfunktion -> Geschäftsservice etc.) reden wir von unterschiedlichen Dingen als Funktionsbausteine.

In diesem Sinne würde wir auch eine Umbenennung im Dokument "Leitfrage_08_Zusatzmaterial_Update_13.12.pdf" anregen: Anstatt "Basisdienste" sollte es dort besser "Basisfunktionen" heißen. Aktuell gibt es so eine recht willkürliche Mischung von "Funktion" und "Dienst".

A.S - editiert am 11.01.2024

Aus Sicht der DigitalService GmbH des Bundes:

Fehlende Elemente: - Bereitstellung strukturierter, offener Daten, möglicherweise auch im Kontext der Architektur-Leitlinien oder als Mini-Funktionsbaustein und nicht als extra Funktionsbaustein (Stichwort: Data Mesh statt Data Lake). - Moderierter Austausch zwischen Entwicklern und Interessenten. - Weitere Elemente, die eher auf der Behördenseite zu verordnen sind, jedoch ein erweiterte E2E-Perspektive Sinn machen könnte.

Inhaltliche Aspekte: Mehrere Punkte sind sinnvoll, aber die Details ihrer Umsetzung sind entscheidend. Anhand der Überschriften, ohne Bezeichnungen, lässt sich das nicht beurteilen. Es ist auch unklar, auf welcher Ebene diese festgelegt werden sollten (Zuschnitt, Bezeichnung, Prinzipien, oder durch Marktmechanismen). Dazu gehören u.a.: - Datensparsames Nutzertracking und Feedback, nutzbar für Entwicklungsteams, das auch EU-Vorschriften erfüllt. - Eine Integrationsplattform mit Dokumentation für Entwickler, wobei im Betrieb Self-Service berücksichtigt werden sollte. - Cloud-Infrastruktur für den Betrieb, Identitätsfeststellung und Authentifizierung (wo vollständiger Identitätsnachweis nicht erforderlich ist). - Bei Siegeln und Signaturen die Berücksichtigung der Rückrufbarkeit (Recht auf Vergessen, Fehlerkorrekturen etc.). - Offene Zusammenarbeit und Kommunikation unter Entwicklern. - Bei antragsbezogene Folgekommunikation: ist es nur der (minimale) bidirektionale Austausch oder sind darin auch Benachrichtigungen via Email, SMS usw. enthalten, die einen solchen Dienst wirklich (komfortabel) nutzbar machen und mit für dessen Durchsetzung sorgen? - usw. etc.

Klarheit der Darstellung: Wie bereits erwähnt, ist die Darstellung noch nicht vollständig klar. Andere Arten des Capability Mappings und Visualisierung von Architekturen könnten dazu hilfreich sein.

Zur Inspiration des Abstraktionslevel sowie zur Kommunikation an weniger technisch versierte Personen, anbei noch eine Visualisierung des DigitalService (Illustration I).

Illustration I: Justiz- oder Verwaltungsservices, Basiskomponenten und Basisdienste, Dateiverzeichnisse, Cloud-Infrastrukturen und Verordnungen (Policy). Quelle: https://digitalservice.bund.de/blog/sieben-huerden-und-unzaehlige-chancen-bei-basiskomponenten-in-deutschland

T.K - original vom 16.01.2024

Sammlung CDO-MID Sachsen-Anhalt und Vertreter von Kommunen des Landes:

Bei der Identitätsfeststellung wird aktuell auch eine hochgeladene Ausweiskopie des Antragsstellenden akzeptiert.

Mir fehlt das Post-Payment - vielleicht ist damit auch die bi-direktionale Zahlung gemeint?

Bei Kommunikation fehlt mir das Wort bi-direktional, für Nachfragen, falsche Dokumentzustellungen oder die Bereitstellung von ergänzenden Unterlagen, soweit möglich sollten auch Widersprüche möglich sein.

Es werden nicht nur Bescheide verkündet, es gibt auch Bescheinigungen oder andere Dokumente, die nicht den Status eines Bescheides haben (z. B. bei der Belehrung nach InfektionsschutzG).

Regelbasierter Anstoß von Verwaltungsleistungen fehlt mir die Automatisierte Bescheiderstellung/Bescheinigungserstellung (z. B. Meldebescheinigung, Bescheinigung der Belehrung nach InfektionsschutzG).

Automatisierte Registerabrufe ist damit der Abruf von Daten und Nachweisen gemeint? Unter diesen Punkt Daten und Nachweise sehe ich auch die Beteiligung anderer Behörden (falls nicht unter einem anderen Punkt subsumiert).

Datentransport ist sehr allgemein formuliert - wohin - Fachverfahren/DMS/Antragsraum/Databox,...) oder mit welchem Transportmittel?

Welche Pflege von lokalen Parametern ist gemeint - im BUS die Dienstleistungsbeschreibung oder direkt für den EfA?

Mir fehlt der Part der IT-Sicherheit (insbesondere Virenprüfung, Datenschutzüberlegung), Feedbacktool, Datenschutzcockpit (bei Registerabrufen), Speicherung der Antragsdaten (z. B. auf dem Formularserver für einen gewissen Zeitraum).

Spielt die D115 in dem Zusammenhang eine Rolle?

-Ich finde Zustellung, Datentransport und Antragstellung ziemlich ähnlich. Ich denke, dass man zumindest Zustellung und Datentransport bündeln kann. - Bei Antragstellung gehört auch die Kollaboration mit rein (vgl. eBau, gemeinschaftliches Stellen der Anträge) - Gehören Nachforderungen zu "Daten und Nachweise"? - Ich vermisse Beteiligungsmöglichkeiten (vgl. eBau) - Ist die eAkte Teil der OZG-Rahmenarchitektur? Für eine ganzheitliche Digitalisierung muss sie zwingend mit aufgenommen werden.

D.S - original vom 17.01.2024

Es fehlt bei dem Zugang für die Verwaltung die Bescheiderstellung bzw. Leistungserbringung als Komponente. BürgerInnen erwarten zu Recht die digitale Leistungserbringung von der Verwaltung und diese ist auch nötig, auch um einen volldigitalen Prozess zu erstellen. Dazu gehört dann auch der Rückkanal (digitales Postfach) von der Verwaltung zum Leistungsempfänger/in.

O.F - editiert am 17.01.2024

Rückmeldung der Bundesdruckerei: - Wir möchten den Kommentar von Detlef Hühnlein bekräftigen, der Punkt Identifizierung muss explizit auch den Aspekt Authentisierung umfassen. Zudem fehlt als Komponente die Archivierung mit Langzeitbeweiserhaltung. - Der Punkt "Kommunikation" muss auch die digitale Zustellung an Nutzer beinhalten. Auch das ist ein essentieller Basisdienst in der Verwaltungsdigitalisierung. - Bereitstellung von validierten Daten sollte als ein Basisdienst aufgenommen werden oder zumindest in „Abruf von Daten“ explizit integriert werden. Die Einreichung von Daten und Nachweisen durch den Bürger im Rahmen eines Verwaltungsverfahrens unterscheidet sich von einem Registerabruf durch die Behörde und sollte daher explizit statuiert werden. - Die Validierung elektronischer/digitaler Siegel, Signaturen und Nachweise fehlt als Komponente. „Siegeln und Signieren“ sollte daher neben der Erstellung auch die Validierung von Siegeln und Signaturen explizit enthalten. - Der Punkt "Betrieb von IT-Anwendungen/-Systemen" sollte auch enthalten Konzepte und Vorlagen sicheren Betriebs“. Dies würde z.B. Architekturkonzepte und IT-Sicherheitskonzepte umfassen. - Zu den unter „Entwicklung und Betrieb“ benannten Punkte, könnte folgender Punkt berücksichtigt werden, um auch hier eine klare Ausrichtung an Funktionalitäten zu schärfen: Entwicklungsplattformen und Frameworks (zur Entwicklung interoperabler Komponenten)“, diese Funktionen dienen z.B. der Bereitstellung von SDKs zu weitereichenden Wiederverwertung und Anbindung von Diensten. Hier könnten z.B. auch Standard-Entwicklungsvorgehensweisen, wie Test-Prinzipien oder CI-/CR-/CD-Vorgehen, und Standard-Tools bereitgestellt werden. - Zudem empfehlen wir die Ergänzung des "Funktionsblocks" Marktplatz für (den Zugriff auf und die Verteilung von) Lösungen“. Darunter fällt z.B. das Angebot von Komponenten, die als SaaS bereitgestellt und dann eingebunden werden. Ziel dieses "Funktionsblocks" wäre die Auffindbarkeit und gleichzeitig die Wiederverwertbarkeit zu erleichtern und ggf. darüber eine Orchestrierung von z.B. SaaS-Diensten zu ermöglichen bzw. zu unterstützen. Ein weiterer Aspekt wäre die Nutzung des Marktplatzes für die Einrichtung einer Cloud-Umgebung für den vorgesehenen Betrieb einer Fachanwendung.

M.N.AKDB - editiert am 29.01.2024

Die 14 Funktionsbausteine sind einerseits so generisch gefasst, dass sich nach hiesiger Ansicht nicht abschließend beurteilen lässt, ob man damit die beabsichtigten Ableitungen aus einer Rahmenarchitektur treffen lassen. Trotz des generischen Ansatzes ist es überraschend, dass wesentliche Komponenten einer holistischen IT-Architektur für den öffentlichen Sektor fehlen. So fehlen Aussagen zur erforderlichen Zuständigkeitsfindung und -prüfung, die notwendige Berücksichtigung der IT-Sicherheit lässt sich ebenfalls aus den dargestellten Funktionsbausteinen nicht herauslesen. Die Bedeutung und Zielrichtung "Kollaboration und Kommunikation unter Entwicklern " ist unklar. Weiterhin fehlen nach unserer Einschätzung Aussagen zu Portfolio-Management, Gewährleistung Datenschutz, Beschaffung von IT-Dienstleistungen, Datenintegration, UX/UI, Nutzungsanalyse fehlt, IT-Controlling und Budgetierung, Distributions- und Nachnutzungsmodelle sowie Kollaboration mit dritten Diensten (bspw. Assistenzdiensten).

Nicht nachvollziehbar ist, dass das "Arbeitspferd" der digitalen Verwaltung, die Fachverfahren nicht als eigene Funktion berücksichtigt ist, sondern u.a. dekonstruiert einerseits in der Ausprägung "Entwicklung ohne umfangreiche Programmierkenntnisse = NoCode-Werkzeuge" und dem Testen von Software wiederfinden. Beide Praktiken sind notwendige/nützliche Disziplinen bei der Bereitstellung von IT-Komponenten, aber keine Funktionsbausteine, welche mit den übrigen syntaktisch kompatibel wären, weil sie nicht die Funktion der IT-Komponenten beschreiben, sondern deren Weg der Erstellung.

Unser Vorschlag an dieser Stelle wäre die Kernfunktion eines Fachverfahrens, fachspezifische Fallbearbeitung im Rahmen eines Workflows, zu ergänzen. Ebenso die Anbindung von diesen.

D.H - editiert am 29.01.2024

Lieber Herr Neidel (@oc000002448180), die "Fachverfahren" sollten in der Architektur natürlich in der Form von Fachdiensten ergänzt werden. Wichtig ist, dass die Fachverfahren als Microservices realisiert und über eine OpenAPI-Spezifikation beschrieben sind, so dass diese von den verschiedenen benutzerfreundlichen Frontends (Webapplikationen und Smartphone Apps) entsprechend integriert werden können.

S.G - original vom 18.01.2024

Aus Sicht der VISION Consulting GmbH ist die Stimmigkeit und Vollständigkeit nicht bewertbar, da durchaus nicht alle Basisdienste umfassend aufgeführt sind. Es fehlen darüber hinaus weitere „Untergruppen“ oder detaillierte Beschreibungen zu einzelnen Begriffen.

K.G - editiert am 29.01.2024

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-DIienstleister:

Zuschnitt und Bezeichnung werden vereinfacht dargestellt und sind generisch verfasst, so dass sich nicht abschließend beurteilen lässt, ob sich damit die beab-sichtigten Ableitungen aus einer Rahmenarchitektur treffen lässt. Es fehlt an der nötigen Detailtiefe. So fehlen wesentliche Komponenten einer holistischen IT-Architektur für den öffentlichen Sektor. Es fehlen Aussagen zur erforderlichen Zu-ständigkeitsfindung und -prüfung, die notwendige Berücksichtigung der IT-Sicherheit lässt sich ebenfalls aus den dargestellten Funktionsbausteinen nicht herauslesen. Die Bedeutung und Zielrichtung "Kollaboration und Kommunikation unter Entwicklern " ist unklar. Weiterhin fehlen nach unserer Einschätzung Aussa-gen zu Portfolio-Management, Gewährleistung Datenschutz, Beschaffung von IT-Dienstleistungen, Datenintegration, UX/UI, Nutzungsanalyse fehlt, IT-Controlling und Budgetierung, Distributions- und Nachnutzungsmodelle sowie Kollaboration mit dritten Diensten (bspw. Assistenzdiensten). Darüber hinaus die Fragen: Welche weiteren Bausteine umfassen z.B. Anliegensklärung? Gibt es hier nicht Über-schneidungen zu Basisdiensten (Bürgerportale, Zuständigkeitsfindung, 115), wel-che Basisdienste fallen für die Behörden an (Datentransport bzw. Zustellung an Fachverfahren, eAkte)? Eine klarere und detailliertere Darstellung wäre begrü-ßenswert.

Nicht nachvollziehbar ist, dass das "Arbeitspferd" der digitalen Verwaltung, die Fachverfahren nicht als eigene Funktion berücksichtigt ist, sondern u.a. dekonstru-iert einerseits in der Ausprägung "Entwicklung ohne umfangreiche Programmier-kenntnisse = NoCode-Werkzeuge" und dem Testen von Software wiederfinden. Beide Praktiken sind notwendige/nützliche Disziplinen bei der Bereitstellung von IT-Komponenten, aber keine Funktionsbausteine, welche mit den übrigen syntak-tisch kompatibel wären, weil sie nicht die Funktion der IT-Komponenten beschrei-ben, sondern deren Weg der Erstellung. Unser Vorschlag an dieser Stelle wäre die Kernfunktion eines Fachverfahrens, fachspezifische Fallbearbeitung im Rahmen eines Workflows, zu ergänzen. Ebenso die Anbindung von diesen.

Außerdem erscheint der Zuschnitt der Funktionsbausteine - Kollaboration und Kommunikation mit Entwicklern - Test und Bereitstellung von Eigenentwicklungen - Entwicklung ohne umfangreiche Programmierkenntnisse - Zugang zu digitalen Diensten und Fachanwendungen nicht schlüssig und ausgewogen.

Aus Sicht eines kommunalen IT-Dienstleisters ohne nennenswerte Softwareent-wicklung ist der Funktionsbaustein „Zugang zu digitalen Diensten und Fachverfah-ren“ sehr relevant. Digitale Dienste sind die Nutzung von IT-Verfahren mit Fach-software aus der (Privat-)Cloud anderer IT-Dienstleister. Der Zugriff auf Fachver-fahren muss auch möglich sein, damit der Betrieb im eigenen Rechenzentrum er-folgen kann. Für diesen Betrieb stehen dann die Funktionsbausteine "Betrieb von IT-Anwendungen/-Systemen" und "Betriebsunterstützung" zur Verfügung.

Der Funktionsbaustein „Entwicklung ohne umfangreiche Programmierkenntnisse“ meint die Erstellung von Software mittels Low-Code/No-Code Technologien. Han-delt es sich bei der so entwickelten Software dann auch um Eigenentwicklungen im Sinne des Funktionsmoduls „Testen und Bereitstellen von Eigenentwicklun-gen“? Wenn ja, dann müsste es einen eigenen Baustein „Entwicklung von Eigen-entwicklungen“ geben. Denn es ist nach allgemeiner Auffassung notwendig, auch Software, die „ohne umfangreiche Programmierkenntnisse“ entwickelt wurde, nur getestet zur Verfügung zu stellen. Aus meiner Sicht sollte Softwareentwicklung ein Funktionsbaustein sein. Dabei ist es unerheblich, ob die Software durch Low-Code/No-Code Technologien oder durch Programmierung im eigentlichen Sinne entwickelt wurde. Ein solcher Funktionsbaustein "Softwareentwicklung" muss zwingend auch den Softwaretest und Freigabeprozesse beinhalten.

Der Funktionsbaustein „Kollaboration und Kommunikation unter Entwicklern“ ist m.E. nicht auf die Entwickler zu beschränken. Auch beim Betrieb von IT-Anwendungen/-systemen treten Fragen auf, so dass Kollaboration und Kommu-nikation auch Betriebsfragen umfassen sollte. Insofern schlage ich vor, den Funkti-onsbaustein "Kollaboration und Kommunikation" neben den Entwicklern auch auf den Betrieb auszudehnen: "Kollaboration und Kommunikation für Entwicklung und Betrieb von IT-Anwendungen/-systemen".

Darüber hinaus sind folgende Funktionsbausteine auf Grund ihrer Bezeichnung nicht eindeutig in ihrer Funktionalität: - „Identitätsfeststellung“ Eine Identitätsfeststellung muss immer in beide Richtungen erfolgen. Das gilt bei einer Behörde-Behörde Kommunikation ebenso, wie bei einer Kom-munikation Bürger-Behörde. Zumeist wird aus Sicht der Behörde nur daran gedacht, die Identität des Bürgers eindeutig festzustellen. Der Bürger benö-tigt genauso eine Sicherheit bzgl. der Identität des Betreibers eines Inter-netangebots. Ein Vorschlag zur Realisierung kann liegt der GovDigital vor und kann dort erfragt werden.

„Kommunikation“ In Rahmen des OZG werden eine Reihe unterschiedlicher Arten von Kom-munikation benötigt. So gibt es den Nachrichtentransport zwischen Fach-verfahren oder auch von Antragsverfahren zu den Fachverfahren. Eine Kommunikation kann aber auch ein Chat sein oder die Zustellung eines Be-scheids an einen Bürger. Daher ist der Begriff „Kommunikation“ zu mehr-deutig.

„Verkündung von Bescheiden“ Ist hiermit die Zustellung von Bescheiden und damit die Adressierung des Postfachs des Bürgers gemeint?

„Zustellung an Vorgangs- und Sachbearbeitung (Dienststellennummer)“ Im Rahmen der XÖV Nachrichtentransporte wird jede Behörde über ihre fachliche Kennung adressiert, z. B. „ags:03403000“ für die Meldebehörde Stadt Oldenburg. Es sollte nur einen eindeutigen Identifikator für Behörden geben und der sollte überall gleich benannt werden und auch so im Identi-tätsverzeichnis, wie z. B. dem DVDV, hinterlegt werden.

„Datentransport“ Bei einem Datentransport wird ausschließlich einer Aneinanderreihung von Daten übermittelt. Bei einem Nachrichtentransport definiert die Nachricht mit den eingebetteten Daten die Semantik der Daten durch ein vorgegebe-nes Interpretationsschema. So unterscheiden sich („Marc“, „Behrens“) und (Vorname->“Marc“, Nachname->“Behrens“) in der Aussagekraft. Ein XÖV Standard wie z. B. XMeld geht hier viel weiter und definiert sehr spezifische Nachrichten. Welche Art von Transport ist hier gemeint?

„Abruf von Daten und Nachweisen“ Hier ist die Bedeutung klar, aber zugleich verwirrend. Wer die Definition von „Nachweis“ kennt, der weiß, dass ein Nachweis auch aus Daten bestehen kann. Dann ist „Daten und Nachweise“ ein Pleonasmus. Da die Definition von Nachweis nun einmal so ist wie sie ist, sollte man diese den Menschen nä-herbringen und es hier bei „Abruf von Nachweisen“ belassen.

„Pflege von lokalen Parametern“ Das kann alles oder nichts bedeuten. Handelt es sich um fachliche Parame-ter? Allgemeine Parameter bzgl. Datenschutzbestimmung, Wappen etc.? Oder um die technischen Adressparameter? Hier lohnt es sich die möglichen Parameterarten zu klassifizieren und eindeutig zu benennen.

• Sehen Sie weitere Funktionsbausteine, welche noch nicht abgebildet sind? Bitte beschreiben Sie die Relevanz dieser anhand von Beispielen.

Folgende Bausteine sind nicht benannt: - Identitätsverzeichnis Behörden In einem Nachrichtentransport werden die Behörden durch ihre Identität authentifiziert. Die Identität einer Behörde besteht aus den Informationen Behördenkategorie, fachliche Kennung, öffentlicher Verschlüsselungs-schlüssel und öffentlicher Signaturschlüssel. Diese Informationen werden für die Realisierung der fachlichen Funktionsbausteine benötigt. Wichtig ist, dass alle Bausteine, fachliche wie technische, auf einem gemeinsamen Da-tenmodell arbeiten. Ein Beispiel befindet sich in der obigen Diskussion zum Begriff Dienststellennummer. Das DVDV beinhaltet u. a. ein Identitätsver-zeichnis für Behörden.

Adressverzeichnis Behörden Für die Kommunikation mit einer Behörde wird ein Adressverzeichnis benö-tigt. Für eine fachliche Kennung und einen Service werden die technischen Parameter zur Adressierung geliefert. Für die OSCI Kommunikationen ent-hält z. B. das DVDV vieler dieser Adressen.

Metadatenverzeichnis Das Metadatenverzeichnis soll alle Vorgaben in maschinenlesbarer Form enthalten. Hier folgt eine beispielhafte Auflistung einiger der benötigten Informationen: o Liste der Nachrichtenformate inkl. ihrer Versionen, Services und Nachrichten je Service. o Liste der Behördenkategorien, genutzte Nachrichtenformate, Angabe der Gültigkeitszeiträume der jeweiligen Versionen, Liste der jeweils daraus verwendeten Services und Nachrichten und von welcher Be-hördenkategorie diese an welche geschickt werden dürfen. o Angabe der genutzten Infrastrukturkomponenten (Identitätsver-zeichnis, Adressverzeichnis) je Kommunikationsszenario (XÖV, SAFE, PEPPOL) der Behördenkategorien. o …

Sachlicher Zuständigkeitsfinder Ein solcher Zuständigkeitsfinder liefert zu einem Stichwort die korrekte amtliche Bezeichnung. Zusätzlich liefert er die zuständige Behördenkatego-rie wie z. B. „Meldebehörde“.

Örtlicher Zuständigkeitsfinder Ein solcher Zuständigkeitsfinder liefert zu einer Behördenkategorie und ei-ner Koordinate (Adresse, GPS, …) die fachliche Kennung der örtlich zuständi-gen Behörde.

Identitätsverzeichnis Bürger (analog Unternehmen) Das Verzeichnis liefert vertrauenswürdige Identitätsdaten von Bürgern. (An-ders als bei den Behörden ist die Hinterlegung kryptografischer Schlüssel nicht vorgesehen. Das wird dann sinnvoll, sobald er Bürger Zugriff auf ein si-cheres Crypto-Token erhält, was mit einer Erweiterung des neuen Perso-nalausweises leicht möglich wäre. Dann könnte eine Zustellung von Be-scheiden genauso sicher erfolgen wie ein Nachrichtentransport zwischen Behörden.)

Adressverzeichnis Bürger (analog Unternehmen) Das Verzeichnis liefert zum Beispiel für den Service „Postfach“ die techni-schen Parameter für die Adressierung des Postfachs des Bürgers.

Da das Schaubild nicht die Detailschärfe bietet, ist es schwierig, fehlende Funkti-onsbausteine zu benennen, da sie unter Umständen bereits mitgedacht sind. - Ebene 1: Nutzende – Bürger*innen und Unternehmen / Behörden - Ebene 2: Portale u. Verlinkungen – Kommunale Bürgerportale / Kommunale Onlineangebot - Ebene 3: Onlinedienste, OZG Leistungen – Zentrale u. kommunale Dienste / .NET u. AFM-Dienste - Ebene 4: Basisdienste u. Infrastrukturen – eID, Payment, Chatbot, Bürger-portalservice, Statusanzeige / Behörden-AD, Terminbuchung / Nutzerpost-fach, OZG-Nutzerkonto, eAkte, FV, Geodaten u.w.

D.H - original vom 29.01.2024

Liebe Frau Giebel (@OC000025092724), die von Ihnen angesprochenen Verzeichnisse können in einem geeigneten "Föderierten Katalog" zusammengefasst werden. Ein "Identitätsverzeichnis Bürger", das vermutlich zusätzlich zu den ohnehin schon vielfach existierenden Registern mit größtenteils redundanten Informationen geschaffen werden müsste, verbietet sich aus meiner Sicht jedoch schon aus Gründen der Datenminimierung gemäß Art. 5 (1) lit. c) DSGVO. Statt dem "Adressverzeichnis Bürger" sollte die Adresse des Service-Postfachs (z.B. https://id.bund.de/... oder private Nextcloud-Instanz) in einem bestehenden Register (und zusätzlich neben der E-Mail-Adresse ggf. im Personalausweis) gespeichert werden.

G.B - editiert am 29.01.2024

Bein Entwicklung und Betrieb scheinen Auditierbarkeit und Sicherheit nicht erkennbar berücksichtigt zu werden, in welchem Rahmen die in den Leitplanken vogesehene Anforderung Security bei Desing umgesetzt wird scheint nicht direkt ersichtlich. Prinzipien wie minimale Zugangs- und Zugriffsrechte nach technischer Maßgabe, um auch die Bürger:innen gegen unberechtigte Zugriffe zu schützen, sind auch nach aktueller Gesetzelage nach unserem Verständnis - bspw. im RegModG - nicht vorgesehen.

Die Basisdienste umfassen Zugriffe auf Register. Der Zugang für die Bürger:innen geht davon aus, dass ein "Anliegen" vorliegt. Ein Bürger:innen zentrierter Ansatz würde vom berechtigten Anspruch ausgehen. Eine entsprechender Ansatz wurde im Rahmen des Netzpolitische Abend 125 vorgestellt, siehe: https://digitalegesellschaft.de/2023/03/125-netzpolitischer-abend/ und https://bkastl.de/npa125

Das ganze ist offensichtlich nicht aus der Perspektive zu Ende gedacht und wirkt wie ein verwaltungsautoritäres Verständnis für digitale Daseinsvorsorge und steht in starken Wiederspruch zur alltäglichen self-service Erfahrung üblicher digitaler Dienste.

D.H - original vom 29.01.2024

Lieber Herr Bransky (@OC000019171702), ich stimme Ihnen zu, dass die wichtigen Themen Datenschutz und Datensicherheit bei der Umsetzung des OZG eine sehr wichtige Rolle einnehmen. Für das Thema Sicherheit könnte eine über alle Verwaltungsebenen hinweg zuständige Stelle für das kontinuierliche Monitoring der Sicherheit und Regelkonformität der verschiedenen Dienste vorgesehen werden.
Für das Thema Datenschutz und z.B. Transparenz sollte es ein umfassendes, bürgerzentriertes, vertrauenswürdiges "Datenschutzcockpit" geben, wie dies in (bislang leider nur zaghaften) Ansätzen geplant ist. Unglücklicher Weise weist der hierfür kürzlich von KoSIT entwickelte Standard XDatenschutzcockpit, um es mal sehr vorsichtig zu formulieren, hier die in der XÖV-Standardfamilie üblichen strukturellen Schwächen und Verbesserungspotenziale auf, so dass hier sehr dringend nachgebessert werden muss.

IT-Architekturrichtlinie

11. Umsetzung der föderalen IT-Architekturrichtlinien

Datum der Veröffentlichung: 18.12.2023
Anzahl eingegangener Antworten: 21
Issue # in GitLab: #149
Leitfrage 11 Umsetzung der föderalen IT-Architekturrichtlinien

Wie können die überarbeiteten IT-Architekturrichtlinien zukünftig konsequent umgesetzt werden?

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

D.K - original vom 20.12.2023

Die konsequente Umsetzung dieser Richtlinien ist von entscheidender Bedeutung, um eine effiziente und interoperable IT-Infrastruktur in föderalen Strukturen sicherzustellen. Im Folgenden präsentieren wir Ihnen einige Schlüsselansätze für eine erfolgreiche Umsetzung:

Ganzheitlicher Ansatz in Form von Prinzipien: Die Umsetzung der IT-Architekturrichtlinien erfordert einen ganzheitlichen Ansatz. Es ist wichtig, alle relevanten Ebenen der föderalen Strukturen einzubeziehen, um eine kohärente und einheitliche Implementierung zu gewährleisten. Dies schließt Bund, Länder und Kommunen gleichermaßen ein. Einbeziehung heißt aber hier nicht, jegliche Wünsche zu berücksichtigen und damit die IT-Vorgaben zu komplex oder zu uneindeutig zu gestalten. Durch einen Schwenk auf IT-Architekturprinzipien kann allgemeiner ein Rahmen gesetzt werden, der schneller konsensfähig ist.

Kommunikation und Schulung: Eine erfolgreiche Umsetzung erfordert eine klare Kommunikation über die neuen Richtlinien. Schulungsmaßnahmen auf allen Ebenen sind entscheidend, um sicherzustellen, dass alle Beteiligten ein Verständnis für die neuen Vorgaben entwickeln und in der Lage sind, sie umzusetzen.

Interdisziplinäre Zusammenarbeit: Föderale Strukturen sind oft vielschichtig und erfordern eine enge Zusammenarbeit verschiedener Disziplinen. IT-Experten, Behördenvertreter und andere relevante Stakeholder sollten aktiv zusammenarbeiten, um die Umsetzung der Architekturrichtlinien zu gewährleisten.

Standardisierung und Modularität: Die überarbeiteten Richtlinien sollten auf Standardisierung und Modularität setzen, um die Interoperabilität zwischen verschiedenen föderalen Einheiten zu erleichtern. Einheitliche Standards erleichtern nicht nur die Umsetzung, sondern fördern auch die langfristige Wartbarkeit und Erweiterbarkeit der IT-Systeme.

Technologische Innovation: Die Umsetzung sollte auch Raum für technologische Innovation bieten. Die fortlaufende Evaluation und Integration neuer Technologien kann die Effizienz steigern und die Anpassungsfähigkeit der föderalen IT-Landschaft verbessern.

Monitoring: Ein effektives Monitoring-System sollte implementiert werden, um die Umsetzung der Richtlinien zu überwachen. Regelmäßiges Feedback von Anwendern und Stakeholdern ermöglicht Anpassungen und Optimierungen im Laufe der Zeit.

Compliance-Überprüfungen: Wiederkehrende Compliance-Überprüfungen sind notwendig, um sicherzustellen, dass die IT-Systeme den festgelegten Architekturrichtlinien entsprechen. Dies unterstützt die Einhaltung der Standards über die Zeit hinweg. Die erfolgreiche Umsetzung der überarbeiteten föderalen IT-Architekturrichtlinien erfordert eine koordinierte und engagierte Anstrengung aller Beteiligten.

A.K - original vom 20.12.2023

S.a. Kommentar zu Leitfrage 10 "Einhaltung der föderalen IT-Architekturrichtlinien".

Die Umsetzung hat sehr viel mit der Einhaltung der Richtlinien zu tun, und umgekehrt. Letztlich ergibt sich die Einhaltung ganz wesentlich aus der konsequenten Umsetzung, die wiederum voraussetzt, dass eine Einhaltung überhaupt möglich, notwendig und attraktiv ist.

S.M - editiert am 05.01.2024

Bundesagentur für Arbeit: Als Bundesbehörde wird die BA hierzu keinen Kommentar abgeben, da keine Betroffenheit vorliegt.

A.S - original vom 05.01.2024

Liebe Frau Mahlein, ich wollte nachfragen, wie sie zu der Einschätzung kommen? Ist es für Ihre Bundesbehörde eventuell machbar wäre, durch gezielte Ausschreibungen und entsprechende Vertragsgestaltung mit IT-Dienstleistern die Einhaltung von IT-Architekturrichtlinien zu fördern? Auch wenn es sich um föderale IT-Architekturrichtlinien handelt, könnten darin doch sicherlich Aspekte enthalten sein, die die Qualität Ihrer IT-Projekte steigern, oder? Ich freue mich auf Ihre weitere Einschätzung zu diesem Punkt.

F.S - original vom 30.12.2023

Im Lichte der über Jahrzehnte entstandenen Heterogenität der IT-Architekturen in mehr als 11.000 Kommunen ist eine Umsetzung vielerorts nur realistisch, wenn "Plug an Play"-Angebote gemacht werden und auf Ebene der Länder mindestens Anschubfinanzierungen gegeben werden.

D.T.OZG.S - original vom 05.01.2024

Maßnahmen für die Einhaltung von Richtlinien beinhalten die Umsetzung. Aus Sicht der Deutschen Telekom sind die Maßnahmen zur konsequenten Einhaltung und Umsetzung der IT-Architekturrichtlinien in Leitfrage 10 beschrieben; daher wird hier auf die Antwort von Frage 10 verwiesen.

DIHK.I.K - original vom 05.01.2024

Die DIHK verweist auf ihre Antwort zu Frage 10.

D.U - original vom 06.01.2024

Aus Sicht der Infora GmbH/Materna SE stehen Frage 10 und 11 in starkem Bezug zueinander. Neben den zu Frage 10 genannten Aspekten ist für die konsequente Umsetzung der IT-Architekturrichtlinien die Inititiierung und Steuerung des IT-Architekturprozesses in den einzelnen Umsetzungsprojekten für IT-Lösungen relevant (“IT-Architektur-Governance”). Die Architektur-Governance soll insgesamt dazu beitragen, dass die Richtlinien nicht nur von Architekten, sondern auch von anderen relevanten Akteuren, insbesondere der Projektleitung, konsequent angenommen und in Projekten umgesetzt werden.

Wir empfehlen, hierzu ein IT-Architektur-Governance-Konzept zu erarbeiten, das u.a. folgende Aspekte berücksichtigt:

Verankerung der Lösungsarchitekturentwicklung auf Basis der Rahmenarchitektur im Projektvorgehen

Anlehnung / Harmonisierung von Lösungsarchitekturen mit IT-Strategie und Rahmenarchitektur

Rollen, Gremien und Verantwortlichkeiten für die Architekturentwicklung festlegen

Quality Gates / Prüfpunkte für Lösungsarchitekturen auf Basis der RA und weiteren Qualitätskriterien

Berücksichtigung der RA-Konformität bei der Bewertung von Lösungen (z.B. im Rahmen von Wertschöpfung, Folgekosten, Wirtschaftlichkeit)

- weitere Punkte sind auszuarbeiten

Zum Monitoring kann ein Reifegradmodell oder ein ähnliches Instrument sinnvoll sein, um die Umsetzung der Richtlinien messbar zu machen.

E.S - original vom 08.01.2024

Für den Bitkom e.V.

Bei den Pflichtaufgaben nach Weisung und den Auftragsangelegenheiten sollte im Sinne der Dresdner Forderungen geprüft werden, ob auf eine dezentrale Abwicklung verzichtet werden kann. Je nach Aufgabe ergeben sich zwei Optionen:

Option 1: Bund nimmt Aufgaben zur Entlastung der Kommunen wieder zurück und kümmert sich selbst um die Aufgabenerfüllung.

Option 2: Aufgabenerfüllung bleibt bei den Kommunen, der Bund stellt jedoch nach §4 OZG zentrale digitale Verfahren (z.B. als SaaS-Lösung über die Deutsche Verwaltungscloud) zur Verfügung.

Verbleiben die Aufgaben bei den Ländern und Kommunen, sollten möglichst verbindliche Vorgaben für die Nutzung von Architekturrichtlinien gemacht werden.

Zudem empfiehlt sich:

zentrale Anlaufstelle für Vorgaben, Fragen und Feedback einzurichten.

bestehende Bausteine und Basiskomponenten konsequenter nutzen (ggf. auch Softwarelösungen vorgeben).

Komplexität reduzieren und Attraktivität schaffen (unter anderem durch Nachnutzung).

Rechtzeitig die entsprechenden Adressaten bei Änderungen informieren und eine angemessene Frist zur Umsetzung einräumen.

nach Leistung, Verfügbarkeit und Qualität ausgerichtete Partnerschaftsmodelle mit der Wirtschaft einzugehen und in den Austausch zu treten.

S.L.B - original vom 08.01.2024

Aus Sicht der Bundessteuerberaterkammer könnte die Umsetzung von Beispielprojekten sowie die dazugehörige Dokumentation entscheidend dazu beitragen, die Vorhaben schneller und konsequenter umzusetzen. Die Bereitstellung als Open-Source-Software würde ebenso einen wichtigen Beitrag leisten, die Regelungen einfacher umzusetzen. Zudem wäre die Einstiegshürde deutlich geringer.

Zur Nachverfolgung von wichtigen Vorhaben, ist es wichtig, die Verantwortlichkeiten klar zu benennen. In einigen Vorhaben finden sich – auch in der IT-Architektur – Überschneidungen. Eindeutig definierte Aufgabenbereiche sind hilfreich, um doppelte Entwicklungen zu vermeiden und Missverständnisse schnell auszuräumen.

N.L - original vom 08.01.2024

Die vorgegebenen Richtlinien müssen sinnhaft und verständlich sein, damit sie umsetzbar sind. Darüber hinaus ist es notwendig, dass eindeutige Umsetzungswege aufgezeigt werden und nicht nur das Leitbild kommuniziert wird. Es bedarf einer gemeinsamen Vision, mit der sich alle Stakeholder identifizieren können. - Farina Owusu und Nico Lück (GovStack Initiative)

J.P - original vom 09.01.2024

Antworten Team PwC:

• Für eine konsequente Umsetzung der Richtlinien ist eine entsprechende rechtliche Verbindlichkeit und/oder inhaltliche Überzeugung zur freiwilligen Implementierung förderlich (vgl. Leitfrage 10).

• Zur Fortschrittskontrolle der Umsetzung kann ein entsprechendes Controlling dienen.

A.S - original vom 09.01.2024

Siehe Antwort zur Leitfrage 10

F.K - original vom 10.01.2024

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen:

Um dies mit den Betroffenen herauszufinden, könnte ein solcher Konsultationsprozess wie dieser hier aufgesetzt werden. Allerdings frühestens in einem Jahr, da dies wieder viel zeitliche Ressourcen von allen Beteiligten benötigt.

Checklisten und auch Reifegrad-Checklisten könnten zur Anwendung der Architekturrichtlinien erarbeitet werden.

D.S - original vom 17.01.2024

Hier verweisen wir auf unsere Antwort zu Leitfrage 10

M.N.AKDB - original vom 18.01.2024

Die Umsetzung der IT-Architekturrichtlinien ist maßgeblich von dem Vorleben und der effektiven Nutzung dieser durch die öffentliche Verwaltung selbst abhängig. Werden bspw. Standards nicht in öffentlichen Vergaben eingefordert, entfalten sie keine Relevanz. Werden einzelne Leitplanken aus nicht sachlichen Motiven bspw. überbetont, zerstören sie potenziell nutzbringende und bewährte Strukturen oder tangieren andere Architekturrichtlinien. Im Ergebnis hat es also die Verwaltung selbst in der Hand, wie wirksam die Architekturrichtlinien sein werden.

Ein wichtiger, praktischer Ansatzpunkt ist das Aufgreifen der Ergebnisse der OZG-Rahmenarchitektur u.a. in öffentlichen Vergaben. Dabei sollte künftiger weniger auf spezifische Eigenschaften von IT-Anwendungen abgestellt werden und die beabsichtigten Nutzen und Prozesse betont werden. Damit ergäben sich neue "Beinfreiheiten" und Provider-Konstellationen.

Auch könnte das Instrument einer Experimentierklausel zur gezielten Verprobung von Schwerpunkten und Intentionen Wirkung entfalten. Das BayDiG liefert hier eine entsprechende Blaupause.

S.G - original vom 18.01.2024

Aus Sicht der VISION Consulting GmbH sollten hier mindestens die folgenden Punkte berücksichtigt werden:

Dokumentation und zentrale Veröffentlichung

Kenntnis, Schulung und Sensibilisierung der Richtlinien

Kooperation aller föderalen Entitäten

K.G - original vom 23.01.2024

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister

Insgesamt ist es wichtig, dass die Umsetzung dieser Richtlinien in einer Weise erfolgt, die den Bedürfnissen und Kapazitäten der verschiedenen Kommunen gerecht wird, da diese unterschiedliche (finanzielle) Ressourcen und technische Fähigkeiten haben können.

Konkret sollten folgende Punkte mitbedacht werden:

Kommunikation und Schulung:

Erläuterung der Bedeutung und der Vorteile von IT-Architekturrichtlinien und deren Einhaltung

Erstellung von Best Practices, die den Kommunen helfen, die Richtlinien umzusetzen

Informieren der Mitarbeitenden, Anbieten von Schulungen.

Stakeholder-Engagement: Involvement aller relevanten Stakeholder (IT-Teams, Führungskräfte, Abteilungen und externe Partner) in den Umsetzungsprozess. Offene Kommunikation und Feedback.

Technische Basisinfrastrukturen/kooperative Ansätze:

Bereitstellung technischer Basisinfrastrukturen inkl. technischer Unterstützung

Schaffung von Plattformen, über die die Kommunen Erfahrungen austauschen und voneinander lernen können

Regelmäßige Überprüfungen und Audits, um sicherzustellen, dass die Richtlinien eingehalten werden. Automatisierung der Überprüfungsprozesse (wenn möglich) und Einhaltung sicherstellen.

Implementierungsleitfaden: Implementierungsleitfäden, die die Schritte zur Umsetzung der Richtlinien detailliert und adressatengerecht beschreiben (Entwickler, Behördenmitarbeiter, Politik).

Feedback: Feedbackschleifen, um kontinuierliche Verbesserungen vorzu-nehmen. Rückmeldungen der Stakeholder aufnehmen Richtlinien gegebe-nenfalls anpassen.

Dokumentation und Transparenz: Sicherstellen, dass alle relevanten Informationen und Dokumentationen leicht zugänglich sind. Schaffung von Transparenz bezüglich der Richtlinien, ihrer Bedeutung und Auswirkungen.

Anreize und Belohnungen: Schaffung von (finanziellen) Anreizen oder Belohnungen für Kommunen, die die Richtlinien freiwillig umsetzen

Verpflichtende Vorgaben

In einigen Fällen könnte der Bund auch verpflichtende Vorgaben einführen, die die Kommunen dazu verpflichten, bestimmte Standards oder Maßnahmen zur Einhaltung der IT-Architekturrichtlinien zu erfüllen.

Hierbei ist die Frage der Finanzierung entscheidend. Die Umsetzung von IT-Architekturrichtlinien erfordert oft erhebliche finanzielle Mittel für die Anpassung oder Erneuerung von IT-Infrastrukturen, den Erwerb neuer Software oder die Schulung von Mitarbeitern.

B.S - original vom 28.01.2024

GKV-Spitzenverband

Die Umsetzung der Richtlinie hängt maßgeblich von deren Akzeptanz ab. Die Sozialversicherung hat sich bereits seit vielen Jahren eine Richtlinie für die technischen Rahmenbedingungen gegeben, die mittlerweile durch den § 95 SGB IV rechtlich abgesichert und verpflichtend zu beachten ist.

Bei der Ausgestaltung der Richtlinie hat es sich bewährt, die Anpassungen im Konsens mit den übrigen Verfahrensbeteiligten vorzunehmen, damit die Anpassungen bzw. die sich daraus ergebenden Aufwände durch alle mitgetragen werden.

C.R - original vom 28.01.2024

Aus Sicht von BearingPoint möchten wir Folgendes anmerken:

Um die überarbeiteten IT-Architekturrichtlinien künftig konsequent umsetzen zu können, ist neben den in unserer Antwort zu Frage 10 beschriebenen wesentlichen Grundvoraussetzungen insbesondere die Etablierung von übergreifenden Enterprise-Architecture-Fähigkeiten notwendig.

D. h. die Fähigkeiten solche Architekturrichtlinien zu planen, zu ändern, die Anwendung der Richtlinien zu steuern (Governance) und insgesamt nutzbringend zu etablieren. Letzteres insbesondere auch durch flankierende Maßnahmen wie z. B. mittels Referenzarchitekturen, Arbeitsvorlagen, einheitliche Definitionen (u. a. Nutzen des ArchiMate-Standards), Architektur-Wissensmanagement und einem praktischen Austausch der Handlungsträger.

Um zu identifizieren welche (Enterprise-Architecture-)Fähigkeiten für die Umsetzung der IT-Architekturrichtlinien relevant sind und wie diese Fähigkeiten etabliert werden können, ist ein entsprechendes (EA-)Fähigkeitenmodell sinnvoll.

Hier kann auf oberster Ebene der (EA-)Fähigkeiten differenziert werden in - die strategische Ebene, die sich mit der Ausrichtung der IT-Architekturrichtlinien an der Geschäftsstrategie und den Stakeholder-Anforderungen befasst (Vision, langfristige Strategie, Kommunikation auf Leitungsebene etc.), - die taktische Ebene, die sich mit der Planung, der Steuerung und der Umsetzung der IT-Architekturrichtlinien befasst (u. a. auch entsprechende Governance-Prozesse), - die operative Ebene, die sich mit der Ausführung, der Anpassung und der Optimierung der IT-Architekturrichtlinien befasst, sowie Hilfestellungen bei deren Anwendung gibt, z. B. durch Referenzarchitekturen, Vorlagen für typische Architekturartefakte, Schaffung einer einheitlichen Verständigungsbasis (z.B. nicht nur, aber insbesondere durch den Einsatz des ArchiMate-Standards), Werkzeuge empfiehlt oder bereitstellt, eine Community zum kontinuierlichen Austausch, Wissensmanagement etc.

Auf strategischer und operativer Ebene ist ein entscheidender Erfolgsfaktor, dass die IT-Architekturrichtlinien (inkl. der flankierenden Maßnahmen, s. o.) als an/in sich sinnvoll und nutzbringend angesehen werden (=intrinsische Akzeptanz). Dies gilt umso mehr für die föderale Zusammenarbeit zwischen den Ebenen Bund, Land und Kommune.

Bei der Betrachtung, Ausgestaltung und Umsetzungen eines solchen (EA-)Fähigkeitenmodells ist auch die Betrachtung der verschiedenen Rollen wichtig und die Identifikation der je nach Rolle, Ebene und (Enterprise-Architecture-Teil-)Fähigkeit sinnvollen, bzw. notwendigen Rollenfähigkeiten.

Typische Rollen sind: - Der Enterprise Architekt, der die Gesamtverantwortung für die Gestaltung und Steuerung einer Unternehmensarchitektur hat. - Der Domänenarchitekt, der die Verantwortung für die Gestaltung und Steuerung einer bestimmten Domäne der Unternehmensarchitektur hat, wie z.B. Geschäftsarchitektur, Informationsarchitektur, Anwendungsarchitektur oder Infrastrukturarchitektur. - Der Lösungsarchitekt, der die Verantwortung für die Gestaltung und Steuerung einer bestimmten Lösung hat, die eine oder mehrere Domänen der Unternehmensarchitektur umfasst. - Der Projektleiter, der die Verantwortung für die Planung, die Koordination und die Umsetzung von Projekten hat, die die Unternehmensarchitektur verändern oder beeinflussen. - Der Business Analyst, der die Verantwortung für die Analyse, die Modellierung und die Kommunikation der Geschäftsprozesse und der Anforderungen der Stakeholder hat. - Der IT-Spezialist, der die Verantwortung für die Entwicklung, die Integration, den Betrieb und die Wartung der Informationssysteme und der Technologien hat.

Je nach IT-Architekturrichtlinie und deren Auswirkung auf die jeweilige IT-Architektur müssen die Bedarfe und Fähigkeiten dieser Rollen berücksichtigt werden, um eine konsequente Umsetzung zu unterstützen.

Aus einem solchen (EA-)Fähigkeitenmodell und der Umsetzungsbetrachtung entsteht eine Fähigkeitenlandkarte, welche den aktuellen Stand und das notwendige bzw. gewünschte Ziel der jeweiligen (Teil-)Fähigkeiten beschreibt (d. h. den Reifegrad). Solche Reifegrade können z. B. anhand von ACMM (Architecture Capability Maturity Model) oder CMMI (Capability Maturity Model Integration) festgelegt und deren Erreichung geplant sowie gemessen werden – siehe auch TOGAF hierzu.

G.B - original vom 28.01.2024

Indem ein Einhalten der IT-Architekturrichtlinen eine Akzeptanz der Lösung durch die Bevölkerung zur Folge hätte, dies bspw. durch die einführung Nutzer*innen bezogener Leitplanken. Eine positive und vertrauensbildende Wahrnehmung der IT-Architekturrichtlinien und somit ein möglicher politischer Druck zu ihrer Einhaltung könnte eine Priorisierung der Umsetzung durch die Verwaltung zur Folge haben.

10. Einhaltung der föderalen IT-Architekturrichtlinien

Datum der Veröffentlichung: 18.12.2023
Anzahl eingegangener Antworten: 21
Issue # in GitLab: #148
Leitfrage 10 Einhaltung der föderalen IT-Architekturrichtlinien

Was muss geändert werden, damit die IT-Architekturrichtlinien eingehalten werden?

Bitte beantworten Sie die Leitfrage im unteren Kommentarbereich. Veröffentlichen Sie Ihren Kommentar im Namen Ihrer Organisation.

D.K - editiert am 30.12.2023

Einführung klarer Richtlinien und Standards: Definition von klaren IT-Architekturrichtlinien und -standards, die von allen Teams und Projektbeteiligten verstanden werden können. Dies erleichtert die Umsetzung und fördert die Einheitlichkeit. KISS-Prinzip befolgen (Keep It Simple and Stupid).

Schulung und Sensibilisierung: Beteiligte müssen die Bedeutung der IT-Architekturrichtlinien verstehen. Dabei ist eine Sensibilisierung für Best Practices und mögliche Auswirkungen von Nichteinhaltung entscheidend.

Regelmäßige Überprüfungen und Risikomanagement: Implementieren von regelmäßigen Überprüfungen, um sicherzustellen, dass die aktuellen Systeme und Anwendungen den definierten Richtlinien entsprechen. Dies ermöglicht es, etwaige Abweichungen frühzeitig zu erkennen und zu beheben. Ein effektives Risikomanagement ist dabei hilfreich, um potenzielle Risiken im Zusammenhang mit der Einhaltung der IT-Architekturrichtlinien zu identifizieren und zu bewerten.

Agile Methoden fördern: Implementierung agiler Methoden und DevOps-Praktiken, um eine kontinuierliche Integration und Bereitstellung zu ermöglichen. Dies erleichtert die schnelle Anpassung von Systemen und Anwendungen an sich ändernde Anforderungen, während die Architekturrichtlinien eingehalten werden.

Dokumentation: Sicherstellung, dass es eine umfassende Dokumentation für die IT-Architektur gibt. Dies erleichtert die Kommunikation zwischen den Teams und fördert das Verständnis sowie den Austausch für die bestehenden Architekturrichtlinien.

Kommunikation und Zusammenarbeit fördern: Schaffung einer Kultur der offenen Kommunikation und Zusammenarbeit zwischen den Entwicklungsteams, dem Architekturteam und weiteren relevanten Stakeholdern.

Verhinderung “reglementierender” Vorgaben / Prinzipien statt Vorgaben verwenden: Durch die Vorgabe zu spezifischer Richtlinien wird indirekt die Produktneutralität verletzt bzw. bestimmte Lösungsgruppen, Lösungsansätze oder Architekturparadigmen bevorzugt. Stattdessen sollte auf Prinzipien gesetzt werden, sprich IT-Architekturprinzipien.

A.K - editiert am 09.01.2024

Hier ist nicht so recht deutlich, auf welche Referenz sich die Frage, was sich ändern müsste, bezieht. Hier gehen wir erst einmal auf IT-Architekturen allgemein ein, und versuchen dann soweit möglich eine Bewertung hinsichtlich der föderalen IT-Architekturrichtlinien (soweit veröffentlicht).

Für die Einhaltung von Richtlinien ist generell entweder eine Rechtsgrundlage (Gesetz, Verordnung) oder eine bindende Vereinbarung (Beschluss, Contract) erforderlich. Hieraus leiten sich ggf. Verbindlichkeiten und Verpflichtungen ab, auch hinsichtlich der Finanzierung. Diese müssen natürlich auch umgesetzt und eingefordert werden. Eine Architekturrichtlinie sollte sich auf einen starken Rückhalt bei allen Beteiligten stützen.

Es ist nicht immer leicht, bei Architekturrichtlinien die richtige “Flughöhe” bzw. die richtige Balance zwischen Reglementierung und Freiheitsgraden/Flexibilität zu erzielen. Am Ende kann dies nur durch Erfahrung, durch kontinuierliche Überprüfung und vor allem im Rahmen kooperativer Prozesse erfolgen. Am Ende muss es hinauslaufen auf so viel Freiheit/Flexibilität wie möglich und so viel Regulierung wie nötig. Für IT-Architekturrichtlinien sind darüber hinaus generell einige Erfolgsfaktoren unerlässlich. Dazu zählen aus unserer Sicht insbesondere:

Mehrwert muss klar erkennbar sein

Umsetzung muss machbar sein

Notwendige Expertise muss vorliegen

Konsens aller benannten Stakeholder muss vorliegen

Daneben existieren eine Reihe weiterer Aspekte, die in jedem Fall positive Auswirkungen haben:

Stand der Technik muss abgebildet werden

Entwicklung sollte transparent erfolgen

Ziele, Anforderungen, Grundprinzipien und Rahmenbedingungen müssen systematisch und methodisch nachvollziehbar ermittelt sowie eindeutig und verständlich formuliert werden

Beschlussgrundlage und Rechtseinordnung müssen dargelegt werden

Jede Festlegung ist zu begründen und einer Wirksamkeits- und Folgenabschätzung zu unterziehen, absehbar unnötige oder gar schädliche Festlegungen sind zu vermeiden

Qualitätssicherung der Richtlinien erfolgt unabhängig von den Entwicklern der Richtlinien

Ableitung aus Zielen und Anforderungen sowie die Einordnung in den Kontext muss klar erkennbar und methodisch nachvollziehbar sein

Anwendbarkeit im Einzelfall sowie Verbindlichkeitsgrad sind klar zu definieren (was bedeutet KANN/SOLL/MUSS etc.)

IT-Architekturrichtlinien müssen genügend stabil sein, um hierauf verlässlich Investitionsentscheidungen treffen zu können

Anwendungsbereich (Scope) muss klar ausformuliert sein, insbesondere hinsichtlich der Verwaltungsebenen und der Berücksichtigung von Bestandsverfahren und bereits getätigten Investitionen

Unterschiedliche Leistungsfähigkeit der Beteiligten muss berücksichtigt werden

Richtlinien müssen ggf. eine schrittweise Umsetzung unterstützen und dürfen Umsetzer nicht überfordern

Umsetzung muss mit entsprechenden Unterstützungsangeboten unterlegt sein (dokumentierte Beispielumsetzungen, Blaupausen, Wissensbasen, Patterns, Beratung etc.)

Umsetzung wird beobachtet -> ggf. müssen zusätzliche Hilfen entwickelt werden oder Anpassungen an den Richtlinien selbst erfolgen

Weiterentwicklung muss in allen Dimensionen abgesichert und transparent erfolgen, wobei die Interessen der benannten Stakeholder stets gewahrt bleiben müssen

Verbindungen bzw. Abhängigkeiten zu externen Initiativen sind zu ermitteln und nachzuführen

Richtlinien müssen breit und verständlich kommuniziert und beworben werden

Einhaltung der Richtlinien muss im Rahmen einer Governance beobachtet und gefördert werden

Ob eine Richtlinie erfolgreich umgesetzt wurde oder nicht sollte nicht vom Umsetzer selbst festgestellt werden, sondern im Rahmen eines Audits (z.B. durch die Governance)

Konformität zur IT-Richtlinie sollte als wichtiges Kriterium zur Unterstützung der Digitalisierung genutzt werden (etwa im Rahmen von Ausschreibungen)

Insgesamt bildet die bestehende föderale Architekturrichtlinie des Architekturboards einige der oben genannten Aspekte ab. Dies beinhaltet insbesondere Zielentwicklung, Einordnung und die Einbeziehung von Stakeholdern, jedenfalls innerhalb der Verwaltung von Bund und Ländern.

Hinsichtlich der möglichen Änderungen speziell der föderalen Architekturrichtlinie sind einige Punkte sicherlich ausbaufähig, hierzu zählen u.a. Mehrwertdarstellung, Transparenz, Ableitung von Anforderungen, Wirkungs- und Folgenabschätzung, Unterstützungsangebote, Beobachtung der Umsetzung sowie die Feststellung der Konformität als Qualitätskriterium und deren Bedeutung, etwa bei Ausschreibungen.

Einige der oben genannten Punkte sind nicht anhand der öffentlich zugänglichen Quellen zu bewerten, hier sollte das Architekturboard ggf. eine Selbsteinschätzung vornehmen.

S.M - original vom 22.12.2023

Bundesagentur für Arbeit: Als Bundesbehörde wird die BA hierzu keinen Kommentar abgeben, da keine Betroffenheit vorliegt.

D.T.OZG.S - original vom 05.01.2024

Die föderalen IT-Architekturrichtlinien stellen ein generelles Regelwerk für die Umsetzung von Digitalisierungsvorhaben dar. Mithilfe der IT-Architekturrichtlinien wird den beteiligten Stakeholdern, insbesondere für diejenigen, die Umsetzungsvorhaben durchführen und verantworten, ein Regelwerk an die Hand gegeben, welches generelle Anforderungen definiert, die zu berücksichtigen sind.

Aus Sicht der Deutschen Telekom sollten folgende Maßnahmen ergriffen werden, um die Einhaltung der IT-Architekturrichtlinien zu erreichen:

Verbindlichkeitserklärung

Die Anwendung einer IT-Architekturrichtlinie wird Ressourcen (finanziell und personell) beanspruchen. Die Anwendung der IT-Architekturrichtlinie sollte in einem – im Vergleich zum Beschluss des IT-Planungsrates – formelleren und verbindlicheren Rahmen erfolgen.

Detaillierung und Wissensaufbau bei relevanten Stakeholdergruppen

Die IT-Architekturrichtlinien sind zu detaillieren. Die Detaillierung muss es Verwaltungen erlauben, diese innerhalb ihres Zuständigkeitsbereichs umzusetzen (bzw. umsetzen zu lassen). Das Wissen zu diesen IT-Architekturrichtlinien muss bei den relevanten Stakeholdergruppen, insbesondere zuständigen Verwaltungen, öffentlich-rechtlichen und privatwirtschaftlichen IT-Dienstleistern, etabliert werden.

Anwendung bei neuen Vorhaben

Die IT-Architekturrichtlinie ist bei neuen Vorhaben verbindlich umzusetzen. Sie muss Auswirkungen auf die Liefergegenstände haben und innerhalb der Projektziele berücksichtigt sein.

Anpassung bestehender Infrastrukturen

Zunächst ist der Stand Quo der relevanten Bausteine inkl. eines Abgleichs zur Konformität zur IT-Architekturrichtlinie aufzunehmen. Diese Bestandsaufnahme muss innerhalb der umsetzenden Verwaltungen und unter Beteiligung der IT-Dienstleister erfolgen. Abweichungen von der IT-Architekturrichtlinie sollten beseitigt werden. Anpassungsbedarfe sind in Form von Projekten zu priorisieren, initialisieren und umzusetzen. Das Projektportfolio mündet in einer (verwaltungsspezifischen) Roadmap über deren Umsetzungsstand berichtet wird.

Etablierung einer Architektur-Governance

Richtlinien ohne Kontrolle sind wirkungslos. Es muss eine Architektur-Governance aufgebaut werden, die die Einhaltung der IT-Architekturrichtlinien (oder der begründeten Abweichungen davon) überwacht.

Fortschreibung

Die IT-Architekturrichtlinie ist unter Beteiligung relevanter Stakeholdergruppen fortzuschreiben.

DIHK.I.K - editiert am 09.01.2024

Grundsätzliche Anmerkung vorab:

Auch diese Frage hätte, um gute Beantwortung durch die Teilnehmenden zu ermöglichen, eine bessere Kontextualisierung und eine differenziertere Formulierung benötigt. Als Kontextualisierung wären bspw. hilfreich gewesen:

die Verlinkung der gemeinten Richtlinien

ihr bisheriger Adressatenkreis (wer muss anwenden?) und ihr sachlicher Wirkungskreis (für welche Projekte)

eine Zusammenfassung der Erwartungen, die das BMI bzw. der IT-Planungsrat an die Richtlinien hatte und heute hat

eine kurze Zusammenfassung, inwieweit die Richtlinien bisher angewendet worden sind und welche Effekte beobachtet wurden

eine Differenzialanalyse zwischen dem Ansprüchen bei Verabschiedung und der real beobachteten Verwendung

Mit diesen Bausteinen wäre alle Teilnehmenden des Konsultationsprozesses auf ein gemeinsames informatorisches Niveau gehoben worden und hätten so passgenaue Antworten verfassen können.

Die Kommentierung durch die DIHK erfolgt ohne diese Kontextualisierung unter der Annahme, dass diese Richtlinien gemeint sind: Beschluss2021-37_IT-Architekturboard_AL1_Architekturrichtlinien.pdf (it-planungsrat.de) , die mit diesem Beschluss der IT-Planungsrates eingeführt wurden: Beschluss 2021/37 - IT-Architekturboard | IT-Planungsrat : „Der IT-Planungsrat beschließt die verbindliche Anwendung der „Föderalen IT-Architekturrichtlinien“ Weitere Dokumente standen uns nicht zur Verfügung.

Spezifisch zur gestellten Frage: Was muss geändert werden, damit die IT-Architekturrichtlinien eingehalten werden?

Zunächst müsste expliziert werden, für wen (welche Behörden) und für was (welche Projekte) die Richtlinien im Status Quo schon gelten – aufbauend auf welcher Legitimationskette und in welchem Grad der Verbindlichkeit.

Sollten der bisherige Kreis der Verpflichteten die Architekturrichtlinien nicht beachten, kann das an schlicht fehlendem Wissen über die eigene Betroffenheit liegen. Auch der Grad der Verbindlichkeit könnte zu niedrig gewählt sein – inkl. fehlenden Kontroll- und Sanktionsmechanismen. Dann kommen alle inhaltlichen Beweggründe, die Ansgar Kückes weiter unten sehr gut aufgeführt hat, zum Tragen.

Sollte es darum gehen, dass der Kreis der Verpflichteten an sich zu klein ist und die Architekturrichtlinien zur Optimierung der Effizienz der föderalen Verwaltungsdigitalisierung von mehr Akteuren in mehr Projekten Anwendung finden müssten, muss man den Kreis der Verpflichteten erweitern. Eine freiwillige Beachtung von Grundsätzen wird sich in einem ansonsten hochregulierten Umfeld wie der IT-Beschaffung und -Entwicklung im öffentlichen Sektor nicht durchsetzen können.

A.S - original vom 09.01.2024

Zustimmung zur Anmerkung vorab und zur Antwort auf die Frage.

J.P.S - editiert am 09.01.2024

Materna und Infora

Um die Einhaltung der IT-Architekturrichtlinien zu gewährleisten, muss in den IT-Umsetzungsprojekten an der Akzeptanz und dem Verständnis für den Nutzen dieser Einhaltung angesetzt werden.

Folgende Maßnahmen können dazu beitragen

Referenzprojekte und Best Practices

Wichtig ist, dass es Referenzprojekte in allen Größen gibt, an denen ersichtlich wird, dass die Richtlinien auch in der Praxis angewandt werden können und das Projekt damit seine Ziele erreicht hat.

Dokumentation und Kommunikation - Sicherstellen, dass die IT-Architekturrichtlinien klar und umfassend dokumentiert sind - Kommunizieren der Richtlinien an alle relevanten Stakeholder, einschließlich Entwicklern, IT-Personal und anderen Beteiligten

Weiterbildungsmöglichkeiten und übergreifende Zusammenarbeit - Anbieten von Webinaren o.ä. um Umsetzende mit den Richtlinien vertraut zu machen - Förderung der Zusammenarbeit zwischen verschiedenen Organisationen

Kontinuierliche Verbesserung - Ein Prozess zur kontinuierlichen Verbesserung der IT-Rahmenarchitektur sollte eingerichtet und kommuniziert werden.

E.S - original vom 08.01.2024

Für den Bitkom e.V.

IT-Architekturrichtlinien sind kraft ihrer Natur häufig sehr abstrakt. Diese sollten daher zusätzlich in eine domänenspezifischen Architekturrichtlinie überführt werden. Auf diese Art und Weise wird sichergestellt, dass die Richtlinien im jeweiligen Bereich auch richtig interpretiert und zweckentsprechend eingesetzt werden.

Der Plattformgedanke kann helfen zentrale Vorgaben umzusetzen – passend dazu sollte es eine zentrale Instanz geben, die zügig finale Entscheidungen treffen und Vorgaben machen kann. Dazu benötigt es eine Rechtsgrundlage, welche diese Entscheidungen auch für die Länder verpflichtend vorgibt. In § 4 OZG ist die verbindliche Vorgabe zur Verwendung bestimmter IT-Komponenten (für Verwaltungsverfahren, die der Durchführung unmittelbar geltender Rechtsakte der Europäischen Union oder der Ausführung von Bundesgesetzen dienen) zwar vorgesehen, das zur Verfügung stehende rechtliche Instrumentarium wird bislang jedoch zu selten genutzt.

Grundsätzlich sollte die zentrale Bereitstellung und gemeinschaftliche Nutzung von Basiskomponenten bzw. deren nachhaltige Nachnutzung verstärkt werden. Hier ist eine Nutzer- und Anbindungsfreundlichkeit genauso wichtig wie bei den Onlinediensten. Der Entwurf des OZG-Änderungsgesetzes schlägt bei diesem Thema den richtigen Weg ein. Es sollten Anreize geschaffen werden, dass gemeinsame Standrads und gemeinsame Infrastrukturen auch konsequent genutzt werden (Basiskomponenten; FIM-Bausteine; bestehende Kataloge etc.). Gleichzeitig sollte für die Anwenderinnen und Anwender eine einfache Möglichkeit geschaffen werden, jederzeit die bestehenden Richtlinien zu kommentieren. Hierdurch kann sichergestellt werden, dass Zielkonflikte (Vorgaben versus Umsetzung) frühzeitig angezeigt und geklärt werden können.

S.L.B - original vom 08.01.2024

Die Bundessteuerberaterkammer regt an, die finalen IT-Architekturrichtlinien so konkret wie möglich auszuarbeiten und mit Beispielen zu erklären. Dadurch können eine höhere Verbindlichkeit und Anschaulichkeit erreicht werden. Begleitend dazu könnten Checklisten und weitere Leitfäden erarbeitet werden, die die Überprüfbarkeit vereinfachen und eine Konformitätsfeststellung ermöglichen.

Austauschmöglichkeiten, wie der aktuell stattfindende Konsultationsprozess, fördern den Erhalt und Weiterentwicklung der Richtlinien. Regelmäßige Workshops, die ggf. Einblicke in andere Projekte vermitteln, schaffen Transparenz und geben Anhaltspunkte zur richtigen Anwendung der Architekturrichtlinien.

Letztlich könnten auch eigens entwickelte Tools oder einzelne Bausteine zur Verfügung gestellt werden. Die Tools unterstützen bei der Einhaltung der Architektur, vorgefertigte Bausteine erleichtern die Umsetzung, beschleunigen die Vorhaben und sorgen für eine Einheitlichkeit.

N.L - original vom 08.01.2024

Damit die IT-Architekturrichtlinien eingehalten werden, muss ein hohes Maß an Verbindlichkeit für gesetzte Standards gewährleistet werden. Werden bloße Leitlinien vereinbart, deren Ausgestaltung und Einhaltung offen und optional ist, so erschwert dies eine flächendeckende Umsetzung. Es müssen Kontrollmechanismen eingeführt und Hilfestellungen für die Umsetzung angeboten werden, um einen langfristigen Erfolg zu erzielen.

Farina Owusu und Nico Lück (GovStack Initiative)

J.P - original vom 09.01.2024

Antworten Team PwC:

• Es muss die Verbindlichkeit der IT-Architekturrichtlinien von Seiten des Bundes ggü. Ländern und Kommunen durchgesetzt werden (ggf. durch Aufnahme in ein entsprechendes Gesetz, z.B. „OZG 3.0“).

• Neben einer rechtlichen Verbindlichkeit können Richtlinien auch inhaltlich überzeugen. Das heißt die Richtlinien sind in einer Weise ausgestaltet, dass sie in den einzelnen Behörden als vorteilhaft erachtet und daher freiwillig implementiert werden.

A.S - editiert am 09.01.2024

Aus Sicht der DigitalService GmbH des Bundes:

Zur Einhaltung und Umsetzung der IT-Architekturrichtlinien sowie einer neuen/ergänzten OZG-Rahmenarchitektur lässt sich Ähnliches sagen. Da es unklar ist, welche Richtlinie mit der Frage genau gemeint ist, wird allgemein geantwortet.

Nach SWF gibt es systemisch zwei Interventionsprinzipien:

[a] Störung von Mustern: Dies beinhaltet das Unterbrechen eines problematischen Kreislaufs, um das Problem zu reduzieren oder unwirksam zu machen, und

[b] Etablierung neuer Muster: Dies bedeutet, einen neuen Kreislauf oder ein neues Muster zu schaffen, um effektiv zu werden.

Sowie drei Ebenen der Intervention:

Ebene [1]: Interventionen, die sich auf das soziale System mit seinen interaktionellen und kommunikativen Mustern konzentrieren.

Ebene [2]: Interventionen, die auf spezifische Verhaltensmuster und die Verknüpfung von Interaktion und Wirklichkeitskonstruktion abzielen.

Ebene [3]: Interventionen, die sich auf allgemeine psychische (Denk-)Muster der Wirklichkeitskonstruktion konzentrieren.

Ideen dazu wie dies konkret aussehen könnte:

Gezieltes Aufzeigen von Fehlern und Mängeln in aktuellen Projekten, die den neuen Richtlinien nicht entsprechen. Eine Behörde könnte z.B. eine Revision von laufenden Projekten veranlassen, um die Konformität mit den neuen Richtlinien zu überprüfen. [2a]

Einführung von Anreizen für die Einhaltung der neuen Richtlinien, wie z.B. zusätzliche Budgets oder Priorisierung bei der Vergabe von IT-Projekten. Politiker könnten Fördermittel oder Auszeichnungen für Projekte bereitstellen, die den neuen Standards entsprechen, Best Practices können beworben werden. Oder es könnte gesetzlich/per Verordnung eingeführt werden, dass neue IT-Projekte nur noch unter Einhaltung der Leitlinien vergeben werden dürfen. [1b][2b]

Kritische Diskussionen und Debatten über veraltete IT-Ansätze, Hinterfragen proprietärer Ansätze und bestehende föderale Lizenz- und Finanzierungsmodelle, um ein Umdenken zu fördern. Politiker könnten in öffentlichen Reden die Bedeutung moderner IT-Strukturen, modernen Entwicklungsmethoden und offener Governance-Strukturen hervorheben. [3a]

Implementierung offener, jedoch starker Governance-Strukturen mit eindeutiger Zuordnung von Rollen und Mandaten, und auch dem Ownership inkl. Anreizen zur Weiterentwicklung, um Blockaden in den Systemen zu überwinden, effektive Entscheidungsfindung und eine effektivere Umsetzung und Durchsetzung der Richtlinien zu ermöglichen. [2a][2b]

Einführung von Workshops und Schulungen für Behörden und IT-Dienstleister, um das Verständnis und die Akzeptanz der neuen Richtlinien zu fördern. Ein Beispiel wäre die Durchführung von Schulungen durch IT-Experten, um die Vorteile und die praktische Anwendung der neuen Richtlinien zu erläutern. [1b] [3b]

Genereller Aufbau von Kompetenzen und Plattform-Know-How in der öffentlichen Verwaltung. Schulungen und Coaching von Politikern, Behörden und IT-Dienstleistern zum Mindset und den IT-Richtlinien. Auch eine Visualisierung kann helfen. [3b]

Schaffung einer Kultur der ständigen Verbesserung und Innovation im IT-Bereich. Ein Beispiel wäre eine regelmäßige Überprüfung und Anpassung der IT-Richtlinien, um mit technologischen Entwicklungen Schritt zu halten, wobei Politiker, Behörden und IT-Dienstleister gemeinsam an der Aktualisierung und Verbesserung der Richtlinien arbeiten. [3b]

F.K - original vom 10.01.2024

Aus dem Bereich der Hochschulen und Kultureinrichtungen des Landes Hessen:

Sie scheinen nur für Fitko-Projekte relevant zu sein und in diesem Kontext abgestimmt worden zu sein. Sollte die Anwendbarkeit breiter sein, muss auch der Prozess der Einbindung der Stakeholder breiter gefasst sein und von ihnen das Commitment eingeholt werden, z.B. wird im Bereich der Hochschulen die Freiheit von Forschung und Lehre als wichtig angesehen.

SEITENBAU - original vom 10.01.2024

Aufbauend auf die Rückmeldungen zu Leitfrage 04 kann folgender Änderungsbedarf festgehalten werden, um eine bessere Einhaltung der IT-Architekturrichtlinien zu erreichen (angelehnt an Struktur in Kommentar zu Leitfrage 04).

1. Allgemein

Bekanntheitsgrad: Die Zielgruppen der IT-Architekturrichtlinien (Ausschreibende, Beauftragende, Umsetzende etc.) werden identifiziert und geeignete Kanäle gefunden, mit denen die IT-Architekturrichtlinien bekannt gemacht werden. Ggf. werden begleitende Informationen, wie die Relevanz, sowie Chancen bei Beachtung und Risiko bei Missachtung der Richtlinien erläutert. Berichte über Best Practises bei Neu- oder Weiterentwicklungen können die Anwendbarkeit der Richtlinien konkret aufzeigen. Interessant wäre auch eine Betrachtung je Funktionsbausteine (vgl. Leitfrage 08): Welche bestehenden Lösungen erfüllen bereits wie gut die Richtlinien?

Ungünstige Ausgangslage (Eine Entscheidung, die im Widerspruch zu den Architektur-Richtlinien steht, wurde bereits vor Kenntnis der Richtlinien gefällt): Stehen keine zeitlichen oder wirtschaftlichen Gründe einer Korrektur der Entscheidung entgegen, so soll diese angestrebt werden. Bestehen Gründe, so sollte geprüft werden, inwiefern später im Lifecycle der Lösung eine Kompatibilität mit den Richtlinien erreicht oder ob der Einsatzbereich der Lösung klein gehalten werden kann.

Bezogen auf konkrete Leitlinien

Verwendung von Standards (SR1)

Ein für einen Anwendungsfall zu umfangreicher und aufwendiger oder ein zu generischer, nicht ausreichender Standard: Grundsätzlich wäre es wünschenswert, wenn Lösungsumsetzer leicht einen direkten Kontakt zu Standardverantwortlichen finden und ggf. einen Weg zur (perspektivischen) Beseitigung der Differenzen finden. Aufzeigen einer abweichenden und standardkonformen Lösung, CRs für den Standard aber auch das Akzeptieren der Abweichen können das Ergebnisse sein.

Sicherstellung von Wiederverwendung (SR2)

Identifikation einer geeigneten Lösung gestaltet sich schwierig: Mit Entscheidern kann in Stichproben geklärt werden, ob diese in der Lage sind sich einen Überblick über bestehende Lösungen zu verschaffen (z.B. Kenntnis über Marktplatz, GovDigital). Maßnahmen zur Erhöhung des Bekanntheitsgrads bzgl. Möglichkeiten zur Marktanalyse können daraufhin ergriffen werden. Angebote wie der Marktplatz für EfA-Leistungen und GovDigital können das eigene Portfolio aktiv steuern (ggf. anhand der Funktionsbausteine, vgl. Leitfrage 08), indem benötigte aber nicht gelistete Lösungen identifiziert werden und ggf. bestehende Lösungen zur Eintragung bewogen werden.

Geeignete, wiederverwendbare Lösungen stehen nicht zur Verfügung: Annahme: Für jeden Funktionsbaustein gibt es Lösungen. In bestimmten, zukünftigen Anwendungsfällen können diese jedoch nicht ausreichen. Eine Möglichkeit wäre, dass Hersteller einer Lösung transparent machen, inwieweit weitere Anforderungen von Dritten in die Weiterentwicklung eingebracht werden können. Die Kooperation zwischen Hersteller und Nachnutzer wird so erhöht und bestehende Lösungen mutmaßlich verbessert.

Sicherstellung der Herstellerunabhängigkeit (SR7)

In einer Information zu den IT-Architekturrichtlinien können Modelle der Zusammenarbeit zwischen Verwaltung und Herstellern beschrieben werden, die die Herstellerunabhängigkeit sicherstellen und attraktiv für Hersteller sind. Dabei kann auf bestehende Modelle zurückgegriffen werden, die Verwaltung und private IT-Softwareerstellungsdienstleister bereits heute nutzen.

Bei Neuentwicklungen können Ausschreibende und Beauftragende auf diese Modelle zurückgreifen, um die Herstellerunabhängigkeit sicherzustellen.

E.H - original vom 12.01.2024

Antwort von Bundesamt für Migration und Flüchtline (BAMF):

Das Einhalten von einigen Architekturrichtlinien kann anhand von Konformitätsprüfungen erreicht werden. Gütesiegel mit einem Level könnten dazu beitragen, eine Aussage über den Grad der Konformität und damit implizit eine Aussage über die Einhaltung der Architekturrichtlinien zu treffen. Ähnlich wie die Gütesiegel im Supermarkt kann der Konsument selbst entscheiden, welchen Dienst er verwenden will - wir gehen von einem Marktplatz aus und nicht von zentralistischen OZG.

Eine Selbsteinschätzung oder sogar ein teilautomatisierter Prozess könnte auch funktionieren. Ähnlich wie bei der agilen Transformation, wo einige Teams einfach schon woanders "stehen" (können) und man sich als Team auf einer Übersicht vielleicht im positiven Sinne "herausgefordert" gegenüber anderen fühlen könnte, könnten Statuswerte wie "Basiskonformität in Arbeit", "Mindestanforderungen erfüllt", "KVP" hier ein Ansatz sein.

Zusammenfassend könnte pro Dienst angezeigt werden: Erreichungsgrad, Gütesiegel mit Level (Fremd- und/oder Selbsteinschätzung), Trend

D.S - original vom 17.01.2024

Unsere Kommentierung bezieht sich explizit auf die Verhältnisse im kommunalen Markt.

Die Richtlinien müssen in einem offen Beteiligungsprozess wie bei der Entwicklung von Standards erstellt und verabschiedet werden. Damit steigt Qualität und Akzeptanz der Standards bei allen Akteuren. Solange diese im geschlossenen Kreis durch markt- und fachfremde Teilnehmer entwickelt werden, werden diese vorwiegend auf Ablehnung stoßen.

Ein Problem besteht auch in den Fällen, wo eine Einhaltung der Richtlinien das Produkt am Markt verteuert und ein Anbieter bei deren Berücksichtigung dann wirtschaftliche Nachteile erfährt, weil er Ausschreibungen mit seinem dann teureren Produkt verliert. Es darf nicht sein, dass die Berücksichtiging der Richtlinien zu Nachteilen für den Hersteller führt.

Wenn Richtlinien in einem offenen Prozess gemeinsam entwickelt wurden, sollten diese anschließend Verbindlichkeit in allen (auch kommunalen) öffentlichen Ausschreibungen haben. Nur damit entsteht automatisch ein wirtschaftlicher Anreiz für alle Anbieter, diese Richtlinien auch umzusetzen.

Grundsätzlich sollten Richtlinien möglichst technologieoffen erstellt werden, um Wettbewerb, Innovation und Nachhaltigkeit zu gewährleisten. Bei einer reinen Zentrierung auf OpenSource, werden etablierte Lizenzanbieter im Markt automatisch zu Gegnern, was der Akzeptanz und Durchsetzung der Richtlinie nicht zutäglich ist. Da es im Markt der kommunalen Fachverfahren nur Lizenzprodukte gibt, wäre eine Einhaltung der Richtlinie dann sogar ausgeschlossen.

M.N.AKDB - original vom 18.01.2024

Die Compliance von Architekturrichtlinien entscheidet sich maßgeblich an deren intrinsischer Eignung des Regelungsgegenstandes, also müssen die Architekturrichtlinien einen maximalen Bezug zur Realität der Verwaltungsdigitalisierung auf den jeweiligen Ebenen des Staatsaufbaus haben. Um dafür eine maximale Effizienz zu erreichen, sollten keine erdrosselnden Zentralisierungskonzepte verfolgt werden, welche insbesondere auf Anwendungsebene Milliarden an Investitionen und bestehende Prozesse vernichtet, sondern vielmehr sich auf die Durchlässigkeit der Daten und Prozesse zwischen den Ebenen des Verwaltungsaufbaus konzentrieren. Standards und mit Bedacht gesetzte allgemeine Infrastrukturvorgaben/-komponenten können das gesamte Ökosystem positiv beeinflussen; überzogene, falsch gesetzte Vorgaben erdrosseln es und führen zu einer Überforderung der betrauten Stellen und insgesamt zu einem Nichtfunktionieren des Systems.

S.G - original vom 18.01.2024

Aus Sicht der VISION Consulting GmbH sollten hier mindestens die folgenden Punkte berücksichtigt werden:

Standardisierung entsprechend den Leitplanken

Dokumentation und zentrale Veröffentlichung

Kenntnis, Schulung und Sensibilisierung der Richtlinien

Interoperabilität und Transparenz

Kooperation aller föderalen Entitäten

K.G - original vom 23.01.2024

VITAKO - Bundes-Arbeitsgemeinschaft der Kommunalen IT-Dienstleister:

Wir stimmen dem Kommentar von Manfred Neidel AKDB @oc000002448180 zu! Konkret geändert bzw. beachtet werden für die Einhaltung der IT-Architekturrichtlinien müssen aus unserer Sicht:

Analyse der Richtlinien

Bestandsaufnahme der aktuellen Systeme / Infrastrukturkomponenten

Abgleich Ist-/Sollzustand

Roadmap zum Sollzustand

Vorbereiten der Stakeholder, Kommunikation, Schulungen

Implementierung

Testen

Betrieb, Wartung, Verbesserung (aktuelle Best Practices und Anpassung an möglicherweise veränderte Richtlinien).

C.R - original vom 28.01.2024

Gegenüber der von uns wahrgenommenen Praxis, möchten wir aus Sicht von BearingPoint Folgendes anmerken:

In erster Linie ist ein entsprechendes Commitment der Leitungsebenen zur aktiven Nutzung und Einhaltung der IT-Architekturrichtlinien notwendig. Nach Finalisierung der IT-Architekturrichtlinien müssen diese durch die Leitungsebenen vertreten und durch die IT-Architekten gelebt werden. Dies umfasst insbesondere die weitere Ausgestaltung einer Unterstützung der Umsetzung. Hierzu zählt die ausreichende Ressourcenausstattung zur Begleitung von Projekten durch IT-Architekten, welche eine Einhaltung der Richtlinien in diesen Projekten sicherstellt. Gleiches gilt für die Prüfung von bereits existierenden bzw. nicht begleiteten Projekten. Im einfachsten Sinne könnte dies eine Prüfinstanz sein, welche Projektanträge öffentlicher Stellen auch seitens Architekturboard prüft und bei der Projektabnahme die Konformität der Ergebnisse zu den IT-Architekturrichtlinien betrachtet.

Ein weiterer wichtiger Punkt ist die Akzeptanz der IT-Architekturrichtlinien. Hierzu zählt u.a. Transparenz in Bezug auf die Richtlinien bspw. Notwendigkeit/ Erforderlichkeit, Mehrwerte & Konsequenzen bei Nichteinhaltung solcher Richtlinien, aber auch konstruktive Unterstützung durch z.B. konkrete Benennung von einsetzbaren Technologien oder Open Source Tools. Die Kommunikation mit betroffenen Stellen ist hierbei essenziell und sollte regelmäßig (zumindest im Rahmen von Aktualisierungen) erfolgen.

Es sollte jedoch immer berücksichtigt werden, dass Ausnahmen von den Richtlinien notwendig sein können und möglich sein müssen. Solche Ausnahme müssen begründet erfolgen, dürfen kein Regelfall werden und werden dokumentiert (z.B. in einem Architecture Decision Log) und nachgehalten. Hier ist eine ausgereifte Prüfinstanz inkl. Feedback zur Re-evaluation der Richtlinien bezüglich Ausnahmebedarfen umso relevanter. Auch dies fördert Akzeptanz und Praktikabilität.

Da wir uns im Bereich der föderalen IT-Architekturrichtlinien bewegen, möchten wir zudem nochmals besonders hervorheben, dass das Schaffen eines Konsenses bzw. einer partnerschaftlichen Zusammenarbeit und Ausgestaltung zwischen verantwortender und betroffener Stelle stets im Vordergrund ggü. Vorgaben und Reglementierungen stehen sollte. Hier sind Stakeholder- und Kommunikationsmanagement von besonderer Bedeutung bspw. für die Schaffung von Feedbackprozessen zur Berücksichtigung von Erfahrungen der Umsetzungsprojekte.

Bei weiteren Ausgestaltungen sind die unterschiedlichen Ebenen (Bund, Land, Kommune) mit zu berücksichtigen. Eine föderale IT-Architekturrichtlinie betrifft nicht allein die Länder, sondern muss auch deren Kollaboration und Konnektivität zu den anderen Ebenen beachten und fördern. Öffentliche Verwaltung basiert auf und profitiert von der reibungslosen Zusammenarbeit der unterschiedlichen Verwaltungsebenen, was sich auch in der Gestaltung der jeweiligen IT auswirken muss.

G.B - original vom 28.01.2024

Die wiedersprüchlichen Anforderungen zwischen Umsetzung von Lösungen nach Stand der Technik und gesetzlichen Anforderungen, wie bspw. im Registermodernisierungsgesetz, sollten aufgelöst werden.

Leitplanke	Wert (gem. Unterlage vom 13.12.2023)	Bewertung DTAG	Folgen
Transformationsgrad	Disruption priorisieren	sinnvoll	Aufwänden bei Inanspruchnahme von Verwaltungsleistungen (bspw. Glasfaserausbau) würden reduziert. Transformation muss insbesondere durch die Fachlichkeit gewollt und getrieben werden.
Grad der Standardisierung	Übergreifende Standardisierung	Sinnvoll (Tendenz zu einer vollständigen Standardisierung)	Grundsätzlich müssen übergreifende Standards gelten. Hierdurch können Aufwands- und Kostenreduzierung durch (teilweise) Wiederverwendung von anderen Projekten realisiert werden und gleichzeitig individuelle Anforderungen von Organisationen berücksichtigt werden.
Herkunft der Standards	Nutzung internationaler Standards + nationale Standards wo notwendig	sinnvoll	Aufwands- und Kosten können durch Wiederverwendung von internationalen Projekten reduziert werden. Gleichzeitig können notwendige Individualleistungen umgesetzt werden. Die Etablierung von nationalen Standards sollte beschleunigt / optimiert werden.
Einheitlichkeit von Qualität-standards	Bundesweite Qualitäts-standards	sinnvoll	Aufwands- und Kosten können durch Verzicht individueller Qualitätsanforderungen reduziert werden. Zudem schaffen (ggf. höhere) bundeseinheitliche Standards bessere Akzeptanz.
Kooperationsgrad	Einsatz eigener fachübergreifender Module möglich	sinnvoll	Markt für querschnittliche Themen bleibt bestehen. Umstellungsaufwände „aus Prinzip“ werden vermieden.
Vertrauensmechanismen	Zero Trust Ansatz	sinnvoll
Zugang zum Ökosystem	Offen für alle	nicht sinnvoll Aufgrund der Anforderungen des öffentlichen Sektors sollten ausschließlich Marktteilnehmer:innen mit der notwendigen Fachkunde und Leistungsfähigkeit Zugang zum Ökosystem besitzen.	Die Fachkunde / Leistungsfähigkeit wird im Rahmen der Vergabeverfahren bereits in Form der Eignungsprüfung durchgeführt. Zu begrüßen wäre jedoch eine Standardisierung der Eignungsprüfung.
Digitale Souveränität	Alternative Systeme zu aktuell vorhandenen Lösungen		Die Ausprägungen lassen großen Interpretationsspielraum zu und sind aus unserer Sicht missverständlich. Wir verzichten daher auf eine Bewertung der Ausprägung.
Transparenz	Offenlegung des Quellcodes	nicht sinnvoll Bei Individualentwicklungen ist die Ausprägung sinnvoll. Ob allerdings Hersteller von Standardsoftware den Quellcode offenlegen, darf bezweifelt werden.	Fraglich ist, inwieweit die (Standard-) Fachverfahren innerhalb eines Ende-zu-Ende-Prozesses in der OZG-Rahmenarchitektur berücksichtigt sind. Die Ausprägung der Leitplanke muss für alle (Funktions-) Bausteine gleichermaßen gelten.

Art	Relevante Regelung
EU-VO / Gesetz / Verordnung	SDG-VO, Single Digital Gateway VO (EU-VO 2018/1724)
EU-VO / Gesetz / Verordnung	DSGVO, Datenschutzgrundverordnung (EU-VO 2016/679)
EU-VO / Gesetz / Verordnung	eIDAS, Verordnung über elektronische Identifizierung und Vertrauensdienste (EU-VO 910/2014)
EU-VO / Gesetz / Verordnung	BDSG, Bundesdatenschutzgesetz
EU-VO / Gesetz / Verordnung	Datenschutzgesetze der Länder
EU-VO / Gesetz / Verordnung	BSI-Gesetz sowie BSI Kritisverordnung
EU-VO / Gesetz / Verordnung	OZG, Onlinezugangsgesetz
EU-VO / Gesetz / Verordnung	ITSiV-PV, IT Sicherheitsverordnung Portalverbund
EU-VO / Gesetz / Verordnung	EGovG Bund, E-Government Gesetz Bund
EU-VO / Gesetz / Verordnung	E-Government Gesetze der Länder
EU-VO / Gesetz / Verordnung	RegMoG, Registermodernisierungsgesetz
EU-VO / Gesetz / Verordnung	Behindertengleichstellungsgesetze
EU-VO / Gesetz / Verordnung	IT-NetzG, Gesetz über die Verbindung informationstechnischen Netze des Bundes und der Länder
EU-VO / Gesetz / Verordnung	GDNG, Gesetz zur verbesserten Nutzung von Gesundheitsdaten
Beschlüsse und Standards	Beschlüsse von IT-Planungsrat und OZG-AL-Runde (z. B.: IT-Architekturrichtlinie 2021/37, Support- und Betriebsorganisation von EfA-ODs 2023/07, Verfügbarkeiten von IT-Systemen im Portalverbund 2018/40, Responsive Design 2018/40, FitStore und GovDigital Marktplatz 2022/27, Leitlinie Informationssicherheit 2020/05 u.a., Anschlussbedingungen NdB-VN 2020/15, DVC-Strategie 2021/46, DVC-Koordinierungsstelle 2023/18 u.w., DVC-Zielarchitektur 2022/47, DVC-Architekturboard, MeinUK 2020/01 u.a.).
Beschlüsse und Standards	Anwendungen des IT-Planungsrates (115, BFD, DVDV, FINK, FIT Connect, FIT-Store, Föderales Entwicklerportal, FIM, GovData, Governikus, GMM, OSiP, PVOG)
Beschlüsse und Standards	Standards des IT Planungsrats (OSCI, XTA, String-Latin/DIN91379 XDomea, XRechnung, XVergabe, XBau, XPlanung, XDatenfelder, XZuFi, XProzess, DCAT-AP.de)
Beschlüsse und Standards	BSI TR-03160 Servicekonten
Beschlüsse und Standards	BSI TR-03147 Vertrauensniveaubewertung von Verfahren zu Identitätsprüfung natürlicher Personen
Beschlüsse und Standards	BSI TR-03107 elektronische Identitäten und Vertrauensdienste
Beschlüsse und Standards	BSI TR-03172 Portalverbund
Beschlüsse und Standards	BSI Grundschutz
Beschlüsse und Standards	ISO 20000 IT Servicemanagement
Beschlüsse und Standards	ISO 22301 „Betriebliches Kontinuitätsmanagement“
Beschlüsse und Standards	ISO 27001 "Informationssicherheit, Cybersicherheit und Datenschutz - Informationssicherheitsmanagementsysteme - Anforderungen"
Beschlüsse und Standards	EVB-IT, einheitliche Vertragsbedingungen für IT-Leistungen
Beschlüsse und Standards	NOOTS, Technical Design Document
Strategiepapier	Digitalisierungsstrategien von Bund, Ländern und Kommunen
Strategiepapier	Wahl- und Parteiprogramme der Parteien
Strategiepapier	Gartner, Magic Quadrant und Technology Trends
Strategiepapier	Deloitte, Tech Trends
Strategiepapier	Aktuelle Studien und Veröffentlichungen von Wissenschaft, Beratungs- und Consultingunternehmen (z. B. NEGZ „Government as a Platform in Deutschland“)