3. Vorbereitungen

3.1 Ausgangslage

3.1.1 Verfügbare Vorgehensmodelle für die Architekturarbeit

Die Architektur zum SouvAP behandelt die drei Phasen

• Planung – Sammlung von Anforderungen, was der SouvAP leisten muss,

• Aufbau – Transformation der Anforderungen auf Service-Bereitstellungen – und

• Betrieb – Erbringung der Services gemäß geltender Dienstgütevereinbarungen.

Das Vorgehen in der Planung soll die Architekturdomänen

• Geschäftsarchitektur,

• Informationssystem- und Datenarchitektur und

• Infrastrukturarchitektur

differenzieren.

Zu jeder dieser drei Architekturdomänen wurden in den letzten Jahren unterschiedliche Vorgehensmodelle entwickelt, die im Kern die Transformation eines Ist-Zustands zu einem Soll-Zustand adressierten. Aufgrund der fortschreitenden IT-Durchdringung in praktisch allen Lebensbereichen hat sich in den letzten Jahren eine ganzheitliche Behandlung aller drei Architekturdomänen in einem übergreifenden Vorgehensmodell durchgesetzt. Aktuell wird international die Architektur-Entwicklungsmethode gemäß TOGAF (The Open Group Architecture Framework) präferiert. Dort sind die zuvor genannten Phasen Planung, Aufbau und Betrieb mitberücksichtigt.

Aufgrund der hohen Anforderungen der verwalterischen Datenverarbeitung an regulatorische Vorgaben deckt die Vorgehensweise gemäß TOGAF jedoch nicht alle benötigten Aspekte einer Architektur eines SouvAP für die öffentliche Verwaltung ab. Zum einen behandelt TOGAF selbst in keiner Weise Sicherheitsaspekte, zum anderen macht TOGAF keine Vorgaben zu Betriebsprozessen. Zu diesen zwei Aufgabenstellungen kann sich die Architektur zum SouvAP an den folgenden Rahmenwerken bedienen:

• IT Grundschutz (BSI) diskutiert Gefahren bei der Datenverarbeitung aus Sicht des Anlagenbetreibers. Ein umfangreicher Katalog an Maßnahmen adressiert den Schutz des kompletten IT-Infrastrukturverbunds über alle Phasen seines Lebenszyklus, also ab Planung über Beschaffung und Betrieb bis zur Dekommisionierung.

• ITIL bündelt Leitlinien, die auf die Bereitstellung von IT-Services in hoher Qualität fokussieren. ITIL beschreibt Vorgehensweisen, mit denen ein IT-Dienstleister komplexe Aufgaben des IT-Betriebs ab Planung über Inbetriebnahme, Betrieb, Wartung und Aussonderung effizient und mit geringem Fehlerrisiko umsetzen kann.

Aspekte zur Sicherheit sind als Querschnittsdomäne zu betrachten, faktisch also in die Phasen Planung, Aufbau und Betrieb sowie in die Ausgestaltung der Architekturdomänen Geschäftsarchitektur, Informations- und Datenarchitektur sowie Infrastrukturarchitektur einzubeziehen. Für die zuletzt genannten Architekturdomänen hat die Sherwood Applied Business Security Architecture SABSA ein Vorgehensmodell entwickelt, das in TOGAF integriert werden kann.

3.1.2 Einflussnehmende strategische Dokumente

Die folgenden strategischen Dokumente beeinflussen die Ausgestaltung der Architekturarbeit:

• Nationale E-Government Strategie,

• Deutsche Verwaltungscloud Strategie,

• IT-Strategie des Bundes,

• IT-Strategien/Digitalstrategien der Länder (z.B. Freie und Hansestadt Hamburg, Hansestadt Bremen, Sachsen-Anhalt, Schleswig-Holstein),

• Zielbilder der öffentlichen RZ-Dienstleister.

3.1.3 Geschäftsprinzipien, Geschäftliche Ziele

An dieser Stelle sind geschäftliche Prinzipien und Ziele herausgestellt, die übergreifend Einfluss auf jede Architekturdomäne nehmen sollen:

• Risikobewusstsein,

• Wirtschaftlichkeit,

• Investitionssicherheit,

• Zukunftsfähigkeit,

• Robustheit,

• Effektivität,

• Qualität,

• Kundenzufriedenheit,

• Informationssicherheit,

• Datenschutz und

• Geheimschutz.

Die genannten Schlagwörter sind in den zuvor genannten IT-Strategien und in den Zielbildern der öffentlichen Verwaltungen als strategische Ziele herausgestellt. Die Auswahl wurde auf Ziele konzentriert, die für den SouvAP als relevant eingestuft werden.

3.1.4 Übergreifende Rahmenbedingungen

