9. Phase F: Integrationsplan

9.1 Unternehmensstrategien versus Architekturarbeiten

Die anstehenden Architekturarbeiten sind von den Rollengruppen Software-Lieferant und Plattform-/Software-Betreiber umzusetzen. Die nachstehenden Unterkapitel arbeiten die vermuteten Wechselwirkungen zwischen bestehenden Unternehmensstandards und dem erforderlichen Architekturvorgehen heraus.

9.1.1 Software-Lieferanten

Professionelle Software-Hersteller verwenden in der Regel ein oder mehrere Frameworks, die helfen sollen, den Entwicklungsprozess ab Code-Erstellung über Testprozeduren bis hin zur finalen Qualitätssicherung zu standardisieren. Die am Markt verfügbaren Produkte dafür sind jedoch mehrheitlich auf eine konkrete Programmiersprache zugeschnitten und nicht universell einsetzbar. Es ist daher nicht zu erwarten, dass alle am SouvAP beteiligten Hersteller bezüglicher ihrer Entwicklungsprozesse vergleichbar sind respektive identische Frameworks verwenden bzw. identische Frameworks gleichartig einsetzen.

Der SouvAP soll aus dem Zusammenschluss bereits vorhandener und daher unabhängig voneinander entwickelter Softwareprodukte entstehen, die auf die Bewältigung alltäglich anfallender Verwaltungsaufgaben zugeschnitten sind. Das Architekturkonzept zum SouvAP hat in Phase C kein einheitliches Anwendungsentwicklungsmodell gefordert, da davon ausgegangen wurde, dass die Modulkandidaten in den verwendeten Programmiersprachen diversifizieren. Daher wurde davon ausgegngen, dass die Informationssystemarchitektur zum SouvAP übergreifend keine einheitlichen Management-Standards befolgt.

Aus Sicht der Architektur gelingt dennoch die Festlegung von übergeordneten Standardisierungen, die aus den technischen Handlungsfeldern gemäß Phase E ableitbar sind. Diese sollten unter den beteiligten Software-Lieferanten als empfohlenes Vorgehensmodell Akzeptanz finden und in der Umsetzung mit gegenseitiger Abstimmung befolgt werden. Die folgende Auflistung benennt Beispiele für übergeordnete Standardisierungen ohne Anspruch auf Vollständigkeit.

• Vorhandene Code-Segmente sind betreffend ihres Funktionsumfangs zu prüfen und gegebenenfalls zu ergänzen. Es wird erwartet, dass dies vollständig mittels vorhandener Management-Standards gesteuert werden dann. Die an der Migration beteiligten Entwickler sollten die anfallenden Aufgaben in gewohnter Manier analog dem üblichen Tagesgeschäft bewältigen können.
• Die Bedienkonzepte sind unter allen beteiligten Software-Lieferanten abzustimmen und zu vereinheitlichen. Dies erfordert die Spezifikation eines übergreifenden Standards und die Aufbereitung von Stilvorgaben gemäß einem Pflichtenheft. Idealerweise gelingt die Kapselung des Standards in einer portablen Bibliothek, die von allen Teilnehmern an den Entwicklungsprozessen genutzt werden kann.
• Die Anforderung nach Barrierefreiheit setzt voraussichtlich ein Studium der dafür umzusetzenden Richtlinien voraus. Mit Blick auf das einheitliche Bedienkonzept sind auch in diesem Punkt Abstimmungen unter allen beteiligten Software-Lieferanten erforderlich. Aus Sicht der Architektur ist ein regelmäßiger Austausch der beteiligten Entwickler untereinander erforderlich, um eine einheitliche und möglichst vollständige Umsetzung der Anforderungen über alle SouvAP-Module zu erreichen.
• Die Containerisierung fordert möglicherweise eine Neuorientierung auf der Seite der Entwickler. Aufgrund der aktuell noch zahlreichen und untereinander nicht standardisierten Hilfsmittel für das Zusammenspiel komplexer Modul-Landschaften mit jeweils zahlreichen Microservices ist zu diesem Punkt eine Abstimmung zwischen den Software-Lieferanten und zusätzlich den Plattform-Betreibern benötigt. Ziel soll es sein, einen gemeinsam genutzten Pool an Container-nativen Services (insbesondere für die Architektur-Pattern API-Gateway, Service-Mesh und Key-Management) festzulegen, der den homogenen Betrieb aller Module und damit ihre Interoperabilität unterstützt. Es sei an dieser Stelle hervorgehoben, dass die DVS dazu bisher keine Festlegung getroffen hat.
• Die Umsetzung von Sicherheitsmaßnahmen bedingt voraussichtlich ebenfalls neue Unternehmensstandards, zumindest derart, dass die beteiligten Entwickler gemeinsam anzuwendende Standards festlegen müssen. Vermutlich betreten die Entwickler mit der Transformation von traditioneller hin zu Container-nativer Ausgestaltung von Sicherheitsmaßnahmen weitestgehend Neuland. Während bisher erforderliche Sicherheitsmaßnahmen durch Komponenten realisierbar waren, die z.B. als Agenten parallel zur Applikation durch das zugrunde liegende Betriebssystem bedient werden konnten, sind in Container-nativen Anwendungen Sicherheitsmaßnahmen entweder von der Applikation selbst umzusetzen oder über Services zu adaptieren, die selbst in Containern operieren.

