10. Phase G: Governance

10.1 Festlegung des Transformationsumfangs, Priorisieren der Teilaufgaben

Die Arbeitspakete zur Migration und die Reihenfolge der Umsetzung wurden aus Gründen der Dringlichkeit des Vorhabens bereits vor der Architekturarbeit im Leistungsbeschreibung 2022 festgelegt und begonnen. Die Leistungsbeschreibung hat im Kern einen iterativen Entwicklungsprozess ausgeprägt, der über einen Zeitraum von 17 Monaten bewältigt werden sollte. Darin wurden 6 Meilensteine festgeschrieben. Zu den ersten zwei Phasen, also der Gültigkeit der Leistungsbeschreibung 2022, wurden Arbeitspakete nebst Abnahmekriterien ausformuliert.

Zeitgleich mit der Fertigstellung der Architekturvision und dem Start des Reviews zu den Phasen B-D des Architekturkonzepts wurde eine Fortschreibung des Leitungsscheins für das Jahr 2023 erzeugt. Darin sind zahlreiche Erkenntnisse eingeflossen, die die Architekturarbeit neu aufgedeckt hat. Die übergeordneten Ziele gemäß Leistungsbeschreibung 2022 sind vollumfänglich in die Leistungsbeschreibung 2023 eingeflossen, die Arbeitspakete wurden in den Details weitgehend überarbeitet bzw. an neue Erkenntnisse angepasst. Die Arbeitspakete pro Meilenstein reflektieren die Priorisierung der Teilaufgaben aus Sicht der fachlich zuständigen Leistungserbringer.

10.2 Benötigte Ressourcen und Skills für die Transformation

Die Transformation der Informationssystemarchitektur wird durch die Hersteller der Modulkandidaten erbracht. Dort sind nach Einschätzung des Auftraggebers die erforderlichen Skills in Bestbesetzung vorhanden. Die Verfügbarkeit der erforderlichen Ressourcen bestätigen die Hersteller der Modulkandidaten mit der Auftragsannahme.

Die Transformation der Infrastrukturarchitektur kommt einer Erstinstallation einer noch nicht abschließend ausformulierten Container-Plattform gleich. Die übergeordnete Technik Containerisierung wird auf der Seite des geplanten Betreibers Dataport bereits seit Jahren als Basisdienst angeboten. Aufgrund dieses Sachverhalts ist davon auszugehen, dass Dataport den Skill-Bedarf mindestens erfüllt. Erforderliche technische Ressourcen kann Dataport wahlweise aus eigenen Beständen abdecken oder aus den bereits aufgebauten Cloud-Ökosystem seitens Dritter beziehen.

Der Ablauf der Transformation wird von einer professionellen Projektsteuerung begleitet. Diese greift mehrschichtig, und zwar auf der Seite von Dataport als Generalunternehmer und auf den Seiten der Software-Lieferanten. Diese Aufgabe nehmen Mitarbeiter von Univention wahr.

Des Weiteren beobachten die übergreifenden Gremien Produktboards (Produktstrategie-/Produktentwicklungsboard) und Architekturboard die Transformation und treten für den Fall etwa erforderlicher Anpassungen im Vorgehen beratend auf. Derartige Fälle werden als Änderungsvorhaben gehandelt und sind einem darauf zugeschnittenen formalen Prozess unterworfen. Mit Erreichen jedes Zieltermins (Meilensteins) werden die Abnahmekriterien gemäß Leistungsbeschreibung geprüft. Nutzbare Teil- bzw. Endergebnisse prüft und bewertet ein User Experience Board. Dort aufgedeckte Optimierungspotenziale fließen direkt in die weitere Ausgestaltung der Transformation ein.

10.3 Steuerung der Entwicklungen zur Lösungsbereitstellung

10.3.1 Transformation der Informationssystemarchitektur

Die vollständigen Erkenntnisse zum Umfang des Transformationsbedarfs hat das Architekturkonzept erst nach der Inkraftsetzung der Leistungsbeschreibung 2023 zusammengetragen. Die Roadmap gemäß Phase E hat daher in der Leistungsbeschreibung 2023 keine Berücksichtigung finden können. Dennoch hat die Leistungsbeschreibung 2023 die relevanten Handlungsfelder

• Identifikation von Modulkandidaten
• Vervollständigen des Funktionsvorrats gemäß Funktionsmodell
• Ausrichtung auf einheitliches Bedienkonzept
• Anpassung an Anforderungen zur barrierefreien Bedienung
• Anpassungen für medienbruchfreie Interoperabilität
• Containerisierung
• Einzug von Sicherheitsmaßnahmen mit dem Ziel der Konformität zu C5 und BSI-IT-Grundschutz

vorausschauend weitgehend adressiert und darauf zugeschnittene Arbeitspakete nebst Abnahmekriterien ausgewiesen.