Des Weiteren wird die Architekturarbeit durch die folgenden unternehmerischen und rechtlichen Rahmenbedingungen flankiert:

• Verwaltungsvorschriften,

• betriebliche Richtlinien und Standards der beteiligten Organisationen,

• geltende Gesetze, z.B. Datenschutzgrundverordnung, IT-Sicherheitsgesetz.

3.1.5 Anvisierter Geschäftsnutzen der Architekturarbeit

Die Architekturarbeit zum SouvAP will Bund, Länder und Kommunen in die Lage versetzen, ebenen-übergreifend standardisiert medienbruchfrei und souverän verwalterische Geschäftsprozesse mit digitalen Werkzeugen zu bewältigen. Sie will damit einen wesentlichen Beitrag zur Modernisierung des Staates liefern. Der SouvAP will dabei die Voraussetzungen für eine digitale Autonomie schaffen und somit die digitale Souveränität des Staates fördern.

3.1.6 Beteiligte Unternehmen und Partner

Der SouvAP wird in einer kollaborativen, offenen und effektiven Zusammenarbeit innerhalb der öffentlichen Verwaltung (ÖV) erstellt. Die Softwarebasis wird aus vorhandenen Open Source (OS) Ökosystemen assembliert. Dazu zählen initial die Nextcloud GmbH, die OpenXchange AG, Univention und Element. Die technische Konzeption, die Umsetzung und die Erprobung des SouvAP sollen der IT-Dienstleister Dataport und die beteiligten OS-Hersteller vorantreiben.

3.1.7 Organisationsmodell für Architekturarbeit

Die Leistungsbeschreibung zum SouvAP sieht die Einrichtung eines Architekturboards für die Spezifikation der grundlegenden technischen Architektur des SouvAP vor. Dort sind das BMI, Dataport und weitere Teilnehmende aus der ÖV beteiligt. Die OS-Hersteller werden durch Univention vertreten. Das Architekturboard soll Architektur-Empfehlungen bzw. Entscheidungsvorlagen an die Projektsteuerung und die technische Entwicklung liefern.

Im technischen Beirat (Produktstrategieboard) konzentrierte Aufgaben sollen Vertreter des BMI, von Dataport und von OS-Herstellern umsetzen. Hier ist der Austausch mit dem OS-Ökosystem zur Umsetzung von Anforderungen, dem Einsatz und der Weiterentwicklung von OS-Produkten zu betreiben und es sind Produkte und Weiterentwicklungspotentiale zu diskutieren bzw. deren Umsetzungspläne im Detail auszuarbeiten.

Ein User Experience-Board soll (strategische) Anforderungen der ÖV identifizieren und die Erprobung des SouvAP durchführen. Im User Experience-Board sind insbesondere Teilnehmende der ÖV vertreten (z. B. Betreiber und Nutzende der ÖV).

3.2 Architekturvorhaben

3.2.1 Abgrenzung beteiligter Organisationseinheiten

Der SouvAP wurde vom BMI initiiert mit dem Ziel, den Bediensteten der öffentlichen Verwaltung einen umfänglichen digitalen Werkzeugkasten für Aufgaben der Produktion, Kommunikation, Kollaboration und (übergreifend) die Anbindung ausgewählter Fachverfahren (z.B. E-Akte) zur Verfügung zu stellen. Damit steht das BMI in der Rolle des Auftraggebers und die Bediensteten der öffentlichen Verwaltung nehmen die Rolle der Nutzenden ein.

Im Zuge der Architekturarbeit übernimmt das Architekturboard die Architektenrolle. Der technische Beirat übernimmt die Entwicklerrolle und wird dabei durch das OS-Ökosystem unterstützt. Produktentscheidungen obliegen dem Auftraggeber.

Dataport soll die Bereitstellung und den Betrieb des SouvAP in einer ersten Version wahrnehmen. In der Folge sollen der Betrieb, der Support und die Weiterentwicklung des SouvAP auf ein Partnernetzwerk innerhalb der öffentlichen Verwaltung ausgedehnt werden. Ergänzende Entwicklungs- und Supportverträge mit Anbietern auch aus dem Open Source Umfeld sollen die professionelle und nachhaltige Nutzung gewährleisten. Das Open Source Umfeld wird hier im weiteren Sinne dem OS-Ökosystem zugeordnet. Das Diagramm illustriert das Organisationsmodell und den Kommunikationsfluss zwischen den Organisationen.

Abbildung : Organisationsmodell und Kommunikationsfluss zwischen Organisationen

Anmerkung: Die Leistungsbeschreibung SouvAP stellt die grundsätzliche Rahmenbedingung „DVS-Konformität“. Die Digitale Verwaltungscloud-Strategie DVS unterscheidet Plattformbetreiber und Softwarebetreiber. Die Architekturentwicklung SouvAP trifft diese Unterscheidung zunächst nicht.