9.1.2 Plattform-/Software-Betreiber

Das Tagesgeschäft der Plattform-/Softwarebetreiber ist heute mehrheitlich durch unternehmensspezifische Service-Kataloge geprägt. Diese liefern dem Kunden Transparenz zu buchbaren Dienstleistungen rund um den Plattform- und/oder Software-Betrieb. Die Betreiber schneiden ihre Service-Kataloge auf eine Implementierung von Hard- und Software zu, die durch ein zyklisch fortgeschriebenes RZ-Design geprägt ist. Entsprechend unterliegt der Service-Katalog – wie auch die zugrunde liegende Technik – einem Lebenszyklus. Erfolgreiche Service-Provider stimmen ihre Service-Kataloge mehrheitlich auf die Kundenanforderungen ab und sie planen, verbauen und betreiben die Technik passend zu den Kundenanforderungen.

Bei der Steuerung des Geschäftsbetriebs orientieren sich die professionellen Anbieter mehrheitlich an der international akzeptierten IT Information Library ITIL. Dort zusammengefasste Empfehlungen sollen helfen, das Tagesgeschäft in planbare Routinearbeiten zu strukturieren. Zusätzlich geben sie Hinweise auf den effizienten Umgang mit ungeplanten Störungen. Des Weiteren nehmen gesetzliche Regelungen und unternehmerische Standards Einfluss auf das Tagesgeschäft. Den Nachweis ordnungsgemäßer DV-Tätigkeiten gegenüber Kunden und Aufsichtsbehörden erbringen die Dienstanbieter über Arbeitsprotokolle. Für besonders sensible Bereiche ist sogar eine Videoaufzeichnung von Systemzugängen und administrativen Eingriffen üblich. Diese internen Prozesse bilden Beispiele für eine unternehmensinterne Prozesslandkarte.

Betreiber des SouvAP müssen nach Ansicht der Architektur zumindest in Teilen neue Geschäftsprozesse etablieren, um den Aufbau und den Betrieb einer DVS-konformen Plattform leisten zu können. Es wäre wünschenswert, dass dazu zeitnah ein Vorgehensmodell entsteht, das eine Art Standard für einheitliche Betriebsprozesse für Betreiber von DVS-konformen Plattformen im Allgemeinen und darauf betriebenen SouvAP-Implementierungen im Besonderen summiert. Nachstehend sind einige Beispiele für neue Prozesse aufgezählt, die auf der Seite der Plattform-/Softwarebetreiber auszugestalten wären. Diese begründen sich über die Vorgabe „DVS-konform“ und sie sind der Bereitstellung der SouvAP-Artefakte auf Open CoDE geschuldet:

• Der Plattform-Betreiber muss eine Festlegung treffen, für welche Schutzstufen DVS-Implementierungen betrieben werden sollen. Je Schutzstufe ist ein Kubernetes-Cluster aufzubauen und die Zuwege sind entsprechend den DVS-Vorgaben aufzuschalten.
• Das Plattform-Design muss zentrale Dienste bereitstellen, die sicherheitsrelevante Aufgaben umsetzen. Es sind Mechanismen einzuziehen, die eine Kopplung dieser Dienste mit den SouvAP-Modulen ermöglichen.
• Die Zielkonfigurationen sind für jede Schutzstufe automatisiert auszurollen. Dafür sind Werkzeuge zu fertigen, die auf die jeweils erforderlichen Aufgaben zugeschnitten sind. Zusätzlich sollten Werkzeuge erstellt werden, die die Einhaltung der umgesetzten Schutzmaßnahmen prüfen bzw. nachweisen können.
• Die auf Open CoDE bereitgestellten Artefakte sind in der jeweils lokalen Registry zur Plattform als vertrauenswürdige Images einzuspielen. Das Vertrauensniveau ist zyklisch zu überprüfen.

9.2 Geschäftsnutzen der Arbeitspakete

Die in Phase E zusammengestellten Arbeitspakete haben auf hoher Flughöhe produktspezifische Ziele vorformuliert, die über ein systematisches Vorgehen die technische Bereitstellung, den operativen Betrieb und die effiziente Nutzung des SouvAP ermöglichen sollen. Eine dazu passend erzeugte Roadmap hat Aufgabenstellungen zusammengestellt, die die technische Implementierung, ihre sicherheitsrelevante Ausgestaltung und den erfolgreichen produktiven Einsatz des SouvAP vorantreiben sollen. Der Geschäftsnutzen darin enthaltener Arbeitspakete entfaltet sich für den Auftraggeber und die Nutzer faktisch erst ab der produktiven Nutzbarkeit des SouvAP, frühestens also nach Projektende. Für die umsetzenden Rollengruppen ist der geschäftliche Nutzen bereits mit der Abnahme von Lieferleistungen gemäß einem Meilensteinkonzept erreichbar. Darüber hinaus können Plattform-Betreiber bereits aus Zwischenergebnissen zusätzlichen Geschäftsnutzen wie folgt erzielen:

• Die Plattform ist betriebsbereit: Plattformbetreiber können Softwarebetreibern das Fundament für beliebige containerisierte Services anbieten, die mit der zugrunde liegenden Virtualisierungsschicht kompatibel sind. Es sind die Spezifikationen zur Plattform offen zu legen.
• Die Plattform ist C5-testiert und/oder BSI IT-Grundschutz zertifiziert: Der Plattform-Betreiber kann sein Serviceangebot mit einem Sicherheitssiegel bewerben. Falls eine Zertifizierung für BSI IT-Grundschutz vorliegt, ist ein Antrag zur Teilnahme als Plattform-Betreiber im Rahmen der Deutschen Verwaltungscloud erfolgversprechend.

Auch für die Software-Lieferanten ist ein Geschäftsnutzen perspektivisch bereits nach Abschluss von Teilaufgaben möglich, wenn die Arbeitsergebnisse wiederverwendbar sind und in andere Projekte einfließen können. Diese wären z.B.:

• Eine Bibliothek wurde erstellt, die ein einheitliches Bedienkonzept abbildet: Die Bibliothek ist als Standard für Dialogschnittstellen innerhalb alternativer Modulkandidaten für den SouvAP nutzbar oder auch für Produkte, deren Einsatzspektren außerhalb des Portfolios für den SouvAP liegen.
• Eine Bibliothek wurde erstellt, die ein barrierefreies Bedienkonzept abbildet: Dies ist als Ergänzung oder Erweiterung zu dem zuvor genannten Teilergebnis einzustufen. Die Wiederverwendbarkeit und daher der Geschäftsnutzen erstreckt sich auf die zuvor genannten Einsatzbereiche.
• Es stehen (gehärtete) Basis-Images für die Containerisierung bereit, die eine Prüfung auf BSI IT-Grundschutz Stand halten: Die von der containerisierten Anwendung benötigte Laufzeitumgebung enthält allenfalls minimale Angriffsflächen. Eine Nachprüfung des finalisierten Container-Abbilds auf BSI IT-Grundschutz sowie eine etwa erforderliche Risikoanalyse erfordern deutlich reduzierten Aufwand.