Eine Anmerkung zur Nomenklatur: Die Arbeitspakete sind nummeriert, aber nicht fortlaufend. Jedes Arbeitspaket ist kodiert mit einleitendem D, gefolgt vom Liefertermin/Kennung des Meilensteins, einem Kürzel zur bearbeitenden Organisation, der Nummer zum Arbeitspaket und einer Kurzbeschreibung des Auftrags. Als Feldtrenner wird der Bindestrich verwendet.

10.3.1.1 Identifikation von Modulkandidaten

Die Aufgabenstellung wurde im Arbeitspaket

• D-05-DP-103-Phasen E-F (Marktanalyse, Produktbewertung, Produktauswahl mit OS-Ökosystem)

für einen Teil der Produktklassen umgesetzt, die das Leistungsspektrum des SouvAP abbilden sollen. Tatsächlich wurden aus Gründen der Dringlichkeit bereits zum Projektbeginn Werkzeuge festgelegt, die als aussichtsreich betreffend des bekannten Funktionsspektrums eingestuft wurden. Die Marktanalysen haben bestätigt, dass die Vorauswahl jeweils Modulkandidaten mit hohem Abdeckungsgrad des minimal geforderten Funktionsvorrats gemäß Phase C Funktionsmodell identifiziert hat.

10.3.1.2 Vervollständigen des Funktionsvorrats gemäß Funktionsmodell

In dieses Handlungsfeld wurde der überwiegende Teil der Einzelaufgaben gemäß Leistungsbeschreibung 2023 überführt. Eine Einzelaufstellung der zahlreichen Arbeitspakete wird hier nicht geleistet. Der inhaltliche Schwerpunkt konzentrierte sich auf die Hersteller bzw. die Produkte Univention, Collabora, Element, NextCloud, Nordeck, OpenProject, OpenXchange und XWiki. Einige Arbeitspakete adressieren funktionelle Erweiterungen, die den Funktionsvorrat um wünschenswerte Leistungsmerkmale erweitern. Ein Beispiel dafür bildet

• D-04-OX-139-Mail senden (kurzzeitig) rückgängig machen.

In diese Richtung zielt auch

• D-04-OX-121-E-Mail: Exportiere E-Mails und Anhänge in PDF/A,

das den Mail-Transport-Agent OpenXchange befähigen soll, komplette Email-Inhalte einschließlich enthaltener Anhänge im portablen Dokumentenformat PDF/A zu exportieren. Ein anderes Beispiel bildet

• D-04-OP-546_iCal-API,

das die Integration des iCal-Protokolls in OpenProject beauftragt.

4.1.3 Ausrichtung auf einheitliches Bedienkonzept Dieses Handlungsfeld hat im Zuge der Aufgabenfindung zur Leistungsbeschreibung 2023 keine explizite Berücksichtigung erfahren. Lediglich der Auftrag

• D-04-ND-145-Einheitliches Look and Feel

zu den Erweiterungen zum Produkt Element des Herstellers Nordeck verfolgt das Ziel, die Farben und die Schriftart an das Erscheinungsbild von NextCloud und OpenXchange anzupassen. Möglicherweise wurde in der Redaktion zur Leistungsbeschreibung 2023 davon ausgegangen, dass die zuletzt genannten zwei Produkte den Standard setzen und der Anpassungsbedarf zum Thema deshalb eher vernachlässigbar ausfällt oder dies im Zuge der Umsetzung von Barrierefreiheit als Teilprojekt erledigt wird.

10.3.1.3 Anpassung an Anforderungen zur barrierefreien Bedienung

Das Handlungsfeld wurde faktisch auf alle erkannten Modulkandidaten angewandt, die mit den Anwendern über eine Präsentationsschicht im Dialog operieren. Die Einzelaufträge lauten

• D-03-CO-104-Accessibility
• D-03-NC-109-Accessibility-Teil-2
• D-03-XW-111-XWiki-Accessibility
• D-03-OX-152-App Suite 8 Accessibiltiy Improvements 1
• D-04-OX-153-App Suite 8 Accessibiltiy Improvements 2
• D-04-ND-256-Barrierefreiheit-Jitsi
• D-04-ND-306-Barrierefreiheit in Element dOZ 2.0
• D-04_OP-551_Barrierefreiheit-UI-Optimierungen
• D-05-XW-112-XWiki-Accessibility2
• D-05-ND-146-Barrierefreiheit in Element dOZ 2.0
• D-05-OX-154-App Suite 8 Accessibiltiy Improvements 3
• D-06-DP-108-Barrierefreiheit-Prüfung Dataport
• D-06-DP-109-Barrierefreiheit-Sonderprüfungen Dataport
• D-06-XW-113-XWiki-Accessibility3
• D-06-DP-126-Barrierefreiheit-Abnahme Berichte
• D-06-DP-127-Barrierefreiheit-Tracking
• D-06-XW-142-CryptPad-DiagramEditorAccessibility
• D-06-ND-307-Barrierefreiheit in Element dOZ 2.0