3.2.2 Einzusetzende Rahmenwerke und Steuerung der Architekturarbeit

Die Architekturarbeit folgt den Empfehlungen des Rahmenmodells TOGAF. Die gestaltenden Architekturphasen B bis D gemäß TOGAF werden durch eine Domäne Sicherheitsarchitektur ergänzt. Die Sicherheitsarchitektur greift die Empfehlungen des Rahmenwerks SABSA auf und wird als Querschnittsdomäne geführt.

Sämtliche Tätigkeiten betreffend der Vermittlung der Bedarfe und Anforderungen zwischen der ÖV und dem OS-Ökosystem sowie der Umsetzung der in der Leistungsbeschreibung genannten Teilprojekte und Leistungen zum SouvAP werden von einer Projektsteuerungsstruktur koordiniert und überwacht. Die übergreifende Projektsteuerung leisten ein Projektfortschrittsmonitoring, das Finanzcontrolling und das strategische Produktmanagement. Diese Aufgaben liegen in der Verantwortung des Auftraggebers.

3.2.3 Architekturteam

Die Architekturarbeit gemäß TOGAF ist als zyklisch iteratives Vorgehen konzipiert. TOGAF gruppiert die Einzelschritte in die Teilbereiche Planung, Transition und Betrieb (der neuen Architektur). Im Betrieb aufgedeckte Abweichungen vom geplanten Ziel und dort aufgedeckter Anpassungsbedarf können eine neue Iteration begründen. Diese ist formell über Änderungsanforderungen einzuleiten.

Das Design der Architektur (Vision, Geschäftsarchitektur, Informationssystemarchitektur, Infrastrukturarchitektur) ist durch das Architekturboard zu steuern und durch seine Mitglieder oder von den Mitgliedern beauftragten Organisationen auszugestalten. Ergebnisse der Designarbeit sind Entscheidungsvorschläge für eine technische Architektur, die durch den Auftraggeber zu bestätigen ist.

Die anschließenden Planungsphasen (Chancen und Produkte, Migrationsplanung) steuert der Technische Beirat. Hier ist ein enger Dialog mit dem OS-Ökosystem erforderlich. Das Ergebnis ist eine Liste von Produkten, die das Gremium zur Umsetzung der technischen Architektur empfiehlt. Die Produktentscheidung trifft der Auftraggeber.

Die Transition (Implementierungs-Governance) muss unter Einbindung und im Einklang mit den Erkenntnissen, Empfehlungen und Unterstützungsleistungen von Architekturboard, Technischem Beirat und User Experience-Board erfolgen.

Der abschließende Betrieb dieser ersten Iteration der Architekturentwicklung gemäß TOGAF-Vorgehensmodell ist die zuvor genannte Erprobung des SouvAP. Seine Durchführung steuert das User Experience-Board, also Betreiber und Nutzende der ÖV.

3.2.4 Architekturprinzipien

Die Leistungsbeschreibung verweist auf die Architekturrichtlinie des Bundes, die Standards der Deutschen Verwaltungscloud-Strategie und die Föderalen Architekturrichtlinien für die IT. Dazu fordert die Leistungsbeschreibung eine Prüfung auf Verwendbarkeit im SouvAP.

3.2.5 Architekturrichtlinie des Bundes

Im Dokument Architekturrichtlinie des Bundes sind 18 übergreifende Architekturvorgaben ausgearbeitet. Jeder Vorgabe ist eines oder mehrere strategische Ziele gemäß der IT-Strategie der Bundesverwaltung als Verweis zugeordnet. Des Weiteren ist jede Vorgabe mit einer Verbindlichkeit gemäß RFC 2119 geprägt, wird also mit einem Verbindlichkeitsgrad muss, soll, kann oder darf nicht assoziiert.

Der SouvAP übernimmt die übergreifenden Architekturvorgaben aus der Architekturrichtlinie des Bundes als Architekturprinzipien mit ihren Verbindlichkeiten wie folgt (Abweichungen der Verbindlichkeitsgrade gegenüber der Architekturrichtlinie des Bundes sind mit * gekennzeichnet):

3.2.5.1 Standards der Deutschen Verwaltungscloud-Strategie

Die Deutsche Verwaltungscloud-Strategie hat zum Ziel, gemeinsame Standards für die föderale Cloud-Infrastruktur der ÖV und deren Standorte zu definieren. Diese Standards sollen übergreifend für Bund, Länder und Kommunen sowie für deren IT-Dienstleister gültig werden. Für Teilnehmer an der Deutschen Verwaltungscloud ist die Umsetzung dieser Standards verpflichtend. Ausnahmen sind in begründeten Fällen möglich.