9.3 Ressourcenbedarf, Zeitplanung, Kostenabschätzung

Die zugehörigen Kenndaten wurden im Vorfeld des Projekts erzeugt und sie werden während der Projektdurchführung beobachtet und bewertet.

Der Ressourcenbedarf wurde in Personentagen geschätzt. Auf dieser Basis wurde Kostenabschätzung erzeugt.

Die Zeitplanung wurde auf 17 Monate festgelegt. Darin wurden 6 Meilensteintermine festgelegt, zu denen abrechenbare Teillieferungen entsprechend vertraglich festgehaltener Abnahmekriterien zu übermitteln sind.

Die Details dazu sind in den Leistungsscheinen zum SouvAP für die Jahre 2022 und 2023 aufgeführt.

Im Projektverlauf wurde die Arbeit nach Leistungsscheinen vereinzelt als unflexibel eingestuft. Zum einen hat die Architekturarbeit notwendige Arbeitspakete identifiziert, die in den Leistungsscheinen nicht enthalten waren. Zum anderen wurden Arbeitspakete umgewidmet, da im Zuge der Umsetzung erkannt wurde, dass die dort enthaltene Leistungsbeschreibung bzw. die Abnahmekriterien eine Überarbeitung benötigen. Mit dieser Herangehensweise wurde in Einzelfällen eine Art Agilität in die Projektumsetzung eingezogen. Es entstand insgesamt das Meinungsbild, dass ein Projekt dieser Größe bereits in der Planungsphase mehr Flexibilität zugestehen sollte.

9.4 Priorisieren der Migrationsprojekte

In Phase E Kapitel 11.3 wurden die Migrationsprojekte in die Gruppen Technik, Sicherheit und Personal gruppiert und es wurde zu besonders relevanten Teilaufgaben bewertet, welchen Risiken das Gesamtprojekt unterliegt, wenn die Teilaufgabe nicht oder nur teilweise umgesetzt wurde. In Summe können die technischen bzw. sicherheitsrelevanten Risiken die folgenden Auswirkungen entfalten:

• Die Plattform (Kubernetes Cluster) ist nicht betriebsbereit – Der SouvAP ist nicht nutzbar.
• Die Plattform ist betriebsbereit, aber nicht DVS-konform – Der SouvAP ist seitens der öffentlichen Verwaltung nicht produktiv nutzbar.
• Ein oder mehrere SouvAP-Module sind nicht containerisiert – SouvAP-Modul(e) ist/sind nicht nutzbar.
• Ein oder mehrere SouvAP-Module sind containerisiert, aber nicht gehärtet – SouvAP-Modul(e) ist/sind seitens der öffentlichen Verwaltung nicht produktiv nutzbar

Eine tabellarische Aufbereitung dieser Analyse liefert das folgende Nutzungsdiagramm:

Die Migration von Infrastruktur und Informationssystemarchitektur sind grundsätzlich parallelisierbar und sie sollten wie folgt priorisiert werden:

• Aufbau einer Plattform für den SouvAP (Kubernetes-Cluster). Im Ergebnis steht ein technisches Fundament bereit und das ist für Entwicklung und Test von SouvAP-Modulen nutzbar.
• Containerisierung der SouvAP-Module. Die erzeugten Images sind anschließend auf einer Container-Laufzeitumgebung betreibbar.
• Ergänzung der Plattform um Security-Services. Die Plattform kann einem C5-Testat bzw. einer Zertifizierung nach BSI IT-Grundschutz unterzogen werden.
• Härtung der containerisierten SouvAP-Module. Die SouvAP-Module sind auf einer DVS-konformen Plattform produktiv nutzbar.

