5. Phase B: Geschäftsarchitektur

5.1 Überblick

Die Geschäftsarchitektur im Rahmen des Architekturkonzeptes zum SouvAP hat die vorrangige Aufgabe, den wechselseitigen Einfluss der angestrebten IT-Lösung auf die dafür wesentlichen geschäftlichen Prozesse der Beteiligten zu erfassen und zu berücksichtigen.1

Die Beschreibung der Geschäftsarchitektur folgt einer an TOGAF angelehnten Adaption, bestehend aus den Teilen

• Geschäftsstrategie
  einschließlich der Geschäftsprinzipien, der organisatorischen Rahmenbedingungen, Motivation der Beteiligten, digitale Trends und Trends der Verwaltungsarbeit, dem zu erwartenden Betriebsmodells sowie der Lösungsidee

• Geschäfts-Design
  einschließlich der Beschreibung der zur Verfügung zu stellenden Fähigkeiten der zu entwickelnden IT-Lösung, basierend auf den zu entwickelnden Business-Capabilities, einer Beschreibung der Werteketten der geschäftlichen Beteiligten und ihrer Lieferungen, sowie einer Betrachtung der beteiligten Informationsdomänen

• Geschäfts-Transformation
  einschließlich der Betrachtung der zu priorisierenden Capabilities und Funktionen, dem zu erwartenden Einfluss auf die beteiligten Geschäftsorganisationen und Risiken

5.2 Geschäftsstrategie

5.2.1 Geschäftsprinzipien

In 3.1.3 wurden bereits einige Geschäftsprinzipien benannt.

Die für die Entwicklung des SouvAP geeigneten Organisationen, Funktionen und Prozesse sollen sich nachfolgenden übergeordneten Architektur- und Geschäftsprinzipien richten:

Tabelle : Geschäftsprinzipien

5.2.2 Treiber für die Entwicklung des SouvAP

Die Entwicklung einer Lösung für einen SouvAP wird getrieben durch eine Reihe von gesellschaftlichen Trends und Weichenstellungen der Politik.

Dazu gehören u.a.:

• Digitale Trends in der IT

• Trends in der Entwicklung der Arbeitswelt

• Gesellschaftspolitische Trends

5.2.2.1 Zu berücksichtigende digitale Trends in der IT

In den letzten Jahren haben in der IT-Industrie einige Entwicklungen stattgefunden, die selbstverständlich auch die IT in der Verwaltungsarbeit direkt beeinflussen:

Tabelle : Digitale Trends in der IT

5.2.2.2 Zu berücksichtigende Trends in der Verwaltungsarbeit

Der SouvAP beschreibt einen Teil eines Digitalen Arbeitsplatzes, der wiederum Teil eines übergreifenden Arbeitsplatzkonzeptes ist, wie Verwaltungsmitarbeiter zukünftig arbeiten werden.

Der Erfolg jeglicher Veränderung der Arbeitsweise der Mitarbeiter hängt von allen diesen Faktoren ab, die sich immer wechselseitig bedingen. Es ist also nicht einfach eine rein technische Fragestellung.

Auf die Frage, wie ein moderner digitaler Arbeitsplatz aussehen muss, noch dazu in der Verwaltung, gibt es keine eindeutige Antwort, aber Hinweise.

Die Beratungsgesellschaft Gartner beschreibt in ihrem Hype Cycle mehrere solcher für den SouvAP relevante Trends2:

Tabelle : Digitale Trends im Arbeitsplatz

Zusätzlich wird nach der Pandemie ein Trend zum "Erhalt" von Home Office / "Distributed Office" Arbeitskulturen wahrgenommen, sowie damit einhergehend eine selbstorganisierte und dadurch asynchronere Arbeitsweise.

5.2.2.3 Gesellschaftspolitische Ableitungen

Einige dieser allgemeinen Trends aus der Digitalisierung und Veränderung der Arbeit selbst sind direkt oder indirekt in die Digitalstrategien des Bundes und der Länder eingeflossen.

z.B. werden in der Digitalstrategie des Bundes3 3 Handlungsfelder benannt:

• Vernetzte und digital souveräne Gesellschaft

• Innovative Wirtschaft, Arbeitswelt, Wissenschaft und Forschung

• Lernender, digitaler Staat

In der Digitalstrategie des Bundes4 werden einige Themen, den SouvAP betreffend herausgestellt:

• Wir gestalten neue Modelle des Arbeitens

Um die digitale Wirtschaft zu stärken, unterstützen wir flexible Arbeitsmodelle, modernen Datenschutz und den Einsatz Künstlicher Intelligenz.

• Wir wollen Technologien „made in Germany“

Wer wichtige Technologien selbst entwickelt, bleibt unabhängig. Darum wollen wir Künstliche Intelligenz, Chips und Quantenrechner aus eigener Hand.

• Wir wollen die Verwaltung vereinfachen

Alle Behörden und ihre Dienstleistungen sollen auf ein Smartphone passen. Dafür schaffen wir die Voraussetzungen – etwa mit der digitalen ID.

• Wir sichern Behörden im digitalen Raum ab

Damit Daten der Verwaltungen geschützt sind, fördern wir verschlüsselte Kommunikation. Zudem werden wir unabhängiger von einzelnen Herstellern.

• Wir machen Daten sicher für Behörden und Unternehmen

Das Bedürfnis nach Cybersicherheit wächst. Netze und Software müssen widerstandsfähig sein. Deshalb stärken wir unsere Institutionen.

Beispielhaft für die Digitalstrategien der Länder sei auf die DVH (Digitale Verwaltungsstrategie Hessen)5 verwiesen. U.a. werden dort verschiedene Ziele benannt:

• In einem zentralen Verwaltungsportal wollen wir alle behördlichen > Angebote der Kommunen, Landes- und Bundesbehörden bündeln und sie > allen Bürgerinnen und Bürgern, Unternehmen und Institutionen > jederzeit service- und nutzenorientiert online zugänglich machen.

• Wir wollen Verwaltungsleistungen digitalisieren und online auf allen > Ebenen anbieten. Dazu treiben wir die notwendige enge > Zusammenarbeit zwischen Bund, Ländern und Kommunen voran. Wir > teilen unsere guten Lösungen mit allen, implementieren erprobte > Verfahren anderer und stehen insbesondere unseren Kommunen zur > Seite.

• Wir wollen die Möglichkeiten moderner IT-Infrastruktur, innovativer > Technologien und optimierter Prozesse ausschöpfen, um die > Landesverwaltung stetig zu modernisieren und die vielfältigen > Aufgaben effizient und bürgernah zu erfüllen.

5.2.2.4 Schlussfolgerungen und Akzeptanzkriterien für den SouvAP

Der SouvAP soll nicht einfach eine weitere Adaption einer Office-Lösung mit Schwerpunkt auf das Thema „Souveränität“ sein. Der Erfolg eines SouvAP wird sich erst einstellen, wenn er eine ganze Reihe Akzeptanzkriterien berücksichtigt:

• Im Mittelpunkt steht die Akzeptanz durch die Nutzenden selbst

  • Die Verwaltungsmitarbeiter haben i.d.R. bereits eine Lösung für den digitalen Arbeitsplatz im Einsatz. Der SouvAP darf in seiner Funktionalität und Nutzungserlebnis nicht schlechter sein als dessen bisherige Lösung. Das heißt insbesondere, dass die Vorteile einer neuen, auf die konkrete und unmittelbare Verwaltungsarbeit zugeschnittene Lösung etwaige Nachteile durch z.B. fehlende Features wettgemacht werden sollten.
    Wobei die Bewertung sowohl objektiv gemessen werden kann, z.B. in der Anzahl der notwendigen Aktionen wie Mausklicks, als auch sehr subjektive und nur über Umfragen zu ermittelnde Aspekte umfasst.

  • Die Lösung muss die neuen Anforderungen aus der Digitalisierung und der Veränderung der Arbeitswelt der Verwaltung direkt berücksichtigen.

  • Die weitere Konzeption und Entwicklung erfolgt entsprechend der Nutzungserfahrung und im Hinblick auf eine moderne Verwaltung

• Der SouvAP muss die gesellschaftlichen Rahmenbedingungen und Zielstellungen erfüllen

  • Das Thema Souveränität steht im Mittelpunkt und ist ein Haupttreiber für die Lösung

  • Dies schließt nicht nur die bereitgestellte Software selbst mit ein, sondern den gesamten Wertschöpfungsprozess einschließlich einer Bereitstellung in einer souveränen Cloud-Umgebung (siehe DVS) und die Entwicklung der Lösung.