Die Auflistung dürfte unmissverständlich aufzeigen, dass die am Projekt beteiligten Hersteller die erforderliche Transformation frühzeitig angegangen sind und diese auch überwiegend als mittelfristiges Vorhaben eingestuft wurde. Außerdem wurde ein zweistufiger Abnahmeprozess instanziiert, der einerseits die Umsetzung bis zum Meilenstein 6 steuert (Abnahme-Tracking), andererseits mit einem standardisierten Verwahren die Ergebnisse nach einheitlichen Kriterien bewertet.

10.3.1.4 Anpassungen für medienbruchfreie Interoperabilität

Die Interoperabilität adressiert zwei verschiedene Anwendungsbereiche: - Interoperabilität zwischen SouvAP-Modulen und - Interoperabilität von SouvAP-Modulen mit durch Dritte erzeugten Datenformaten.

Eine Bewertung der zu diesem Thema platzierten Arbeitspakete liefert im Ergebnis, dass der Einzelauftrag

• D-05-DP-112-InteropLayer-Datenarchitektur

die Interoperabilität zwischen SouvAP-Modulen adressiert und dass die Arbeitspakete

• D-03-CO-100-Writer-interoperability
• D-03-CO-101-Calc-Interoperability
• D-04-CO-200-Writer-interoperability
• D-04-CO-201-Calc-Interoperability
• D-04-CO-203-Impress-Interoperability
• D-05-CO-301-Calc-Interoperability
• D-06-CO-400-Writer-interoperability

von Collabora eine Art Bindeglieder für verlustfreien Im- und Export von Dokumenten anderer Produkte für den identischen Anwendungsbereich liefern soll. Entsprechendes motivieren die Erklärungen zu den Arbeitspaketen in der Weise, dass die Maßnahmen auf eine Interoperabilität mit bereits vorhanden BMI-Dokumenten fokussieren, die z.B. im Format DOCX erzeugt wurden.

Zwei weitere Arbeitspakete

• D-04-OP-548_Integration-Nextcloud-OpenProject und
• D-03-XW-131-CryptPad-NextCloud

zielen auf die Integration der vorhandenen API zur Dateiablage NextCloud in die Produkte OpenProject bzw. XWiki. OpenProject will die Interoperabilität mit der Dateiablage NextCloud verbessern derart, dass z.B. projektspezifische Ablageorte und darauf anzuwendende Zugriffsrechte aus OpenProjekt heraus gesteuert werden können. Cryptpad wiederum will einen ereignisgesteuerten Nachrichtenaustausch mit NextCloud für den Fall auftretender Zustandsänderungen von in Arbeit befindlichen Dokumenten auf der Seite von NextCloud realisieren.

4.1.6 Containerisierung Die Containerisierung der Modulkandidaten wurde bereits im Frühstadium des Projekts adressiert. Daraufhin getroffene Aufwandsabschätzungen haben für die Modulkandidaten NextCloud, OpenXchange und die für das Gesamtkonzept relevanten Bausteine Portal und IAM einen Migrationsbedarf über mehrere Meilensteine angekündigt. Die darauf zugeschnittenen Arbeitspakete gemäß Leistungsbeschreibung 2023 sind

• D-03-UV-106-containerization of UCS IAM
• D-04-UV-107-containerization of UCS IAM
• D-05-UV-108-containerization of UCS IAM
• D-04-NC-134-Nextcloud-Enterprise-Container
• D-05-NC-135-Nextcloud-Enterprise-Container
• D-06-NC-133-Nextcloud-Enterprise-Container
• D-03-OX-115-MS1, MS2 Erweiterungen auf Container-Technologie umbauen
• D-04-OX-127-Containerisierung OX App Suite - erstes "on prem" Release v8
• D-05-OX-111-Containerisierung OX App Suite - erstes "on prem" Release v8
• D-03-UV-165_containerization_of_the_portal_according_to_the_currently_available_DVS_standards
• D-04-UV-166_containerization_of_the_portal_according_to_the_currently_available_DVS_standards

10.3.1.5 Sicherheitsmaßnahmen

Das Handlungsfeld enthält Aufgaben, die Sicherheitsmaßnahmen an der Applikationsschicht einziehen und Aufgaben, die die Sicherheit der SouvAP-Module betreffend BSI-IT-Grundschutz und Datenschutz prüfen und bewerten. Erstere wurden in der Leistungsbeschreibung 2023 wie folgt eingebracht:

• D-03-ND-101-Whiteboard SiKo Konformität
• D-04-ND-264-Erfüllung-von-DSGVO
• D-04-OX-125-Schutzfunktionen beim Versand
• D-06-XW-145-CryptPad-Security
• D-03-XW-114-XWiki-Security
• D-03-XW-144-XWiki-Security4
• D-04-XW-115-XWiki-Security2
• D-05-XW-143-XWiki-Security3
• D-06_OP-550_Sicherheitsprüfung

Die Umsetzung fällt in den Verantwortungsbereich der am Projekt beteiligten Software-Lieferanten (Hersteller). Der verbleibende Aufgabenkatalog wird von Dataport bearbeitet. Über die gesamte Laufzeit der Leistungsbeschreibung 2023 begleitet Dataport die Umsetzung von Sicherheit über alle Module zum SouvAP. Die Aufgabenpakete laut Leistungsbeschreibung 2023 sind:

• D-03-DP-100-SIKO_IT-GS-Check_übergreifend
• D-03-DP-101-SIKO_IT-GS-Check
• D-04-DP-102-SIKO_IT-GS-Check
• D-05-DP-103-SIKO_IT-GS-Check
• D-06-DP-104-SIKO_IT-GS-Check
• D-03-DP-200-Datenschutz
• D-04-DP-200-Datenschutz
• D-05-DP-200-Datenschutz
• D-06-DP-200-Datenschutz

10.3.2 Transformation der Infrastrukturarchitektur

Das Zielbild sieht einen Betrieb des SouvAP in einer nach BSI IT-Grundschutz zertifizierten technischen Infrastruktur vor, die die Anforderungen der DVS umsetzt. Diesbezügliche Entwicklungsarbeiten treibt das BMI seit Juli 2023 voran1. Gemäß erstem Bericht zum Projekt2 wird erwartet, dass Ende 2024 "ein attraktives Portfolio aus IaaS, PaaS, SaaS und weiteren Services der DVC definiert und aufgebaut" ist.

Im Projekt SouvAP wurden alle während des Projekts öffentlich verfügbaren Dokumente zur DVS aufmerksam analysiert. Im Ergebnis entstand eine granulare Bewertung erforderlicher Sicherheitsmaßnahmen für Aufbau und Betrieb eines Kubernetes Clusters entsprechend den DVS-Vorgaben und ergänzend ein Katalog an sinnvollen Schutzmaßnahmen bis in die containerisierten Applikationen hinein.

Das Ergebnis entstand aus akribischer Bewertung der laut Kubernetes Community bekannten Angriffsflächen nebst empfohlener Sicherheitsmaßnahmen, der Docker Best Practices, der Ausarbeitung NIST SP 800-190, der Betrachtungen von C5 und BSI IT-Grundschutz und weiterer, in einschlägigen Foren veröffentlichten Sicherheitsdiskussionen zu Kubernetes-Implementierungen. Es sollte nachvollziehbar sein, dass die Gesamtheit der dabei erkannten Problemquellen und die empfohlenen Handlungsstränge zur Gegenwehr weit über die aktuell im C5:2020 skizzierten Kriterien und auch die spezifischen Bausteinanforderungen des BSI IT-Grundschutz-Kompendiums Ed. 2023 hinaus gehen.

Für die Bereitstellung des SouvAP wurde eine Entwicklungsplattform aufgebaut. Diese wurde als Kubernetes-as-a-Service KaaS von einem Drittanbieter vorbereitet und wird seitens der Entwickler der SouvAP-Module als PaaS genutzt. Oberhalb davon wurde eine erste Form einer CI/CD-Pipeline realisiert, die im Endausbau das automatisierte Ausrollen von SouvAP-Artefakten entsprechend der Vorgaben der DVS leisten soll.

Ab Ende des Projekts SouvAP ist eine Erprobungsphase zum SouvAP geplant. Für diesen Zeitraum ist keine Produktivsetzung geplant. Aus diesem Grund soll die aktuell für die Bereitstellung des SouvAP aufgebaute Entwicklungsplattform durch eine weitere Instanz „Referenzumgebung“ für die SouvAP-Erprobung ergänzt werden.*

10.4 Steuerung der Architektur-Umsetzung

Die Transformation wird fortlaufend auf den Seiten von Dataport und den Herstellern über die Arbeitspakete

• D-04-DP-199-Projektmanagement technische Entwicklung
• D-05-DP-199-Projektmanagement technische Entwicklung
• D-06-DP-199-Projektmanagement technische Entwicklung
• D-03-UV-206-Hersteller und Projektbetreuung
• D-04-UV-207-Hersteller und Projektbetreuung
• D-05-UV-208-Hersteller und Projektbetreuung
• D-06-UV-209-Hersteller und Projektbetreuung

gesteuert. Außerdem erhält die Steuerung des Gesamtprojekts operative Unterstützung durch die Querschnittsgremien

• Produktboards (Produktstrategie-/Produktentwicklungsboard)
• Architekturboard
• User Experience Board

TOGAF empfiehlt, den Transformationsprozess wie folgt zu steuern:

• Fortlaufende Überprüfung der Steuerungsprozesse für jeden Baustein, Überprüfung der Zwischenergebnisse auf Architektur-Konformität,
• Durchführung von Compliance-Überprüfungen nach der Transformation und
• Abschluss der Umsetzung von Bereitstellungsprojekten.

Der erste Schritt wurde unmittelbar nach der ersten Abgrenzung des Transformationsbedarfs eingeleitet (siehe Architekturkonzept Phase E). Es wurde zunächst ein gemeinsamer Arbeitstermin mit Vertretern aller Teilprojekte und Gremien durchgeführt, in dem die relevanten Handlungsfelder mit grober Detailtiefe aufgezeigt wurden.