9.5 Roadmap validieren, Architekturdefinitionen aktualisieren

Die Roadmap wurde im Umlaufverfahren einem Review unterzogen. Die Validierung wurde über die Einarbeitung von Kommentaren geleistet, die die Reviewer geliefert haben. Aus den Reviews wurden die folgenden Bereiche identifiziert, die in Teilen eine Überarbeitung der Architektur und der Roadmap begründen:

• Betrachtung der funktionalen Bedarfe: Aufgrund der Vorauswahl der dem Projekt zugrunde gelegten Open Source Software wurde eine grundlegende Abdeckung der funktionalen Anforderungen entsprechend dem Bedarf angenommen. Innerhalb der Architekturarbeit wurde daher der Fokus auf die nicht-funktionalen Anforderungen Sicherheit, Skalierbarkeit und DVS Konformität gelegt. Im Zuge der Umsetzung hat sich herausgestellt, dass für die fachliche Integration ein zusätzlicher Abgleich mit funktionalen Anforderungen erforderlich ist. Das resultiert u.a. aus den Anforderungen seitens der Sicherheitsarchitektur und dem Interop-Layer. Außerdem gelingt mit diesem Schritt die Überprüfung der Wahl einzusetzenden offenen Standards auf Vollständigkeit.
• Abgrenzung der Verantwortlichkeiten: Die Architektur beschreibt den Aufbau eines Souveränen Arbeitsplatzes. Aufbau und Betrieb stehen im Verantwortungsbereich unterschiedlicher Rollen, und zwar Software-Lieferanten Plattform-Betreiber und Software-Betreiber. Nur Teile der Gesamtarchitektur werden durch die auf Open CoDE bereitgestellte Software realisiert. Die Abgrenzung der Verantwortlichkeiten der Rollen und ihrer Liefergegenstände in Bezug auf die Elemente der Gesamtarchitektur ist noch nicht abgeschlossen.
• Aufnahme neuer Anforderungen: Aus der Gruppe der praxisinteressierten Stakeholder wurden die einsatzrelevanten Fähigkeiten Multicloud-Föderation, Höchstverfügbarkeit und Offline-Desktop angefragt. Diese Anforderungen wurden von der Architektur zur Kenntnis genommen und als wünschenswerte Erweiterung für zukünftige Iteration der Architekturentwicklung eingestuft.
• Finalisierung der Lösungsdesigns: Aus der Architekturarbeit auf die softwareseitige Umsetzung wirkende Implikationen sind nochmal im Detail sowohl Modul-spezifisch als auch Modul-übergreifend abzuprüfen. Die resultierenden Spezifikationen muss die Interoperabilitätsschicht verarbeiten. Konkret bedeutet dies, dass die Interoperabilitätsschicht auf die Anforderungen der Architektur hin zuzuschneiden ist.

9.6 Implementierung/Migration

Die Arbeitspakete werden arbeitsteilig in Anlehnung an die Leistungsscheine 2022 und 2023 umgesetzt. Im Anhang sind ausgewählte Feinkonzepte zusammengefasst, die darüberhinausgehend zusätzliche Schritte präzisieren, die in den Leistungsscheinen nicht direkt mit Abnahmekriterien behaftet wurden. Dazu zählen:

• Marktübersicht: Anhand der Funktionsmodellierung gemäß Phase C Kapitel 2.3 wurde das Potenzial für Modulkandidaten analysiert, die alternativ zur getroffenen Vorauswahl die Wechselfähigkeit einzelner SouvAP-Module unterstreichen können.

9.7 Abschluss des Architekturentwicklungszyklus, Dokumentation der gewonnenen Erkenntnisse

Die beauftragten Transformationsschritte sind in den Leistungsscheinen 2022 und 2023 ausgewiesen und mit Abnahmekriterien behaftet. Der Architekturentwicklungszyklus endet mit Abschluss der dort zusammengestellten Einzelaufgaben.