• Die Lösung muss in seiner Wertschöpfungskette für alle beteiligten Partner einen Gewinn darstellen

  • Der SouvAP wird ähnlich zu dem im Rahmen des OZG vereinbarten EfA Prinzip als eine Gemeinschaftslösung betrachtet, die eine spezifische, entsprechend den unterschiedlichen Verwaltungen angemessene Ausprägung erfährt

  • Die Vergütung der Leistungen innerhalb der Wertschöpfungskette erfolgt nach wirtschaftlichen und fairen Modellen

  • Die Lösung und deren Entstehung darf den bestehenden Verwaltungsprozessen nicht zuwiderlaufen.

siehe hierzu die entsprechenden komplementären Geschäftsprinzipien 49:

• Ökologisches Denken und Nachhaltigkeit

• Ausrichtung auf Verwaltungsnutzen und Anwenderzufriedenheit basierend auf Anwenderfeedback

• Sicherheit First (u.a. Security by Design)

• Partnerschaftliche und faire Geschäftsbeziehungen

5.2.3 Organisationssicht

5.2.3.1 Beteiligte Organisationen, Akteure

Im Rahmen der Zurverfügungstellung des SouvAP sind folgende Organisationen unmittelbar beteiligt und bilden eine virtuelle Organisation eigentlich formal und rechtlich unabhängiger Akteure:

Abbildung : Beteiligte Organisationen, Akteure

• BMI/ZENDIS ZenDiS
  Auftraggeber und Koordinator des zu entwickelnden SouvAP

• Deutsche Verwaltung

In ihren verschiedenen Ausprägungen als Verwaltung des Bundes, der Länder und Kommunen sowie Verwaltungskooperationen ist die ÖV der zentrale Nutzer des SouvAP

• Kunden der Verwaltung

Die Kunden der Verwaltung sind in erster Linie die Bürger, verwaltungsnahe Organisationen, Unternehmen und Communities.

Sie sind von der Nutzung des SouvAP nicht ausgeschlossen, falls es entsprechende Angebote der IT-Dienstleister dazu geben sollte. Der Source Code steht allen Bürgern und Unternehmen gleichermaßen (über das Repository Open CoDE) zur Verfügung.

• IT-Dienstleister des Bundes, der Länder und Kommunen

Sie handeln im gesetzlichen Auftrag der ÖV und stellen ihr zentrale IT-Dienstleistungen zur Verfügung, so auch den SouvAP.

• Software-Anbieter der Privatwirtschaft und die Community, Softwareanbieter

Viele der zu entwickelnden SouvAP Module entstammen der Entwicklung privater IT-Firmen und der freien IT-Community

5.2.3.2 Beteiligte Rollen im Rahmen des SouvAP

Neben den Beteiligten am SouvAP im Rahmen der Entwicklung, Zurverfügungstellung, Betrieb und Nutzung lassen sich die Rollen etwas differenzieren (siehe auch die Definitionen der Rollen in der DVS):

Abbildung 6: Beteiligte Rollen im Rahmen des SouvAP

Zu beachten ist, dass die in 4.2.1 genannten Anspruchsgruppen im realen Wertschöpfungsprozess dabei verschiedene und auch parallele Rollen einnehmen.
So sind die Bundes- und Landesbehörden sowohl Auftraggeber der Kundenseite als auch selbst Nutzer der Software, die IT-Dienstleister des Bundes, der Länder und Kommunen können auch selbst Softwarelieferanten sein.

Ebenfalls zu beachten ist, dass die Nutzungsbedingungen der Software in der Öffentlichen Verwaltung vor allem über Subskriptionen organisiert werden und nicht über reine Softwarelizenzen.

Erläuterung Konfektionierung: Der Erstellungsprozess des SouvAP erfolgt mehrstufig (siehe Wertschöpfungskette später). Ein Software-Konfektionierer stellt durch Auswahl und Integration aus der Gesamtheit der zur Verfügung stehenden Softwaremodule ein spezifisches Produkt zusammen.

5.2.3.3 Motivation der Beteiligten Akteure

Innerhalb der virtuellen Gesamtorganisation müssen die unmittelbar der Verwaltung unterworfenen Beteiligten, also sowohl die Verwaltungsorganisation selbst als auch ihre IT-Dienstleister von den externen Partnern, Softwarelieferanten unterschieden werden. Diese teilen zwar im Rahmen des SouvAP die meisten Interessen, aber es gibt auch zu berücksichtigende Unterschiede.

Siehe 4.2.2 für eine Auflistung der verschiedenen zu berücksichtigenden Interessen.

Auch die Interessen innerhalb der Verwaltungsorganisationen sind nicht identisch. Grade aus den zum Teil sehr spezifischen Anforderungen wird der Bedarf für speziell konfektionierte Lösungen des SouvAP abgeleitet, die trotzdem auf demselben Konzept und gemeinsamen Komponenten beruhen und damit abgestimmt werden müssen.

Siehe hier auch die in 3.1.4 genannten Rahmenbedingungen und Geschäftsziele der Beteiligten.

5.2.4 Betriebsmodell

Der Begriff Betriebsmodell wird in der Strategie auf Unternehmensebene verwendet, um zu beschreiben, wie eine Organisation in Geschäftsbereiche strukturiert ist, welche Aktivitäten zentralisiert oder dezentralisiert sind und wie viel Integration zwischen den Geschäftsbereichen erforderlich ist

Die beteiligten Partner bei der Erstellung, Bereitstellung und Betrieb des SouvAP haben zwar im Hinblick auf den Erfolg des SouvAP ähnliche Zielstellungen, aber unterschiedliche organisatorische Voraussetzungen. So unterliegen alle Entscheidungsträger im öffentlichen Bereich einigen Beschränkungen, an denen nicht zu rütteln ist.

• Die Ressorthoheit

• Die Autonomierechte von Gebietskörperschaften

• Regeln des Beschaffungsrechts

• uva.

Privatrechtliche Partner haben hier grundsätzlich eine größere Flexibilität, sowohl was die Geschäftsmodelle anbelangt, als auch die Umsetzung in ihren jeweiligen Bereichen und Ebenen.

Wesentlich im Rahmen der Entwicklung des SouvAP ist die Beziehung zwischen dem Auftraggeber des SouvAP, der gleichzeitig die Steuerung übernimmt (BMI/ ZenDiS) und den verwaltungsnahen IT-Dienstleistern (gemeinsames Anforderungs- und Releasemanagement) sowie die Beziehung dieser IT-Dienstleister untereinander (Bereitstellung und Referenzimplementierungen).

Die Softwarelieferanten der Open Source Software sind strategisch wichtig, da deren langfristige Planung der Module mit der Roadmap des SouvAP abgeglichen werden muss. Für die Steuerungsprozesse der virtuellen Organisation selbst spielt dieser Aspekt eine eher untergeordnete Rolle.

Abbildung 7: Integration/ Lokale Verantwortung

Der SouvAP wird der Idee nach als dezentrale Lösung im Sinne von Referenzimplementierungen eines gemeinsamen Standards entwickelt und als konfektionierte Lösungen den tatsächlichen Verwaltungskunden zur Verfügung gestellt. Der unmittelbare Integrationsdruck der Beteiligten ist in dieser Lösungsidee eher niedrig.

Die Verantwortung für die Leistungserbringung an die Verwaltungskunden selbst liegt beinahe vollständig bei den IT-Dienstleistern des Bundes, der Länder und Kommunen, allerdings ist das gemeinsame Releasemanagement der Lösung in zentraler Verantwortung. Die Entwicklung der Softwaremodule erfolgt lokal bei den Softwarelieferanten, die Lieferung dieser Softwaremodule wird allerdings zentral gesteuert. Es kann also davon ausgegangen werden, dass die Zusammenarbeit als koordinierter Verbund zwischen diesen Hauptbeteiligten erfolgt.

Gegen ein kooperatives Netzwerk bzw. ein zentralisierter Verbund spricht die Tatsache, dass zumindest momentan die IT-Dienstleister des Bundes, der Länder und Kommunen verwaltungsrechtlich autonom agieren.

Dies bedeutet insbesondere die Verpflichtung der IT-Dienstleister, die gemeinsamen Standardisierungsvorgaben zu beachten, um einen gemeinsamen SouvAP zu ermöglichen und nicht in auseinanderdriftende Landeslösungen zu zerfallen.

5.2.5 Lösungsidee