Darauf basierend wurde ein Fragebogen entwickelt, zu dem die am Projekt beteiligten Hersteller eine Selbsteinschätzung liefern sollten, in der sie ihren subjektiv empfundenen Umsetzungsgrad bewerten sollten. Auf Basis der Rückmeldungen wurden Priorisierungen gesetzt und es wurden fortlaufend die jeweils erreichten Umsetzungsgrade nach Selbsteinschätzung abgefragt. In transformationsbegleitenden Abstimmungsterminen standen Architektur und Teilprojektleitungen im zweiwöchigen Rhythmus im direkten Austausch mit den transformationsumsetzenden Leistungseinheiten.

10.4.1 Der Umsetzungssteuerung unterworfene Bausteine

Die zyklische Überwachung der Umsetzung konzentrierte sich auf die Hersteller bzw. Produkte

• Collabora,
• CryptPad,
• Element,
• NextCloud,
• Nordeck,
• OpenProject,
• OX AppSuite,
• Univention und
• Xwiki.

10.4.2 In der Umsetzungssteuerung beobachtete Aspekte

Die zu beobachtenden Aspekte wurden aus den transformationsrelevanten Handlungsfeldern und den darin betrachteten Einzelmaßnahmen entnommen (siehe Phase E). Die Aspekte wurde gruppiert zu Dokumentation, Softwareentwicklung, Aufbau und Betrieb, Containerisierung, Bereitstellung der Artefakte und Sicherheit (BSI IT-Grundschutz, C5, NIST SP 800-190).

Die Tabelle benennt die einzelnen Kategorien, die darin gruppierten Aspekte und die Verbindlichkeitsgrade, mit der jeder Aspekt erreicht werden soll/muss. Der Zielerreichungsgrad differiert zum Zeitpunkt dieser Ausarbeitung noch je nach Modul und Kategorie gegenüber dem Idealbild.

10.5 Implementierung des neuen Geschäfts- und IT-Betriebs

Der neue Geschäfts- und IT-Betrieb soll zunächst als Probebetrieb aufgesetzt und unterhalten werden. Dazu wurden im Projekt je eine Entwicklungs- und eine Referenz-Plattform aufgesetzt. Die technische Basis liefert ein etablierter externer, auf Cloud- und Kubernetes-Services spezialisierter Dienstleister. Dort wurden je ein Kubernetes-as-a-Service für die Entwicklungs- und die Referenz-Umgebung abonniert. Auf diesen Plattformen wurden anschließend die im Projekt erzeugten Artefakte im jeweiligen Entwicklungs- bzw. Release-Stand ausgerollt. Mit dem Deployment wurden faktisch erste Betriebsprozesse evaluiert. Diese Prozesse wurden inzwischen in einer CI/CD-Pipeline verankert und sind somit vollständig automatisiert nutzbar.

Der Tagesbetrieb ist aufgrund eher geringer Anzahl parallel aktiver Anwender während des Projektverlaufs noch vorsichtig als „vorbereitet“ einzustufen. Vorliegende Erfahrungen mit den bisher durchgeführten Evaluierungen durch das User Experience Board lassen aber vermuten, dass der Tagesbetrieb mit dem erreichten Projektergebnis mindestens als beherrschbar einzuschätzen ist. Genaueres muss der Probebetrieb mit wachsender Anwenderzahl aufdecken. Dort ist die Belastbarkeit pro Kubernetes-Cluster auszuloten und es sind Kenngrößen zu finden, die den Ressourcenbedarf für typische Anwenderklassen (z.B. Standard-User und Power-User) aufzeigen. Anhand dieser Daten sind anschließend technische und personelle Mengengerüste für die Bewirtschaftung eines oder mehrerer Kubernetes-Cluster für den Wirkbetrieb mit vorgegebener Anwenderzahl festzulegen.

Der Wirkbetrieb soll die üblichen Rahmenbedingen eines sicheren IT-Betriebs nach Best Practices umsetzen. Die dafür einzusetzende Rahmenwerke BSI IT-Grundschutz und IT Information Library wurden bereits in Kapitel 3 zum Preliminary dieses Konzepts favorisiert. Die zum Projekt unter der Auftragskennung D-06-DP-102 zu erzeugende Betriebsdokumentation soll die inhaltlichen Empfehlungen dieser Rahmenwerke verdichten und damit die Grundlage für die Betriebsprozesse für ordnungsgemäßen und sicheren Betrieb des SouvAP legen. Die Prozesse zu Update/Upgrade von Modulen sowie Backup/Restore von Nutzdaten wurden jedoch innerhalb des Projekts nicht adressiert. Diese sind noch vor der Produktivsetzung zu entwickeln.

10.6 Abschluss der Implementierung, Bewertung der Ergebnisse