Die Standards der Deutschen Verwaltungscloud-Strategie richten sich an die Bereiche

1. Entwicklung und Entwicklungsplattform,

2. Anwendungsbereitstellung und -management,

3. Code Repository,

4. Infrastruktur-Service und technologischer Stack sowie

5. Betriebsstandards und Betriebsmodell.

Die Deutsche Verwaltungscloud-Strategie listet insgesamt 20 Standards nebst Verbindlichkeitsstufen gemäß RFC 2119. Der SouvAP übernimmt die folgenden Standards:

Die angegebenen Standards liegen aktuell in einer ersten Version vor (Kennung R01). Nach einer Fortschreibung auf der Seite der Deutschen Verwaltungscloud-Strategie ist die jeweils aktuelle Version gültig.

3.2.5.2 Föderale IT-Richtlinien

Der IT-Planungsrat hat 13 Föderale Architekturrichtlinien verfasst und diese passend zu einer additiven Betrachtung von Vorgaben entwickelt. Die Vorgaben wurden in die Dimensionen strategische Ziele (SR), normative Vorgaben (R), föderal relevant (Fö) und fachübergreifend (Fu) gruppiert. Die den daraus abgeleiteten Architekturrichtlinien jeweils zugeordneten Verbindlichkeiten folgen den Empfehlungen von RFC 2119 mit der Einschränkung, dass auf die Option „SOLL“ verzichtet wurde, da auch für „MUSS“-Anforderungen begründete Abweichungen und Ausnahmegenehmigungen zulässig sind.

Der SouvAP übernimmt die übergreifenden Architekturvorgaben aus den Föderalen Architekturrichtlinien mit ihren Verbindlichkeiten wie folgt:

Die Föderale Architekturrichtlinie SR12 Umsetzung des „Once Only“ Prinzips wird hier nicht übernommen, da ihr Fokus auf den Dialog von Bürgerinnen und Bürgern mir der Verwaltung liegt. Der SouvAP ist auf die verwalterische Geschäftsprozessunterstützung für Bedienstete der öffentlichen Verwaltung ausgerichtet.

3.2.6 Konfektionierung von Architektur-Frameworks für SouvAP

Für das Projekt SouvAP werden Architekturrichtlinien mit Bezug auf die Architekturrichtlinie des Bundes, die Deutsche Verwaltungscloud-Strategie und die Föderalen IT-Architekturrichtlinien zugrunde gelegt.

Die Architekturrichtlinie des Bundes hat für ihre Darstellungen die Formatvorlagen des TOGAF Frameworks adaptiert. Die Föderalen IT-Architekturrichtlinien verweisen auf die Notwendigkeit, die Gestaltung der föderalen IT-Architektur für Deutschland auf eine ganzheitliche Betrachtung auszurichten und orientiert sich dabei am Architekturframework TOGAF.

Die Deutsche Verwaltungscloud-Strategie trifft keine Vorgaben, nach welchem Schema Architekturarbeiten im Rahmen der Realisierung der Deutschen Verwaltungscloud durchzuführen sind. Die Vorlage der dort festgelegten Standards wurde an die der Architekturrichtlinie für die IT des Bundes angelehnt, ist also gewissermaßen TOGAF-konform.

Es bietet sich an, die Architekturarbeit zum SouvAP mit der der Methode gemäß TOGAF umzusetzen, zumal die auf das Zielbild einflussnehmenden Behörden des Auftragnehmers offensichtlich selbst bereits die Herangehensweise von TOGAF favorisieren und zumindest in Teilen adaptieren. Auch das in Deutschland für technische Sicherheitsstandards verantwortliche Bundesamt für Sicherheit in der Informationstechnik BSI weiß TOGAF zu schätzen und wendet den Optimierungsansatz „Architecture Development Method“ ADM in seinem Hochverfügbarkeits-Kompendium Band G an. Das Vorgehen: rekursive Verbesserung von IT-Ressourcen mit Blick auf die Qualitätsanforderungen der Geschäftsprozesse, um eine Hochverfügbarkeits-Konzeption betreffend Rest-Risiken zu optimieren.

Aufgrund der sicherheitsrelevanten Rahmenbedingungen ist die Kopplung mit einer Sicherheitsarchitektur erforderlich. Diese muss die systematische Entwicklung der Architekturdomänen Geschäftsarchitektur, Informationsarchitektur und Infrastrukturarchitektur begleiten. Die anschließende Implementierung bzw. Migration kann dadurch direkt auf sicherheitsrelevante Anforderungen zugreifen und es liegen auch bereits logische und technische Umsetzungshinweise vor. Nach aktueller Eischätzung ist hierfür das Vorgehensmodell SABSA zu favorisieren, da TOGAF dafür eine nahtlose Ergänzung dokumentiert hat.