Die Lösungsidee des SouvAP lässt sich folgendermaßen beschreiben:

Der SouvAP ist technologisch ein Desktop-as-a-Service (DaaS). Basierend auf einer in der DVS beschriebenen Cloud-Infrastruktur wird den Verwaltungen eine für sie maßgeschneiderte Office-Lösung angeboten.

Die Lösung basiert auf

• einem einheitlichen fachlichen und technischen Konzept, das vom BMI/ ZenDiS verwaltet wird und einen einheitlichen Souveränen Arbeitsplatz mit einheitlicher Nutzererfahrung ermöglicht

• von Software-Lieferanten entwickelte OpenSource Module

• die von IT-Dienstleistern zu spezifischen Lösungen konfektioniert werden

• und die von IT-Dienstleistern des Bundes, der Länder und Kommunen den Verwaltungen zur Verfügung gestellt werden

5.2.6 Legale und kommerzielle Geschäftsaspekte

5.2.6.1 Gesetze und Verwaltungsvorschriften

Bei Softwareausschreibungen in der öffentlichen Verwaltung in Deutschland sind mehrere Gesetze und Vorschriften zu berücksichtigen. Einige der wichtigsten sind:

• Vergaberecht: Die Vergabe von Softwareprojekten in der öffentlichen Verwaltung unterliegt dem deutschen Vergaberecht. Dies umfasst das Gesetz gegen Wettbewerbsbeschränkungen (GWB) und die Vergabeverordnung (VgV), die Vorschriften für die Vergabe von öffentlichen Aufträgen festlegen.

• Informations- und Kommunikationstechnik (IKT)-Beschaffungsrichtlinie: Die IKT-Beschaffungsrichtlinie ist eine EU-Richtlinie, die in Deutschland umgesetzt wurde und die Beschaffung von IKT-Produkten und -Dienstleistungen in der öffentlichen Verwaltung regelt. Sie enthält Vorschriften zur Vergabe von IKT-Aufträgen und zur Offenheit für Open Source-Software.

• Urheberrecht: Das Urheberrechtsgesetz (UrhG) regelt die Rechte an geistigem Eigentum, einschließlich Software. Bei Softwareausschreibungen müssen die rechtlichen Aspekte des Urheberrechts und der Lizenzbedingungen berücksichtigt werden.

• Datenschutzrecht: Das Datenschutzrecht, insbesondere die Datenschutz-Grundverordnung (DSGVO), legt fest, wie personenbezogene Daten verarbeitet werden dürfen. Bei Softwareausschreibungen müssen die Anforderungen des Datenschutzrechts berücksichtigt werden, insbesondere wenn personenbezogene Daten verarbeitet oder gespeichert werden.

• IT-Sicherheit: Die öffentliche Verwaltung hat die Pflicht, die Sicherheit ihrer IT-Systeme und Daten zu gewährleisten. Bei Softwareausschreibungen müssen daher die Anforderungen an die IT-Sicherheit berücksichtigt werden, um sicherzustellen, dass die ausgewählte Software den erforderlichen Sicherheitsstandards entspricht.

Es empfiehlt sich, die Unterstützung von juristischen Experten und Fachleuten in öffentlicher Beschaffung hinzuzuziehen, um sicherzustellen, dass alle rechtlichen Anforderungen erfüllt werden.

5.2.6.2 Software-Nutzungsbedingungen

Während in der Architekturvision auf die inhaltlichen Aspekte der Nutzungsbedingungen der Produktbestandteile eingegangen wurde und die Prinzipien der Nutzung von OSI konformen Lizenzen abgeleitet wurden müssen die Verwaltungsprozesse dazu als solche designt werden. Einige Durchführungsregeln:

• Im Rahmen des SouvAP werden ausschließlich OSD konforme Open Source Lizenzen für die Softwaremodule berücksichtigt, idealerweise mit bestehender Freigabe auf OpenCoDE

• Der zentrale Auftraggeber des SouvAP wird entsprechend seiner Gestaltungsmacht auf die Nutzung in diesem Sinne erlaubter Lizenzen und erforderlicher Subskriptionsmodelle hinwirken

• Jeder Lieferant, sei es der Hersteller der OSS-Module, als auch die IT-Bereitstellung des SouvAP hat seine Nutzungsbedingungen hinsichtlich ihrer inhaltlichen Ausrichtung und Wirkung auf eventuelle Abrechnungen transparent zu machen

• Jeder Kunde einer Lieferung hat im Gegenzug die Nutzung der entsprechenden Subskriptionen zu dokumentieren

5.2.6.3 Abrechnungsmodelle

Die gesamte Wertschöpfungskette stellt die Erbringung unterschiedlicher Leistungen dar, die gegenfinanziert und fair abgerechnet werden sollen.

Dafür sollten einige generelle Regeln maßgeblich sein:

• *Die öffentlichen Verwaltungen haben einen längeren Planungshorizont und sind (Stand heute) sehr CAPEX orientiert, d.h. sie folgen i.d.R. lieber Einmalbudgetierungen mit vorhersagbaren Kosten. Variable OPEX Leistungen sind dagegen eher die Ausnahme.
  Mit Blick auf die Zurverfügungstellung in einer Cloud mit einem Pay-per-use Ansatz wird es hier erst eines Lernprozesses bedürfen. Das Standard-Abrechnungsmodell wird auf ‚herkömmlichen‘ Leistungs- und Entgeldkatalogen aufgebaut sein müssen.
  *

• Die Abrechnungsmodelle der verschiedenen Leistungserbringer müssen ihrerseits aber so transparent sein, dass ein einfaches Abrechnungsmodell für die Verwaltungsorganisation des Endkunden möglich wird.

• Es wird angestrebt, dass die Abrechnungsmodelle für verschiedene SouvAP Instanzen ähnlich sind, um Vergleichbarkeit zu gewährleisten.

5.3 Geschäftsdesign

5.3.1 Beschreibung der zu entwickelnden Business Capabilities

Um die im Rahmen des SouvAP zu entwickelnden Architekturbausteine zu bestimmen, werden die grundlegenden Funktionen, Prozesse, Organisationen und technischen Lösungen in Business Capabilities abstrahiert. Zugrunde liegt die oben beschriebene virtuelle Organisation des SouvAP.

Diese Business Capabilities sollen einerseits einen Bezugspunkt für eine fähigkeitsbasierte Planung schaffen, andererseits auch strukturelle Abhängigkeiten sichtbar machen.

Für die Entwicklung des SouvAP sind im Wesentlichen drei verschiedene Gruppen von Business Capabilities maßgeblich:

• Capabilities den SouvAP aus der Nutzungsperspektive betreffend
  (Fähigkeiten, die sich aus der unmittelbaren Nutzung und damit benötigten Funktionalitäten des SouvAP ergeben)

• Capabilities aus der Anbieter- bzw. Bereitstellungsperspektive
  (Fähigkeiten, die der SouvAP aus der Perspektive der Bereitstellung und damit sowohl der Konfektionierung als auch der Zurverfügungstellung, einschließlich benötigter Infrastrukturdienste bieten muss)

• Capabilities zur Entwicklung und der Governance des SouvAP
  (Fähigkeiten, die benötigt werden, um den SouvAP zu entwickeln und verwalten zu können)

Anmerkung: Neben der nutzerorientierten Betrachtung der erwarteten Fähigkeiten der Lösung selbst sind sowohl die Bereitstellungsperspektive, als auch die Steuerungs- und Entwicklungsfähigkeiten der virtuellen Organisation von Interesse. Zur Vereinfachung und nötigen Abstraktion kann auf das It4IT Referenzmodell der OpenGroup zurückgegriffen werden, das ebenfalls eine virtuelle Organisation in ihrer Erbringung von IT-Dienstleistungen in ihrer Wertschöpfungskette beschreibt.

Die nachfolgend genannten Capabilities sind dabei in drei Ebenen benannt, was ein in der Literatur und Architekturpraxis übliches Vorgehen ist.

5.3.1.1 Capabilities, den SouvAP selbst betreffend

(Nutzungsperspektive)

In der nachfolgenden Abbildung 65, werden die von einem Nutzer abverlangten wesentlichen Fähigkeiten des SouvAP aufgelistet.
Die Capabilities der Ebene 2 (Kommunikation, Netzwerken, Organisation und Planung, Management und Zugriff auf Inhalte, Durchführung von Businessaufgaben) wurden initial der Literatur über die Gestaltung eines Digitalen Arbeitsplatzes entnommen und entsprechend der hier adressierten Verwaltungen diskutiert und angepasst.