Das Architekturprojekt ist formell über die Leistungsbeschreibungen 2022 und 2023 definiert und es wurde auf eine Terminierung zum Ende 2023 ausgelegt. Im Zuge der Umsetzung wurden einige Arbeitspakete in solche mit anderen Zielen transformiert und einige wurden gestrichen. Die Änderungen an den Arbeitspaketen gemäß der Leistungsbeschreibungen haben aus Sicht der Architektur keinen Einfluss auf das Ziel der Transformation gemäß den ursächlichen Inhalten der Leistungsbeschreibungen.

Des Weiteren wurden im Zuge der Transformation speziell betreffend der Containerisierung einige zusätzliche Herausforderungen aufgedeckt, die Verzögerungen begründeten und somit zu Verschiebungen der Zieltermine zu den späteren Meilensteinterminen führten.

Die hier zusammengestellte Bewertung der Ergebnisse wurde vor Ablauf der Lieferfrist erzeugt. Sie will dem Abschlussbericht nicht vorweggreifen und diesen insbesondere nicht ersetzen. Stattdessen übernimmt sie den Versuch, die Ergebnisse aus Sicht des Architekturkonzepts zu bewerten und dies zunächst gegen die fachlichen Zielvorgaben zu spiegeln. Anschließend wird ein Ausblick gegeben, wie die neue Architektur bezüglich des visionär geschätzten Geschäftsnutzens bewertet werden kann. An dieser Stelle sei betont, dass dazu eine Feldstudie mit einer Laufzeit von mindestens 6 Monaten eingeplant werden sollte.

10.6.1 Bewertung der Ergebnisse aus fachlicher Sicht

Gemäß Kapitel 4.1 muss die Transformation in Summe sieben Handlungsfelder ausgestalten und diese sind teils auf Seiten der Informationssystemarchitektur, teils auf Seiten der Infrastrukturarchitektur und teils auf beiden Seiten zu bewältigen. Letztes betrifft maßgeblich die Handlungsfelder Containerisierung und Einzug von Sicherheitsmaßnahmen mit dem Ziel der Konformität zu C5 und BSI-IT-Grundschutz mit der zusätzlichen Herausforderung, dass diesbezügliche Arbeitspaketen in einigen Fällen koordiniert und abgestimmt zwischen den genannten zwei Architekturdomänen erfolgen muss.