Darüber hinaus wurden im Zuge der Transformation weitere Themen adressiert, die im Zuge der Architekturarbeit als umsetzungsrelevant erkannt wurden:

• Die Anforderung „Erfüllung der BSI IT-Grundschutzanforderungen“ für alle Module des Liefergegenstands hat aus Sicht der Architektur den sicheren Betrieb oberhalb einer Kubernetes-Plattform nur teilweise adressiert. BSI IT-Grundschutz berücksichtigt in der Edition 2023 nur einen Teil der in der Kubernetes-Dokumentation aufgeführten Angriffsflächen.
• Die differenzierte Analyse von Sicherheitsanforderungen an containerisierte Applikationen hat auf Seite der Software-Lieferanten Defizite aufgedeckt. Deren Behebung hat zusätzliche Aufwände verursacht.
• Für die Rolle Plattform-/Software-Betreiber waren ebenfalls ergänzende Sicherheitsmaßnahmen zu identifizieren und beim Aufbau der Plattform umzusetzen. Die fortschreitenden Arbeiten an den Spezifikationen zur DVS haben hier teils willkommene inhaltliche Klärungen beigesteuert, letztlich aber auch die Komplexität der ursprünglich angedachten Infrastruktur für den SouvAP-Betrieb offengelegt.
• Der Prozess ab Softwareübergabe bis betriebliche Bereitstellung hat eine Diskussion der Zuständigkeiten und Verantwortlichkeiten der Rollengruppen Software-Lieferanten und Plattform-/Software-Betreiber entfacht. Dabei wurde offenkundig, dass ein gesichertes Lieferkettenmodell entwickelt werden muss und die Umsetzung für alle Beteiligten planbar und nachvollziehbar ausgestaltet sein muss.
• Die Automatisierung aller Aufbau- und Betriebs-Prozesse, wie sie durch die DVS vorgegeben werden, ist im Detail noch nicht etabliert. Das dafür benötigte Wissen muss außerdem noch bei allen Beteiligten aufgebaut werden.

Während der Architekturarbeit wurde offenkundig, dass die vorab festgelegte Methode TOGAF unter den Projektbeteiligten mehrheitlich einen umfangreichen Aufbau von Methodenkenntnissen erforderte. Dies hat aber – positiv – im Ergebnis im Architekturteam ein neues und Domänen-übergreifendes Verständnis zur Architekturarbeit manifestiert und es hat Resultate erzeugt, die künftig eine deutlich optimierte Steuerung dieser und vergleichbarer Initiativen ermöglicht.

Eine unerwartet hohe Hürde stellte die Anforderung „Bereitstellung als DVS-konforme Container“ dar. Dies war hauptsächlich durch die damit verbundenen Sicherheitsanforderungen begründet, die teils erhebliche Eingriffe in die auf traditionelle Plattformen (Bare Metal, Virtuelle Maschine) zugeschnittenen Anwendungen erfordert. Speziell die bisher genutzten zentralen Sicherheitsdienste wie Antivirus und Monitoring stellten sowohl die Software-Lieferanten als auch die Plattform-Betreiber vor neue Herausforderungen, da diese anders als bisher nicht einfach durch Agenten oberhalb eines zugrunde liegenden Betriebssystems bedienbar sind. Die darauf aktuell geleisteten Antworten nutzen im Umfeld von Kubernetes etablierte Techniken. Dazu wurden Produktentscheidungen gefällt, die zukünftig zur Diskussion stehen dürften.

Die Ausarbeitungen zur DVS unterliegen aktuell noch der Konkretisierung. Das Dokument Deutsche Verwaltungscloud-Strategie: Rahmenwerk der Zielarchitektur Version 2.5.5 vom 09. Oktober 20231 enthält neue Anforderungen insbesondere an die CI/CD-Pipeline. Dies hat Auswirkungen auf den erforderlichen DevSecOps-Prozess zum SouvAP, der aus Sicht der Architektur vollständig konsistent zum DVS-Auslieferungsprozess sein muss. Zusammenfassend empfiehlt die Architektur die nachfolgend genannten ergänzenden Aktivitäten außerhalb der Architekturarbeit und Anpassungen im Vorgehensmodell bei einer möglichen Folgeiteration:

• Ausgestaltung einer Prozessdefinition für die gesicherte digital souveräne Bewirtschaftung von Open CoDE, die eine Art Lebenszyklus-Management von Artefakten – inklusive Schwachstellenmanagement – auf Open CoDE reguliert.
• Ausgestaltung einer Prozessdefinition für die Bereitstellung, den Betrieb, die Aktualisierung, den Umgang mit Sicherheitsvorfällen und die Ablösung/Austauschbarkeit von auf Open CoDE bereitgestellten SouvAP-Modulen.
• Zusammenstellung von methodischen und fachlichen Schulungsempfehlungen für Projektbeteiligte zum Projektbeginn, ggf. Ergänzung um weitere Materialien währen des Projektverlaufs.
• Ausformulierung der Transformationsplanungen nach Fertigstellung der Roadmap als Architekturauftrag.
• Aufnahme eines Puffer-Budgets in den Architekturauftrag, der unvorhergesehene, aber umsetzungsrelevante Zusatzaufgaben finanzieren kann.

9.8 Anhang

9.8.1 Marktübersicht SouvAP‑Modulkandidaten

Die Inhalte zu diesem Abschnitt wurden aus einer „Marktanalyse Open Source Module“ aufbereitet. Das Material geht auf eine Ausarbeitung der Fachabteilung TZ43 von Dataport zurück. Bei der Zusammenstellung wurde die Funktionsmodellierung zum SouvAP zugrunde gelegt.

9.8.1.1 Cloud‑Dateiablage

Die Cloud‑Dateiablage liefert zentralen Massenspeicher. Dort speichern die Nutzer des SouvAP Dateien bzw. Dokumente. Ein hierarchisches Dateisystem ermöglicht dort die strukturierte Ablage in benutzerdefinierten Ordnern. Über Dateiattribute verwalten die Benutzer Zugriffsrechte. Darüber können sie anderen Benutzern des SouvAP die Kenntnisnahme zu Datei‑Inhalten verwehren (kein Zugriff), erlauben (Zugriff nur‑lesen) oder auch die Mitwirkung in der Datei‑Fortschreibung (Zugriff lesen/schreiben) ermöglichen.

Die Cloud‑Dateiablage für den SouvAP speichert Dokumente auch höherer Schutzstufen. Aus diesem Grund ist zu fordern, dass die Cloud‑Dateiablage prinzipiell sowohl die verschlüsselte Ablage von Dokumenten als auch ihren verschlüsselten Transport beherrscht.

Die Analyse hat die folgenden Produkte berücksichtigt:

• Nextcloud Files
• ownCloud
• Seafile
• Pydio

Die Tabelle fasst die Leistungsmerkmale der Produkte in Anlehnung an das SouvAP‑Funktionsmodell für eine Cloud‑Dateiablage vergleichend zusammen.

Tabelle 1: Fähigkeiten von aktuellen Open‑Source Produkten zum Segment Cloud‑Dateiablage

9.8.1.2 Web‑Office

Web‑Office bzw. Online‑Office kennzeichnen eine Sammlung von Anwendungen, die mindestens die Aufgabenstellungen Dokumentverarbeitung, Tabellenkalkulation und Erstellung von Präsentationen abdecken. Die Namenszusätze „Web“ oder „Online“ signalisieren, dass die enthaltenen Anwendungen aus einem Web‑Browser heraus zu steuern sind. Die Speicherformate für Dokumentendateien und auch die Bedienoberfläche sind üblicherweise an Office‑Anwendungen für Endgeräte (Clients) angelehnt.

Die Analyse hat die folgenden Produkte berücksichtigt:

• Collabora Online
• OX Documents
• OnlyOffice
• CryptPad