Abbildung 8: Capabilities, den SouvAP selbst betreffend

Im Einzelnen lassen sich diese Capabilities folgendermaßen beschreiben:

Tabelle : Capabilities den SouvAP selbst betreffend

5.3.1.2 Capabilities, die Bereitstellung des SouvAP betreffend

(Bereitstellungsperspektive)

Die in Abbildung 67 aufgelisteten Capabilities entstammen einer Analyse der Arbeitsweise der IT-Dienstleister des Bundes, der Länder und Kommunen und beschreiben deren Tätigkeiten als Fähigkeiten im Kontext der Bereitstellung des SouvAP:

Abbildung 9: Capabilities, die Bereitstellung des SouvAP betreffend

Im Folgenden werden diese Capabilities beschrieben:

Tabelle : Capabilities, die Bereitstellung des SouvAP betreffend

5.3.1.3 Capabilities der Steuerung und Produktentwicklung

(Steuerungs- und Entwicklungsperspektive)

Die in 68 erfassten Capabilities bilden sowohl die softwaretechnische, als auch strategische Entwicklungssicht ab. Hinweise dazu gibt es in der Literatur, u.a. zur IT4IT Referenzarchitektur.

Abbildung 10: Capabilities der Steuerung und Produktentwicklung

Diese Capabilities lassen sich im Einzelnen folgendermaßen beschreiben:

Tabelle : Capabilities der Steuerung und Produktentwicklung

5.3.2 Zuordnung der Rollen zu den Akteuren und Capabilities

Die Beziehungen der verschiedenen Akteure zu den Rollen bzw. Capabilities lässt sich dann folgendermaßen beschreiben:

Tabelle 7: Zuordnung Akteure, Rollen Capabilities

5.3.3 Beschreibung der Liefergegenstände durch die beteiligten Partner

Bevor die Werteströme der Entwicklung und Bereitstellung des SouvAP genauer beschrieben werden, werden hier die eigentlichen Liefergegenstände des SouvAP aufgeführt, die zur Bereitstellung der Funktionalität benötigt werden.

Abbildung Liefergegenstände

Die Entwicklung der Funktionalität des SouvAP erfolgt in mehreren Lieferungen, die aufeinander aufbauen:

1. Der SouvAP muss in seiner Funktionalität konzipiert werden

- Es wird eine Architektur festgelegt, einschließlich der vorgesehenen Module

- Diese zunächst abstrakten Module werden mit den Marktteilnehmern abgesprochen

- Die Lösung wird entsprechend der abstrakten Module spezifiziert

- Die Lösung erhält ein Spezifikationsrelease.

1. Die eigentliche Entwicklung der Module übernehmen Software-Anbieter des Marktes. Es entstehen ein oder mehrere konkrete Module, die der festgelegten Spezifikation folgen

- Die Module sind i.d.R. nicht exklusiv für die ÖV

- Sie folgen einem Vendor spezifischen Release

- Sie werden von den Vendoren in das OpenCOde Source Repository geliefert

1. Aus den zur Verfügung stehenden konkreten Modulen werden (verwaltungs-)kundenspezifische Gesamtlösungen eines SouvAP konfektioniert und zu einer Produkt-Suite zusammengefasst. Eine solche Produkt-Suite ist also eine organisationsspezifische Instanz des SouvAP. Die Phönix-Suite stellt ein Beispiel eines solchen implementierten Produktes dar.

- Auswahl der für die Suite relevanten konkreten Module der Software-Anbieter

- Ergänzung der Gesamtlösung um eigene Funktionalitäten außerhalb der Module und Anpassungen (z.B. eigene Integrationen in Fachverfahren)

- Erstellung Release und Release-Beschreibung des gesamten Produktes

1. Teil der Lieferung des SouvAP ist eine komplette Beispielimplementierung als Source-Code, also einer direkt in einer entsprechenden Laufzeitumgebung lauffähigen SouvAP Lösung

   • Die Beispielimplementierung wird in das Open COde Source Repository als Source geliefert
   • Es werden nicht nur die Module, sondern auch die Integrations- und Deploymentbestandteile
     zur Verfügung gestellt
   • Diese Implementierung ist nicht für den produktiven Betrieb vorgesehen

2. Die erstellte Software-Suite (Produkt) muss noch in geeigneter Form den eigentlichen Kunden zur Verfügung gestellt werden, einschließlich der dazu nötigen Infrastruktur.

Die Lösung wird also um die tatsächlichen IT-Service ergänzt

- Betrieb auf Betreiber-Infrastruktur (DVS-konforme Cloud)

- Anbindung an die Basisdienste (z.B. IAM, Device Management, usw.)

- Etablierung Abrechnungsservices

- Etablierung IT-Support Services

5.3.4 Werteströme des SouvAP

5.3.4.1 Überblick über die Werteströme

Der Erfolg des bereitzustellenden SouvAP hängt wesentlich vom Nutzen für alle Beteiligten ab. (siehe Zuordnung der Rollen zu den Akteuren und Capabilities):

• Strategische Entwicklung und Bereitstellung der Module

Der souveräne digitale Arbeitsplatz wird in einem zweistufigen Prozess den eigentlichen Nutzern in der öffentlichen Verwaltung zur Verfügung gestellt:

• Entwicklung von interoperablen Modulen und deren Zurverfügungstellung im Sourcecode in einem zentralen Repository i.d.R. durch OSS Hersteller in deren eigenen Entwicklungsprozessen

• Aus diesen Modulen werden anschließend im Rahmen der Bereitstellung konkrete und passgenaue Produkte durch die IT-Dienstleister des Bundes, der Länder und Kommunen konfektioniert und den Kunden zur Nutzung angeboten

Der Wertschöpfungsprozess in seiner Konzeption und der zur Verfügungstellung der Open Source Module wird dabei zentral verwaltet.

• Produkt- und IT-Service Bereitstellung

Die digitalen Funktionalitäten des SouvAP werden vorrangig von IT-Unternehmen der öffentlichen Verwaltung in ihren Rechenzentren und auf ihren Plattformen bereitgestellt. Die IT-Dienstleister stellen die Funktionalitäten geeignet aus den zentral zur Verfügung gestellten Modulen zusammen und konfektionieren ein passgenaues Produkt für ihre Verwaltungskunden.

• Produkt-Nutzung

Der tatsächliche Nutzen für die Mitarbeiter der öffentlichen Verwaltung erfolgt in der Auswahl und Nutzung der mit dem SouvAP zur Verfügung gestellten Funktionalitäten

Im Folgenden werden die einzelnen Werteströme im Einzelnen beschrieben:

Tabelle : Werteströme: Strategische Entwicklung und Bereitstellung der Module

Tabelle : Werteströme: Produkt und IT-Service Bereitstellung

Tabelle : Werteströme: Produkt Nutzung

5.3.4.2 Zuordnung der Werteströme zu den beteiligten Rollen

Die in obiger Tabelle beschriebenen Werteströme werden durch die in 58 beschriebenen Rollen realisiert. Diese Realisierung wird durch die gestrichelten Linien ausgedrückt.

Die Werteströme selbst sind in Aktivitäten geordnet (durch Pfeile verbunden)

Abbildung Zuordnung Werteströme zu den Rollen

5.3.4.3 Zuordnung der Werteströme zu den Liefergegenständen

Die oben beschriebenen Liefergegenstände ordnen sich in die Kette der Werteströme folgendermaßen ein:

Abbildung Wertestrom und Liefergegenstände

5.3.5 Geschäftsmodell und Lieferketten

5.3.5.1 Liefergegenstände und Schnittstellen

Entsprechend der Werteströme werden die folgenden zu produzierenden Liefergegenstände jeweils beauftragt sowie geliefert und haben dabei die angegebenen Schnittstellen bzw. Interaktionen:

Tabelle : Liefergegenstände

Das entsprechende Organisationsdesign hat neben den formalen Aspekten der Wertschöpfungskette auch die geschäftlichen Rahmenbedingungen im Auge zu behalten.

Es wird davon ausgegangen, dass sämtliche Software OSD-konform ist. Dennoch können Subskriptionsmodelle explizit vereinbart werden, z.B. um Gewährleistungen und Support, oder noch leistungsstärkere Enterprise-Editionen zu verwenden.

Eine Sonderrolle spielt das Konzept des SouvAP selbst, da es als Branding den Nutzungsbedingungen des Auftraggebers unterliegt.