• Identifikation von Modulkandidaten: Dies wurde bereits vor der Erstellung des Architekturkonzepts durchgeführt. Die im Laufe des Projekts durchgeführte Marktanalyse (siehe Anhang A zu Phase F) hat bestätigt, dass die Vorauswahl passende und außerdem die zum Zeitpunkt des Projekts am besten geeigneten Modulkandidaten selektiert hat.
• Vervollständigen des Funktionsvorrats gemäß Funktionsmodell: Die Vorauswahl hat bereits den Funktionsbedarf gemäß Architekturkonzept vollständig abgedeckt. Im Zuge der Transformation wurden dennoch einige Erweiterungen am Funktionsvorrat vorgenommen. Diese sollten einerseits auf einige der nachstehend genannten Handlungsfelder einzahlen. Zusätzlich wurden funktionelle Erweiterungen eingepflegt, die aus Sicht der Hersteller den Nutzen aus Anwendersicht steigern sollen.
• Ausrichtung auf einheitliches Bedienkonzept: Eine heuristische Analyse der Ergebnisse zum Meilenstein 5 hat Inkonsistenzen in den jeweiligen Umsetzungsgraden der einzelnen Modulkandidaten aufgedeckt. Diese wurden in die Bereiche Allgemeines, Kommunikation und Organisation, Produktivität, Management und Zusammenarbeit gruppiert. Die Analyse hat abschließend in einem Phasenmodell Arbeitsschritte empfohlen, die eine systematische Wandlung hin zu einem Idealbild führen sollen. Die hier getroffene Einschätzung ist als Zwischenstand einzustufen.
• Anpassung an Anforderungen zur barrierefreien Bedienung: Der Umsetzungsgrad der zugehörigen Arbeitspakete wurde ebenfalls etwa ab Erreichen von Meilenstein 5 geprüft, und zwar auf der Grundlage des Landesbehindertengleichstellungsgesetzes (LBGG) sowie der Landesverordnung über den barrierefreien Zugang zu Websites und mobilen Anwendungen öffentlicher Stellen (BfWebV SH). Die Prüfergebnisse kurz vor Erreichen des Meilensteins 6 weisen Abweichungen vom Idealbild aus. Diese Ergebnisse geben wertvolle Hinweise auf Bereiche, in denen Nachbesserungen erforderlich sind. Es ist davon auszugehen, dass dies auch bis zum Projektende mit Priorität bearbeitet wird. Das tatsächlich erreichte Endergebnis ist nach Abschluss aller Transformationsaktivitäten erneut zu bewerten.
• Anpassungen für medienbruchfreie Interoperabilität: Das Architekturkonzept hat die Anforderung aus den Zielsetzungen der FITKO abgeleitet, die die medienbruchfreie Interoperabilität als eGovernment-Standard beansprucht und damit sowohl den medienbruchfreien Datenaustausch zwischen Verwaltung und Bürgern sowie Wirtschaft als auch den medienbruchfreien Datenaustausch innerhalb der (ebenen-übergreifenden) digitalen Verwaltungsprozesse adressiert. Die Umsetzung stand jedoch nicht im Fokus der Budgetvergabe 2023. Es ist noch in der Praxis zu prüfen, ob der medienbruchfreie Datenaustausch im SouvAP zwischen allen dort enthaltenen Modulen gelingt oder ob diesbezügliche Nacharbeiten erforderlich sind.
• Containerisierung (Informationssystemarchitektur): Die transformationsgestaltenden Hersteller haben ihre Modulkandidaten auf eine Betriebsfähigkeit in einer Container-Laufzeitumgebung transformiert. Die DVS-Vorgaben, nämlich die Zerlegung der Applikationen in Mikroservices zu den Aufgabenstellungen Datenzugriffsschicht, Datenverarbeitungsschicht und Präsentationsschicht, wurden im Projektverlauf nicht erreicht. Code-Analysen haben ergeben, dass die Umsetzung dieser Anforderung erhebliche Änderungen an den Modulkandidaten erfordert und dies vermutlich nur über einen weitgehenden Neuaufbau der jeweiligen Module mit Ausrichtung auf Container-native Anwendungsentwicklung möglich ist. Bei der Containerisierung wurden daher schwerpunktmäßig die Docker Best Practices und die Empfehlungen von NIST SP 800-190 und BSI-IT-Grundschutz APP 1.6 genutzt (siehe Kapitel 5.2 Abschnitt Containerisierung).
• Container-Infrastruktur: Es war geplant, das Infrastruktur-Fundament für den SouvAP an die erwarteten Umsetzungshinweise für eine DVS-Implementierung anzulehnen. Aufgrund zahlreicher Erkenntnisse aus zwei DVS-PoCs1,2 und dem Umstand, dass die DVS-Umsetzung auf 2024 verschoben worden ist3, wurde die DVS-konforme Containerisierung der SouvAP-Infrastruktur verworfen. Die Basis für die Entwicklungs- und die Referenzumgebung zum SouvAP wurde bei einem Partnerunternehmen als Kubernetes-as-a-Service (Managed Kubernetes) angemietet. Die so erzeugten Container-Infrastrukturen werden bereits genutzt. Die SouvAP-Module sind betriebsbereit gestellt und stehen für den Probebetrieb zur Verfügung.
• Einzug von Sicherheitsmaßnahmen mit dem Ziel der Konformität zu C5 und BSI-IT-Grundschutz: Der Betreiber des angemieteten Managed Kubernetes kann mit Stand November 2023 sowohl die C5-Testierung als auch die IT-Grundschutz-Zertifizierung des BSI nachweisen. Eine Schwerpunktprüfung SouvAP erhält Stand jetzt jedoch keine IT-Grundschutz Zertifizierung respektive kann nicht IT-Grundschutz konform betrieben werden.

10.6.2 Bewertung der Ergebnisse aus der Perspektive „Geschäftsnutzen“

In Phase A zum Architekturkonzept wurden insgesamt 11 Geschäftsziele herausgearbeitet, die aus dort ebenfalls aufgezählten Treibern und Rahmenbedingungen verdichtet wurden. Diesbezüglich wurden Fähigkeiten geschätzt die einerseits den Ist-Stand und andererseits das erwartete Handlungsvermögen nach der Transformation quantifizieren.

10.6.2.1 Maximierung des Geschäftsnutzens

Es wurde geschätzt, dass die Transformation eine maximale Wirkkraft auf die Geschäftsziele

• Sicherstellung der Digitalen Souveränität und
• Konformität zu den Vorgaben zu Geheim- und Datenschutz

entfalten kann.

Der erste Punkt, Sicherstellung der Digitalen Souveränität, kann aus Sicht der Architektur nach der Transformation einen zumindest annähernd maximalen Wert beanspruchen. Dies wird damit begründet, dass der SouvAP im Ergebnis Alternativen zu bisher vorrangig genutzten Werkzeugen für die Unterstützung wesentlicher täglich anfallender Geschäftsprozesse enthält. Mit der Marktanalyse gemäß Anhang A zu Phase F wurde sogar aufgezeigt, dass eine Wechselfähigkeit auch innerhalb der aktuell favorisierten Module möglich ist. Mit Blick auf Zukunftsfähigkeit und Nachhaltigkeit wäre allerdings zu fordern, dass der SouvAP innerhalb der Öffentlichen Verwaltung auch konsequent eingezogen wird und seine Existenz nicht als Druckmittel gegenüber den Herstellern der etablierten Werkzeuge benutzt wird mit dem Ziel, über deutliche Rabatte zu verhandeln.