Die Tabelle fasst die Leistungsmerkmale der Produkte in Anlehnung an das SouvAP‑Funktionsmodell für ein Web‑Office vergleichend zusammen.

Tabelle 2: Fähigkeiten von aktuellen Open‑Source Produkten zum Segment Web‑Office

9.8.1.3 Wissensmanagementsystem

Wissensmanagementsysteme bündeln Funktionen, die den strukturierten Umgang mit und die zentrale Verwaltung von internem und externem Wissen unterstützen. Im Unterschied zu einer reinen Dateiablage oder reinen Notiz‑Tools liegt der Fokus solcher Systeme auf der bedarfsgerechten Präsentation von Wissen – häufig in Form von Enterprise‑Wikis.

Die Analyse hat die folgenden Produkte berücksichtigt:

• xWiki
• Wiki.js
• Bookstack
• BlueSpice
• DokuWiki

Die Tabelle fasst die Leistungsmerkmale der Produkte in Anlehnung an das SouvAP‑Funktionsmodell für ein Wissensmanagementsystem vergleichend zusammen.

Tabelle 3: Fähigkeiten von aktuellen Open‑Source Produkten zum Segment Wissensmanagementsystem

9.8.1.4 Projektmanagementsystem

Ein Projektmanagementsystem unterstützt bei der Durchführung von Projekten. Es liefert dem Anwender allgemeine und spezielle Werkzeuge für die Planung und die Steuerung von Projekten.

Die Analyse hat die folgenden Produkte berücksichtigt:

• OpenProject
• Mattermost Boards
• Taiga
• ProjectLibre

Die Tabelle fasst die Leistungsmerkmale der Produkte in Anlehnung an das SouvAP‑Funktionsmodell für ein Projektmanagementsystem vergleichend zusammen.

Tabelle 4: Fähigkeiten von aktuellen Open Source Produkten zum Segment Projektmanagementsystem

9.8.1.5 E‑Mail und Kalender

E‑Mail‑Produkte dienen dem Senden und Empfangen von E‑Mails sowie der Verwaltung von Postfächern. Kalenderprodukte unterstützen die Organisation und die Pflege von Einzel‑ und Serienterminen mit Teilnehmerlisten. Sie können häufig weitere unternehmerische Ressourcen wie Räume, Beamer usw. buchen. Häufig integrieren Produkte zu diesem Marktsegment Leistungsmerkmale von Groupware‑Produkten, z. B. Adressbuchverwaltung und Aufgabenorganisation.

Die Analyse hat die folgenden Produkte berücksichtigt:

• Open‑Xchange
• Zimbra Collaboration
• Kopano
• EGroupware

Die Tabelle fasst die Leistungsmerkmale der Produkte in Anlehnung an das SouvAP‑Funktionsmodell für E‑Mail und Kalender vergleichend zusammen.

Tabelle 5: Fähigkeiten von aktuellen Open Source Produkten zum Segment E‑Mail und Kalender

9.8.1.6 Kurznachrichten

Auf Kurznachrichten zugeschnittene Dienste (Instant‑Messaging‑Dienste) unterstützen den synchronen und asynchronen Austausch von Nachrichten eines Dienstnutzers mit einer anderen Einzelperson oder mit Gruppen. Synchron bedeutet, dass Nutzer die Nachrichten unmittelbar nach dem Versand erhalten; asynchron bedeutet, dass Nachrichten auch dann zugestellt werden, wenn der Empfänger zum Sendezeitpunkt offline war. Viele Dienste unterstützen zudem Datei‑, Audio‑ und Video‑Übertragungen sowie persistente Chaträume.

Die Analyse hat die folgenden Produkte berücksichtigt:

• Element
• Rocket.chat
• Zulip
• Mattermost

Die Tabelle fasst die Leistungsmerkmale der Produkte in Anlehnung an das SouvAP‑Funktionsmodell für Kurznachrichten vergleichend zusammen.

Tabelle 6: Fähigkeiten von aktuellen Open Source Produkten zum Segment Kurznachrichten