Abbildung Liefergegenstände - Schnittstellen

Die diesem Lieferprozess zugrundeliegenden Geschäftsprinzipien sind:

• Partnerschaftliche und faire Geschäftsbeziehungen

• Wirtschaftlichkeit

• Lieferung von Services anstatt Anwendungen an die Verwaltungskunden

• Prosumer-Lösung

• Anforderungsbasierte und demokratische Roadmap

5.3.5.2 Geschäftsmodelle der Beteiligten

Ein Geschäftsmodell erfasst im Wesentlichen, wie Werte in der Organisation geschaffen werden. Die Modelle können z.B. in Form von Business Model Canvases beschrieben werden.

Die Elemente eines Geschäftsmodells:

• Management - Wie wird die Organisation geführt?

• Kosten – Wie ist die Kostenstruktur der Organisation?

• Produkte und Services – Welche Leistungen stellt die Organisation her?

• Erlöse – Welche Erlöse generiert die Organisation?

• Kompetenzen – Welche Kompetenzen werden benötigt und über welche Kompetenzen verfügt die Organisation?

• Kunden – Wer sind die Kunden der Organisation?

• Lieferungen – Wie werden die Leistungen geliefert?

Diese Elemente sind nun für die verschiedenen Rollen im Kontext des SouvAP zu erfassen und dahingehend zu vergleichen, ob es Überdeckungen und Konflikte gibt.

Diese Untersuchung würde allein für die Rollen der beteiligten Akteure der Öffentlichen Verwaltung unvollständig bleiben müssen, da allein diese bereits sehr diversifiziert sind.

So sind einige IT-Dienstleister des Bundes, der Länder und Kommunen sowohl Betriebe öffentlichen Rechts, als auch selbst Behörden und damit in ihrer wirtschaftlichen Handlungsfreiheit anderen Bedingungen unterworfen.

Die Geschäftsmodelle der beteiligten Partner hängen jetzt in hohem Maße vom eigenen bzw. zugewiesenem und i.d.R. nicht sehr flexiblen Rollenverständnis ab.

Um eine Gegenüberstellung zu ermöglichen, werden sowohl die Elemente auf das in diesem Kontext wesentliche limitiert, als auch Rollen zusammengefasst und vereinfacht:

• Auftraggeber (Auftraggeber des SouvAP)

• Verwaltungen/Kunde (Auftraggeber für die IT-Dienstleister, Kunde)

• IT-Dienstleister (Software Konfektionierer, Software Betreiber, Plattform Betreiber)

• Software Lieferant (Software Lieferanten)

Vereinfachte Gegenüberstellung:

Tabelle : Geschäftsmodelle

5.3.5.3 Implikationen aus den Geschäftsmodellen

Die Gesamtorganisation des SouvAP ist ein weitgehend geschlossenes System in dem Sinne, dass alle Dienstleistungen letztendlich von den Kunden, also der Öffentlichen Verwaltung gezahlt werden. Das beginnt mit den unmittelbaren Funktionen des SouvAP, erstreckt sich aber auch auf die Finanzierung des Konzeptes und Brandings des SouvAP.

Es besteht jetzt eine gewisse Varianz, wie die Kostenflüsse innerhalb der komplexen Organisation gesteuert werden könnten., in der die unterschiedlichen Rollen durchaus eigene Kosten und Erlöse haben.

Es wird deutlich, dass der SouvAP verwaltungsübergreifend in allen seinen Aspekten damit nur funktionieren kann, wenn der Wertschöpfungsprozess dieser unterschiedlichen Rollenverteilung durch ein hohes Maß an Standardisierung und verbindlichen Festlegungen Rechnung trägt.

Das bedeutet insbesondere:

Tabelle : Implikationen aus den Geschäftsmodellen

5.3.6 Abgeleitete Prozesse und Beispielworkflows

Ähnlich zu den beschriebenen Business Capabilities und den ebenfalls beschriebenen Wertschöpfungsketten im Kontext des SouvAP wird ein Prozessmodell ebenfalls in verschiedenen Ebenen beschrieben:

• Szenarien der Nutzer des SouvAP

• Szenarien der beteiligten Akteure an der Entwicklung, Bereitstellung und Verwaltung des SouvAP

Die Beschreibung beschränkt sich dabei auf wesentliche Prozessbestandteile und liefert kein vollständiges Prozessmodell im Sinne eines BPMN.

5.3.6.1 Nutzungsszenarien der SouvAP Nutzer

Um die relevanten Szenarien beschreiben zu können, sei zuerst auf die wesentlichen Aspekte der Verwaltungsarbeit selbst verwiesen, in den der SouvAP genutzt werden wird:

Der Nutzen der Softwarelösung des souveränen digitalen Arbeitsplatzes ergibt sich primär aus der Nutzung durch die Mitarbeiter der Verwaltung. Das betrifft:

• Alle Aspekte der Unterstützung der Arbeitsvorgänge der Verwaltungsmitarbeiter durch die Softwarelösung selbst, also die Digitalisierung der bestehenden Verwaltungsvorgänge, einschließlich der Erhöhung der persönlichen Produktivität

• Die erfolgreiche Integration der neuen Lösung in die bereits bestehende Prozess- und IT-Landschaft

• Die Ermöglichung von sogar neuen Formen der Lösung von Verwaltungsaufgaben durch die Software

Nicht vergessen werden dürfen andere Aspekte der Nutzung von Software, um sie erfolgreich zu machen und den Nutzen zu generieren:

• Die Software muss verstanden werden, also z.B. in den Funktionen leicht nachzuvollziehen sein und bedarf einer einführungsbegleitenden Schulung

• Die Nutzererfahrung muss insgesamt positiv sein, einschließlich Performance

• Die ‚Form‘, also Modulfunktionalität und Nutzerinterface muss der Funktion, also den Verwaltungsaufgaben folgen. Die Anwendungen müssen z.B. eine logische Einheit bilden

Der hier zu beschreibende digitale Arbeitsplatz ist vorrangig für die Mitarbeiter der Öffentlichen Verwaltung gedacht. Die Arbeit selbst könnte in 3 Tätigkeitsaspekte unterteilt werden:

1. Allgemeine Büro- und Verwaltungstätigkeiten: Diese Tätigkeiten dienen der unmittelbaren Verwaltungstätigkeit, also beispielsweise die Arbeit mit den Fach- und Querschnittsverfahren, die Bürgerkommunikation, die Veraktung usw. Das ist die klassische Verwaltungsarbeit.

2. Projektartige Tätigkeiten und Tätigkeiten in Teams: In der Industrie, ebenso in der Öffentlichen Verwaltung findet die Arbeit, damit auch die digitale Arbeit immer mehr in zeitlich begrenzten Projekten und in virtuellen Teams statt. Diese Projektarbeit kann dabei innerhalb der eigenen Verwaltungsorganisation, aber auch organisationsübergreifend organisiert sein.

3. Übergeordnete Tätigkeiten in der Verwaltungsorganisation: Die Öffentliche Verwaltung besteht aus Verwaltungsorganisationen, die ihrerseits ganz eigene Tätigkeiten erfordern. Hier z.B. die Information aller Mitglieder der Organisation über ein schwarzes Brett im Intranet.

Diesen Tätigkeitsaspekten können folgende Tätigkeiten zugeordnet werden, aus denen sich die verschiedenen Nutzungsszenarien ableiten lassen:

Abbildung : Nutzungsszenarien

Die Mitarbeiter der Öffentlichen Verwaltung sind in diesen Tätigkeiten auf die Unterstützung durch den SouvAP angewiesen. Um die dazu benötigten Komponenten zu bestimmen und optimieren zu können, bietet es sich an, beispielhafte Workflows zu entwerfen und auf ihre Toolunterstützung bezüglich verschiedener Nutzerprofile zu überprüfen.

Bereits jetzt sind einige dieser Szenarien bereits hinreichend bekannt und mit Beispielworkflows beschrieben (siehe Anhang), neuere werden dazukommen. Die Methodik dabei ist, möglichst Szenarien zu finden, die ein oder mehrere Tätigkeiten einschließen, um Wiederverwendbarkeit bereits in der Prozessebene zu gewährleisten.

5.3.6.2 Nutzungsszenarien der Entwicklung und Bereitstellung

Nicht nur die Nutzung des Souveränen Arbeitsplatzes durch die Endanwender selbst erfolgt in typischen Workflows, sondern auch die Entwicklung und Bereitstellung des Souveränen Arbeitsplatzes durch die beteiligten Organisationen lassen sich nach typischen Aktivitäten entsprechend Lieferungen entlang der (oben) bereits beschriebenen Werteströme detaillierter beschreiben und gruppieren:

Abbildung Workflows der Entwicklung und Bereitstellung

Der jeweilige Wertschöpfungsprozess wurde bereits im Überblick beschrieben. Einige Tätigkeitsaspekte sind im Sinne des Verständnisses der Geschäftsprozesse zu detaillieren:

siehe dazu auch die Capabilities der Steuerung und Produktentwicklung, sowie Capabilities, die Bereitstellung des SouvAP betreffend

ebenso die Werteströme des SouvAP

Eine tabellarische Übersicht der entsprechenden die Prozesse repräsentierenden Workflows sieht dann so aus:

Tabelle : Workflows

5.3.7 Lösungsdesign

Welche Designvorgaben lassen sich aus einer Geschäftsperspektive nun bezüglich der bereitzustellenden SouvAP Lösung treffen, die sowohl für die Anwendungs-, als auch Technologie- und Infrastrukturarchitektur relevant sind?

Eine funktionale Betrachtung hat zu klären:

• Welche Nutzer werden mit dem SouvAP später arbeiten, welche Nutzerprofile sind in der öffentlichen Verwaltung üblich?

• Was sind die Rahmenbedingungen der Nutzung, z.B. mit welchen Geräten in welchen Umgebungen werden die Mitarbeiter der öffentlichen Verwaltung aktiv sein?

• Welche Anwendungsfeatures werden die Nutzer benötigen, um die geforderten Business-Capabilities besser zu unterstützen?

Eine Betrachtung der Entwicklung und Bereitstellung hat zu klären:

• Welche Komponenten werden prinzipiell die benötigten Anwendungsfeatures bereitstellen?

• Welche dieser Komponenten sind typischerweise bei den beteiligten Partnern bereits vorhanden oder müssen neu entwickelt werden?

• Gibt es spezielle Anforderungen an diese Komponenten aus einer Geschäftsperspektive der Beteiligten und wie werden diese Komponenten geliefert und bereitgestellt?

• Wie muss das Gesamtsystem des SouvAP aussehen und wie wird es gebildet?

• Wie wird dieses Gesamtsystem den Mitarbeitern der öffentlichen Verwaltung aus zugänglich gemacht?

5.3.7.1 Geräteklassen und Nutzungsprofile der IT-Lösung

Der Rolle ‚Software Nutzer‘ lassen sich verschiedene in der öffentlichen Verwaltung und deren Kunden übliche Geräteklassen zuordnen, mit denen die Mitarbeiter den SouvAP nutzen könnten.

Daraus wiederum lassen sich Nutzerprofile ableiten, die für die Referenzarchitektur und die entsprechenden Nutzungsszenarien berücksichtigt werden müssen.

Abbildung 17: Nutzerprofile und Geräteklassen

Die verschiedenen relevanten Kategorien:

Tabelle 15: Kategorien/ Attribute

Anmerkung: Der SouvAP ist auf eine webbasierte Lösung ausgerichtet. Lokale Installationen des SouvAP sind demnach nicht Stand der Betrachtungen und sind nicht Teil der Referenzarchitektur.

Für die zu entwickelnden Anwendungsszenarien lassen sich u.a. folgende, durch Betrachtung bei den IT-Dienstleistern gewonnene in der öffentlichen Verwaltung typische Nutzerprofile ableiten.

Tabelle 16: Nutzerprofile

5.3.7.2 Zuordnung der Nutzerprofile zu den Geräteklassen

Eine detaillierte Zuordnung der Nutzerprofile zu den Geräteklassen sieht dann so aus:

Tabelle 17: Zuordnung der Nutzerprofile zu den Geräteklassen

Anmerkung: Nicht alle Nutzerprofile werden in den ersten Versionen des SouvAP gleichermaßen Berücksichtigung finden. Der Fokus liegt hier auf dem Standard-Verwaltungsmitarbeiter mit seinem stationären PC oder Laptop. Zusätzlich wird die mobile Nutzung des SouvAP sichergestellt mit einer speziellen Betrachtung der dort angebotenen Module.

Anmerkung: Da die Situation der Bereitstellung von IT-Dienstliestungen in den unterschiedlichen Verwaltungen unterschiedlich erfolgt, werden keine Annahmen zur Bereitstellung der Geräteklassen getroffen und sind nicht Teil des Umfangs der Architekturbetrachtungen.

5.3.8 Übersicht der zu liefernden Funktionalitäten

Für die Roadmap der Module und zu liefernden Funktionalitäten des SouvAP sind entsprechend der Geschäftsstrategie die gewünschten Geschäfts-Capabilities zu entwickeln.

Diese wiederum haben sowohl die definierten Treiber, Geschäftsziele, Geschäftsprinzipien als auch die zu erwartenden Anforderungen aus der Arbeitsweise der Verwaltungen zu berücksichtigen.

Üblicherweise werden die Geschäfts-Capabilities in einem Reifemodell entwickelt, in dem vom erhobenen Ist-Reifegrad ausgehend, die Zielreife der jeweiligen Geschäfts-Capabilities bestimmt wird.

Da für den SouvAP weder eine umfassende Ist-Aufnahme möglich ist, noch eine exakte Ziel-Reife bestimmt werden kann, ist es sinnvoll, zumindest die besonders maßgeblichen Geschäfts-Capabilities aus Nutzungsperspektive entsprechend Nutzungsszenarien der Verwaltungsarbeit hervorzuheben, aus denen die funktionalen Module abgeleitet werden können. Eine Gruppierung nach Verbindlichkeit und Priorität folgt dieser Methodik.

Annahme:

• Es werden entsprechend des Verwaltungsauftrages die essenziellen Basis-Fähigkeiten beschrieben, die unbedingt zu berücksichtigen sind. Das schließt die Berücksichtigung neuerer Trends in der Verwaltungsarbeit mit ein

• Es werden die erweiterten Fähigkeiten benannt, die eine zu erwartende Nachfrage widerspiegeln

5.3.8.1 Priorisierung Tätigkeitsspektrum der Verwaltung

Ausgehend von Beobachtungen innerhalb der öffentlichen Verwaltung kann eine Annahme bezüglich einer Priorisierung der Tätigkeiten vorgenommen werden, bei der die Nutzung des SouvAP besonders nützlich und dringend erscheint:

Abbildung Priorisierte Tätigkeiten

Es ist hier zu beachten, dass die Priorisierung und Verbindlichkeit ausschließlich aus den ausgeübten Tätigkeiten abgeleitet werden und keine Implementierungsroadmap bedeuten, die auch von anderen Faktoren abhängt (siehe u.a. Kap-E).

Des Weitern ist jede Vorgabe mit einer Verbindlichkeit gemäß RFC 2119 geprägt, wird also mit einem Verbindlichkeitsgrad muss, soll, kann oder darf nicht assoziiert.

Es gilt die Annahme, dass eine hohe Verbindlichkeit eine hohe Priorisierung nahelegt.

Tabelle : Verbindlichkeit nach Tätigkeitsspektrum

5.3.8.2 Priorisierung der Business-Capabilities

Welche der prinzipiell mit einem SouvAP assoziierten Business Capabilities werden mit den Funktionen und Features der zu entwickelnden Module besonders unterstützt werden?

Es wird im folgenden, basierend auf Beobachtungen in der Öffentlichen Verwaltung eine Annahme dazu getroffen. Diese ist später durch ein fundiertes Anforderungsmanagement des Auftraggebers zu überarbeiten.

Business Capabilities die Funktionen des SouvAP selbst betreffend (rote Markierung) bedeutet, dass die Unterstützung ein Muss ist.

Abbildung Priorisierung Business Capabilities

Tabelle : Verbindlichkeit nach Capabilities - Nutzung

Business Capabilities die Bereitstellung des SouvAP selbst betreffend:

Die Verwaltungsvorschriften bezüglich der Bereitstellung der IT der Kommunen, der Länder und des Bundes sind über verschiedene Regelwerke normiert. Die entsprechenden abgeleiteten Business Capabilities sind dementsprechend i.d.R. Muss-Kriterien in ihrer Verbindlichkeit und damit keiner gesonderten Priorisierung unterworfen.

Tabelle : Verbindlichkeit nach Capabilities - Bereitstellung

Business Capabilities der Steuerung und Produktentwicklung betreffend:

Tabelle : Verbindlichkeit nach Capabilities - Steuerung und Entwicklung