Der zweite Punkt, Konformität zu den Vorgaben zu Geheim- und Datenschutz, wurde konzeptionell tief beleuchtet. Das Ergebnis der ersten Iteration des Architekturvorhabens sollte aber nur eine Erprobung vorbereiten und noch nicht alle Sicherheitsaspekte für einen Wirkbetrieb umsetzen. Daher wurde die Konformität zu Geheimschutz als Nebenziel festgehalten, das während der Transformation zwar Berücksichtigung findet, aber nicht ausdrücklich Gegenstand des Projektziels ist. Die Umsetzung der Konformität zu Geheimschutz ist daher in einer Folgeiteration abzubilden. Diesbezügliche Betrachtungen und ein Ausloten erforderlicher Maßnahmen wurden etwa ab der Mitte des Projektverlaufs durch Einbindung des BSI in die Architekturarbeit angestrengt.

10.6.2.2 (Moderate) Steigerung des Geschäftsnutzens

Zu den sieben Geschäftszielen

• Steigerung des Nutzens für Bürger, Unternehmen, Verwaltung,
• Maximieren der Effizienz der Geschäftstätigkeiten der ÖV,
• Ausbau der Leistungsfähigkeit der ÖV,
• Gewährleistung der Informationssicherheit,
• Berücksichtigung von Vorgaben zu Transparenz und gesellschaftliche Teilhabe,
• Ausrichtung auf Zukunftsfähigkeit und
• Ausrichtung auf Nachhaltigkeit

wurden Verbesserungen in den Fähigkeiten der Öffentlichen Verwaltung geschätzt, diese erreichen zu können. Eine quantitative Bewertung dieser Versprechen erfordert aus Sicht der Architektur eine zyklische und kontinuierliche Bewertung der Einzelaspekte während des Probebetriebs und darüber hinaus während des Wirkbetriebs.

10.6.2.3 (Geringe) Reduktion des Geschäftsnutzens

Des Weiteren wurde geschätzt, dass die Transformation zu den zwei Geschäftszielen

• Maximieren der Wirtschaftlichkeit der Geschäftstätigkeiten der ÖV und
• Maximieren von Kundenorientierung/Kundenzufriedenheit

die Geschäftsfähigkeiten des verwalterischen Handelns in der Frühphase des Wirkbetriebs negativ beeinflussen kann.

Diesen Auswirkungen sollten professionell aufbereitete Schulungsmaterialien und Schulungsoffensiven abfedern. Das Architekturkonzept hat einen darauf zugeschnittenen Maßnahmenkatalog entwickelt (siehe Phase E Kapitel 4.1.2). Seine Umsetzung wurde im Zuge der Transformation überwacht. Ob und inwieweit die angestrengten Maßnahmen die erwartete negative Auswirkung in der Umstellungsphase entfalten oder ob die Maßnahmen sogar die Vermutungen widerlegen können, ist über Zufriedenheitsanalysen zu erörtern, die begleitend zum Probebetrieb durchzuführen sind.

10.6.3 Bewertung der Ergebnisse aus der Perspektive „OS-Ökosystem“

Die Software-Lieferanten der Module zum Souveränen Arbeitsplatz haben ausgehend von den Arbeitspaketen gemäß der Leistungsbeschreibungen bis hin zum konkreten Zielbild aus diesem Architekturkonzept ein Open-Source-Produktbündel geschaffen, das die Grundlage für die Unterstützung täglich anfallender Verwaltungsarbeiten bilden soll. Aufgrund des Bekenntnisses zu einer Nutzung einheitlicher Standards ist es gelungen, historisch bedingt voneinander isoliert konzipierte und realisierte Software auf das übergreifende Ziel „DVS-konform“ hin auszurichten.

Bisher ist die Ausrichtung „vollständig containerisiert“ vorwiegend für Open-Source-Einzelprodukte umgesetzt. Diese Anpassungen sind typischerweise nicht Bestandteil der kommerziell gepflegten OS-Distributionen. Entsprechend unterliegen die containerisierten Ausgliederungen auch nicht einer vertraglich zugesicherten Wartung durch einen Distributor im Rahmen seiner Subskriptionsverträge.

Daraus resultierende Dilemma auf der Seite der Nutzer besteht nun im Bedarf an Softwarepflege und -weiterentwicklung; spätestens, wenn es um professionellen Einsatz des SouvAP geht. Auf Seite der Software-Lieferanten besteht umgekehrt Bedarf an angemessener Vergütung für derartige Aktivitäten. Damit das zu akzeptablen Konditionen gelingt, müssten die Anpassungen für die Containerisierung zunächst fester Bestandteil des Upstream-Produkts werden. Ob sich das distributionsübergreifend etabliert, steht derzeit noch in den Sternen.

Der primäre Nutzen der Architekturarbeit besteht für die Teilnehmer des OS-Ökosystems vermutlich zunächst erschöpfend in einer anschubfinanzierten Portierung ausgewählter Module hin zur DVS-Konformität. Daraus lässt sich nicht ableiten, dass dies ihre wirtschaftliche Basis stabilisiert oder verbessert hätte. Es kommt also auf ein gegenseitiges Miteinander an, um dieser Anschubfinanzierung langfristig einen Nachhaltigkeitsfaktor zuordnen zu können.