5.3.8.3 Ableitung der bereitzustellenden Lösungskomponenten

Die aus den Verwaltungstätigkeiten und Business Capabilities des SouvAP abgeleiteten Funktionalitäten lassen sich als abstrakte Lösungskomponenten beschreiben:

Abbildung Funktionale Komponenten

Abgeleitete funktionale Komponenten des SouvAP sind demnach:

Strategische Entwicklung und Bereitstellung der Module

Tabelle : Verbindlichkeit - Strategische Entwicklung und Bereitstellung der Module

Produkt- und IT-Service Bereitstellung

Tabelle : Verbindlichkeit - Produkt- und IT-Service Bereitstellung

Produktnutzung

Tabelle : Verbindlichkeit - Produktnutzung

(*) derzeit unklar

5.3.9 Beschreibung der relevanten Informationsdomänen

Das Informationsmodell des SouvAP soll einen Überblick verschaffen über die wesentlichen Infor-mationen, die in der Organisation verarbeitet werden.

Allgemein lassen sich die Informationen, die innerhalb der öffentlichen Verwaltung verarbeitet werden in verschiedene Kategorien, Informationsdomänen zusammenfassen:

(Quelle: Architekturteam)

Tabelle : Informationsdomänen

Der SouvAP betrifft alle Formen der Kommunikation, Zusammenarbeit und Schriftverkehr der öffentlichen Verwaltung. Es sind also Informationen aller Informationsdomänen grundsätzlich betroffen und es werden dementsprechend Daten aller Domänen erhoben. Eine spezifische Gruppierung ist nicht möglich, bzw. es müssen alle Informationen und daher die Konsequenzen der Verwendung von vornherein mitgedacht werden.

Informationsklassifizierung entsprechend BSI-Grundschutz:

Es gelten für alle Phasen der Entwicklung, Bereitstellung und Betrieb des SouvAP grundsätzlich die entsprechenden BSI Vorschriften:

• BSI Standard 200-2, Kapitel 8.2 Schutzbedarfsfeststellung
  (Klassen: normal, hoch, sehr hoch)

• BSI Standard 200-2, Kapitel 5.1 Klassifikation von Informationen
  (Klassifizierung: öffentlich, intern, vertraulich, streng vertraulich)

Es gibt keine dedizierten Vorgaben, welche SouvAP Produkte welchen konkreten Klassen und Klassifizierungen genügen müssen, sondern sind mit den jeweiligen Produktkunden abzustimmen, bzw. gesondert zu zertifizieren.

Neben den Sicherheitsbetrachtungen sind auch andere Regularien auf die Entwicklung, Bereitstellung und Betrieb anwendbar, z.B. aus dem Wettbewerbsrecht, dem Persönlichkeitsrecht usw.

Was die Nutzung des SouvAP anbelangt, liegt es in der Natur der Sache, dass ein SouvAP Produkt nicht allen Regularien immer vollumfänglich von vornherein und für alle Anwendungsfälle genügen kann. Hier sind ggf. spezielle Kundenlösungen mit speziellem Bedarf von den Beteiligten zu konzipieren und zu entwickeln.

5.4 Geschäftstransformation

5.4.1 Priorisierung der Aktivitäten

Die Priorisierung der zu entwickelnden Business Capabilities wurde im Abschnitt der zu liefernden Funktionalitäten vorgestellt und folgt den in der Strategie festgelegten Kernfunktionalitäten, die mit dem SouvAP verbunden sind.

Siehe 5.3.8.2

5.4.2 Implikationen auf die bestehenden Geschäftsmodelle der Beteiligten

Mit der Einführung des SouvAP entsteht für eine Reihe der beschriebenen Capabilities eine fachliche und technische Umsetzung, die die Arbeit in der öffentlichen Verwaltung nachhaltig verändern soll.

Diese neue Lösung bedeutet zumindest eine mehr oder weniger große Veränderung in den bestehenden Geschäftsprozessen der beteiligten Akteure:

Tabelle : Implikationen auf die Geschäftsmodelle

5.4.3 Geschäftsrisiken

Die Konzeption, Entwicklung, Einführung und der Betrieb des SouvAP ist mit einer Reihe von Risiken verbunden

5.4.3.1 Einführung des SouvAP als Teil der Digitalisierung

Der SouvAP ist mehr als die Einführung eines abgegrenzten IT-Fachverfahren, sondern ist als Teil der Digitalisierung der öffentlichen Verwaltung als Ganzes zu verstehen. Dies geht mit einer Reihe Risiken einher:

• Datenschutz und Datensicherheit: Mit der zunehmenden Digitalisierung und Verknüpfung von Arbeitsvorgängen sammelt und verarbeitet die öffentliche Verwaltung immer mehr Daten. Das Risiko von Datenschutzverletzungen und Datenlecks steigt entsprechend. Es ist wichtig, angemessene Sicherheitsmaßnahmen zu implementieren und den Schutz personenbezogener Daten sicherzustellen.

• Cybersecurity: Die öffentliche Verwaltung ist ein attraktives Ziel für Cyberangriffe, da sie eine Vielzahl sensibler Informationen und kritischer Infrastrukturen verwaltet. Die zunehmende Digitalisierung, wie die hier adressierte Zurverfügungstellung einer ganzen Produktklasse als SouvAP erhöht das Risiko von Cyberangriffen, wie z.B. Datenmanipulation, Ransomware oder Identitätsdiebstahl. Ein effektives Cybersecurity-Framework ist entscheidend, um solche Angriffe zu verhindern und angemessen darauf zu reagieren.

• Mangelnde IT-Kompetenz: Die Entwicklung, Bereitstellung und Betrieb des SouvAP erfordert spezifisches technisches Know-how und Fähigkeiten, die zwar in der Regel bei den Softwareherstellern und IT-Dienstleistern, aber möglicherweise nicht in ausreichendem Maße in allen Teilen der öffentlichen Verwaltung vorhanden sind. Ein Mangel an qualifizierten IT-Fachkräften und die Notwendigkeit einer kontinuierlichen Weiterbildung stellen ein Risiko für eine erfolgreiche Einführung des SouvAP in der öffentlichen Verwaltung dar.

• Widerstand gegen Veränderungen: Die Einführung neuer digitaler Prozesse und Technologien erfordert Veränderungen in der Arbeitsweise der Mitarbeiter und der Organisation. Widerstand gegen Veränderungen und mangelnde Akzeptanz können die Umsetzung des SouvAP behindern. Eine umfassende Change-Management-Strategie ist erforderlich, um die Akzeptanz der Mitarbeiter zu fördern und sie auf den mit dem SouvAP angestrebten digitalen Wandel vorzubereiten.

• Digitale Kluft: Die Einführung des SouvAP in der komplexen Verwaltungslandschaft kann dazu führen, dass bestimmte Teile der Verwaltung von den Vorteilen ausgeschlossen werden. Es besteht das Risiko einer digitalen Kluft, in der Teile der Verwaltungsmitarbeiter von der Nutzung des SouvAP ausgeschlossen sind, oder zumindest Schwierigkeiten haben, diesen zu nutzen. Es ist wichtig, sicherzustellen, dass der SouvAP möglichst viele Verwaltungsmitarbeiter erreicht, inklusiv ist und niemanden benachteiligt.

• Beherrschung der Komplexität:
  Der SouvAP wird als ein gebrandetes Produkt in mehreren Produktausprägungen, mit vielen Partnern in einer ohnehin bereits komplexen Verwaltungslandschaft zur Verfügung gestellt. Das stellt eine besondere Herausforderung dar, die nur durch klare Prozesse und Lieferbedingungen gemeistert werden kann.

5.4.3.2 Risiken im Kontext der Nutzung von Software

Eines der Hauptziele des SouvAP ist die Durchsetzung der eigenen Datensouveränität in der öffentlichen Verwaltung. Somit sind die mit diesem Ziel verbundenen Technologien und Methoden noch einmal gesondert zu betrachten. Speziell der Einsatz von Open Source-Software als Basis des SouvAP ist dahingehend zu prüfen, ob es erhöhte oder gar neue Risiken gegenüber klassischer Software gibt.

• Sicherheit: Es ist wichtig, dass Sicherheitsaspekte während des gesamten Softwareentwicklungszyklus berücksichtigt werden. Dazu gehören Sicherheitsbewertungen, Sicherheitstests, die Einhaltung bewährter Sicherheitspraktiken und die kontinuierliche Überwachung der Sicherheitslage. Durch eine proaktive Herangehensweise an die Sicherheit können viele potenzielle Sicherheitsrisiken minimiert oder vermieden werden. Darüber hinaus enthält eine große Anzahl Nicht-Open Source bereits Open Source Bestandteile.
  In diesem Kontext hervorzuheben ist eine automatisierte Codeanalyse zur Schadcodeerkennung. Bei Open Source finden Teile des Softwareentwicklungszyklus jetzt allerdings öffentlich statt und sind damit auch transparent und vor allem überprüfbar. Z.B. kann geprüft werden, ob Kompilate zu den Sources passen.

• Unterstützung: Open Source profitiert in der Regel von gemeinschaftlichen Entwicklungen, die nicht unbedingt die in der öffentlichen Verwaltung zwingend notwendige IT-Unterstützungsleistung umfassen muss. Um diese Unterstützungsleistungen, einschließlich z.B. Schulungsangeboten trotzdem sicherzustellen, werden darauf spezialisierte Firmen betraut, welche oft zusätzliche Enterprise Editionen mit erweiterten Funktionen zur Verfügung stellen.

• Kompatibilität und Standards: Um eine hohe Verbreitung des SouvAP zu garantieren, müssen die dazugehörigen Module sowohl untereinander kompatibel sein, vor allem müssen aber die vorhandenen Schnittstellen in andere Ökosysteme der Kunden auf tatsächlich verwendeten Standards beruhen. Dies führt zu Herausforderungen, da die in der öffentlichen Verwaltung genutzten IT-Verfahren häufig proprietär entwickelt wurden. Hinzu kommt, dass neben freien IT-Standards ebenfalls verbreitete firmenabhängige Pseudostandards im Einsatz sind.
  Die Kompatibilität und Interoperabilität müssen in jedem Fall sorgfältig geprüft und möglicherweise angepasst werden, um reibungslose Abläufe sicherzustellen. Open Source hilft hier insofern sogar weiter, weil zumindest die Chance besteht, Standards einsehen und Anpassungen vornehmen zu können.

• Abhängigkeiten: Der Erfolg und die Weiterentwicklung von Open Source-Software hängen häufig von der Unterstützung und der Aktivität einer Community ab. Es besteht das Risiko, dass ein Open Source-Projekt nicht mehr aktiv gepflegt wird oder die Entwicklergemeinschaft sich auflöst. Dies kann zu Herausforderungen bei der langfristigen Wartung und Unterstützung führen. Auf der anderen Seite können natürlich auch klassische Firmen ihren Geschäftsbetrieb einstellen, ohne dass ein Nachfolger bereitsteht. Bei Open Source-Software kann die Verantwortung auf eine breitere Gemeinschaft verteilt sein, was die Abhängigkeit von einem einzelnen Anbieter zu verringern hilft.
  Darüber hinaus sind freiwillige Entwicklergemeinschaften i.d.R. schneller in ihren Reaktionszeiten zu Sicherheitslücken. Benutzer müssen nicht darauf vertrauen, dass der Closed Source Anbieter schnell auf Sicherheitsbedrohungen reagiert und die notwendigen Updates bereitstellt.

• Lizenzierung: Die Einführung des SouvAP in der öffentlichen Verwaltung muss sicherstellen, dass die Lizenzbedingungen der verwendeten Open Source-Software richtig verstanden und eingehalten werden, um mögliche rechtliche Konflikte zu vermeiden.

5.4.3.3 Allgemeine Risiken in der Einführung des SouvAP

Neben eher allgemeinen Risiken, die jede größere Produktklasse im Rahmen der Digitalisierung betreffen existieren eine Reihe von spezifischen Risiken bei der Einführung des SouvAP:

• Gesellschaftliche Akzeptanz (Anspruch):
  Der SouvAP hat ein erhebliches Aufmerksamkeitspotenzial, da er in direktem Wettbewerb zu den weit verbreiteten kommerziellen Anbietern steht. Damit geht ein sehr hoher Anspruch an die Lösung einher, der erst einmal noch eingelöst werden muss.
  Dies umfasst z.B. die Erkenntnis, dass es keine ‚schwachen‘, unausgereiften Teile in der Lösung geben darf, oder es geht mit einer offenen Kommunikationsstrategie einher, die die Adressierung dieses Risiko zum Teil des Einführungsprozesses selbst macht.

• Nutzerspezifische Akzeptanz:
  Der individuelle Nutzer in der öffentlichen Verwaltung bekommt mit dem SouvAP eine Produktklasse, die er mit hoher Wahrscheinlichkeit in Form kommerzieller Produkte bereits kennt. Dadurch existiert eine individuelle Erwartungshaltung, was den Funktionsumfang, als auch die Laufzeitumgebung, Performance usw. des SouvAP betrifft.
  Es müssen geeignete Maßnahmen, wie z.B. Schulungen usw. durchgeführt werden, die die Akzeptanz zumindest nicht durch Unkenntnis schmälern.

• Akzeptanz durch die Leistungserbringer:
  Die Leistungserbringung durch die Softwarehersteller und -betreiber muss sich für sie selbst lohnen. Das umfasst nicht nur die Wirtschaftlichkeit, sondern auch weichere Faktoren wie Bekanntheitsgrad, Zuverlässigkeit, Renommee usw.
  Nur in einer tatsächlichen Partnerschaft der Beteiligten wird diese Akzeptanz zu erreichen sein.

• Wirtschaftlichkeit:
  Die Einführung des SouvAP wird mit erheblichen Kosten und komplexen Kostenstrukturen verbunden sein, einschließlich der Lizenzgebühren, der Schulung von Mitarbeitern, der Anpassung oder Integration in bestehende Systeme und der laufenden Wartung und Aktualisierung. Es besteht das Risiko von Kostenüberschreitungen, insbesondere wenn die Teilprojekte nicht gut geplant sind oder das Budget nicht angemessen festgelegt wurde.
  Hinzu kommt, dass mit dieser Klasse von Arbeitsmitteln die Messung tatsächlicher Produktivitätsgewinne und damit die Gründe für Investitionen sehr schwierig zu ermitteln sind.

5.4.3.4 Spezifische Risiken mit der Einführung des SouvAP

• Technische Probleme:
  Bei der Einführung des SouvAP besteht das Risiko technischer Probleme wie fehlerhafter Installation, nicht gegebener Interoperabilität, Inkompatibilität mit bestehender Infrastruktur, Softwarefehlern oder Performance-Problemen. Solche Probleme können zu Betriebsunterbrechungen, Datenverlust und Frustration bei den Nutzern führen.

• Datenmigration und -integrität:
  Die Übertragung von Daten von alten Systemen auf den neuen SouvAP kann ein komplexer Prozess sein. Es besteht das Risiko von Datenverlust oder -beschädigung während der Migrationsphase. Darüber hinaus müssen die Daten in der neuen Software korrekt und konsistent integriert werden, um die Datenintegrität sicherzustellen.
  Insbesondere in der Öffentlichen Verwaltung existiert eine Vielzahl von Bestandsdokumenten, die nicht nur der Anzahl wegen Aufmerksamkeit verlangen, sondern auch wiedergabetreu sein müssen.

• Performance:
  Der SouvAP ist als reine Cloud-Lösung geplant und damit insbesondere von der jeweiligen Netzinfrastruktur abhängig, um performant zu sein.
  Hier gilt es von vornherein Offline-Fähigkeiten für den Fall zeitweiser Netzwerkunterbrechungen zu implementieren.

Es ist wichtig, dass alle Partner in der Implementierung des SouvAP diese Risiken kennen und angemessene Maßnahmen ergreifen, um sie zu adressieren und zu minimieren. Dies kann die Durchführung einer sorgfältigen Risikobewertung, die Implementierung von Sicherheitsmaßnahmen und die gesonderte Einbindung von Fachleuten umfassen, um den sicheren und effektiven Einsatz des SouvAP in der öffentlichen Verwaltung zu gewährleisten.

1. Vgl. https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap07.html↩︎

2. Vgl. 6 Digital Workplace Trends on the Gartner Hype Cycle for the Digital Workplace, 2020↩︎

3. Vgl. Digitalstrategie: Digitaler Aufbruch | Bundesregierung↩︎

4. Vgl. Digitalstrategie Deutschland | Digitalstrategie Deutschland (digitalstrategie-deutschland.de)↩︎

5. Vgl. https://digitales.hessen.de/moderne-verwaltung/strategie-digitale-verwaltung↩︎