5.3.4 Interoperabilität als Schlüsselanforderung

Die generelle Forderung nach Interoperabilität soll hier mit Bezug zur RA konkretisiert werden (siehe Kapitel 5.1.3 und 5.3.1; die Begriffe Interoperabilität und Integration werden im Rahmen dieses Kapitels als synonym betrachtet. Streng genommen bildet Interoperabilität die Voraussetzung für eine effektive und einfache Integration). So wird Interoperabilität für verschiedene Teile der RA gefordert: Zum einen geht es (1) um das Zusammenspiel der internen Komponenten (Backend-Integration), deren Kompatibilität nicht in jedem Fall vorausgesetzt werden kann. Weiterhin geht es (2) um das Zusammenführen der Ein- und Ausgabeschnittstellen der Komponenten zu einer einheitlichen Benutzerschnittstelle sowie um eine mögliche Einbettung in bestehende Webauftritte (Frontend-Integration). Schließlich geht es (3) um die Integration in die Geschäftsprozesse der öffentlichen Verwaltung, die Medienbrüche eliminiert und eine effiziente Einrichtung und Auswertung erlaubt. Die hier genannten Schnittstellen und Standards sind konform mit der „Referenzarchitektur elektronische Verwaltungsarbeit“, die auf dem „Organisationskonzept elektronische Verwaltungsarbeit“ aufbaut. Beide werden als vertiefende Lektüre zur elektronischen Verwaltungsarbeit im Sinne der E-Akte empfohlen.

Abbildung 9 stellt einen Detailausschnitt von Abbildung 8 dar, der die für Integration zuständigen Komponenten („Integrationsdienste“) genauer beleuchtet. Mit Blick auf die oben gennannten zentralen Zielsetzungen sollen die Integrationsdienste dafür sorgen, dass das Gesamtsystem wirtschaftlich (weitgehend unter Verwendung existierender Komponenten) entwickelt werden kann und (trotzdem) den definierten Qualitätsansprüchen gerecht wird.

Abbildung 9   Front- und Backend-Integration sowie Integration externer Systeme durch Integrationsdienste

Frontend-Integration

Im Sinne der Usability ist es wünschenswert, dass eine Bürgerbefragung „aus einem Guss“ erscheint und eine einheitliche, harmonische Oberfläche und konsistente Navigation ohne sichtbare Brüche bietet – auch wenn sie sich auf technischer Ebene aus verschiedenen Komponenten zusammensetzt (siehe Kapitel 5.3.3, oben). Die Herausforderung dabei liegt darin, dass Hersteller typischerweise eine eigene Web-Oberfläche basierend auf möglicherweise abweichenden Technologien (PHP, Java, Apache Tomcat) bereitstellen. Die Frontend-Integration sorgt dafür, dass diese sich nach Möglichkeit nahtlos in eine einheitliche Oberfläche einbinden und über eine übergeordnete, konsistente Navigation ansteuern lassen. Hierfür existiert auf technischer Ebene eine Reihe von Möglichkeiten, die eigene Vor- und Nachteile mit sich bringen und abhängig vom gewählten Entwicklungsansatz sind (siehe Kapitel 5.3.2).

Abbildung 8 zeigt grundlegende Möglichkeiten der Frontend-Integration (siehe auch: Link). Sofern die verwendeten Komponenten bereits ein eigenes Web-Interface bieten, können diese nebeneinander „stand-alone“ betrieben werden. Durch gegenseitige Verlinkung auf die jeweils anderen Komponenten lässt sich eine Navigationsstruktur erzeugen (1). Diese Form der Integration ist mit minimalem Aufwand zu erzeugen, bietet jedoch keine einheitliche, harmonische Oberfläche. Bei Option (2) werden die Web-Schnittstellen der einzelnen Komponenten in bestehende Seiten eingebettet. Dies kann durch recht einfach mittels IFrames geschehen oder durch Nutzung von Einbettungs-Mechanismen, sofern diese die durch Komponenten bereitgestellt werden (bspw. durch Verwendung AJAX-Technologien oder MVC-Frameworks wie Angular JS). Wird diese Form der Einbettung durch die Komponenten nicht unterstützt, so ist der Aufwand für diese Form der Integration beträchtlich. Zudem ist der Einsatz von JavaScript erforderlich. Die beiden ersten Optionen sind geeignet, wenn auf bestehenden Systemen aufgebaut wird (Entwicklungsansatz 2 oder 3 oben). Sofern eine komplette Neuentwicklung angestrebt wird (Entwicklungsansatz 1) bietet Option (3) die größte Flexibilität und den größten Komfort für Nutzer. Dabei wird bereits auf der Mittelschicht ein einheitliches, übergreifendes Benutzerinterface für alle Komponenten erzeugt, die entsprechende Schnittstellen bieten. Hierfür können auch Portal-Systeme verwendet werden, die einzelne Dienste als „Portlets“ kapseln, die unabhängig voneinander entwickelt werden können.

Abbildung 10   Grundlegende Möglichkeiten der Frontend-Integration

Ein weiterer Aspekt der Frontend-Integration sind die Möglichkeiten der Bereitstellung für einen Mandanten. Hier lassen sich folgende sinnvolle Ausprägungen unterscheiden: (a) Einbettung in den Webauftritt des Mandanten und (b) zentrale Bereitstellung auf eigener Plattform und (c) eine Kombination aus beidem. So haben die Ausprägungen a und b im Sinn einer guten User-Experience (siehe Unterkapitel 1) beide ihre Berechtigung. Die Einbettung in einen bestehenden Webauftritt kann dabei mit den oben erwähnten Technologien der Einbettung erfolgen (siehe Option 2 oben) und unterliegt denselben Restriktionen.

Empfehlung: Es sollte nach Möglichkeit die technischen Voraussetzungen für Variante (c) geschaffen werden, so dass eine Bürgerbefragung direkt in den Webauftritt des Mandanten integriert ist und gleichzeitig „gespiegelt“ auf einer zentralen Plattform erscheint. Welche Möglichkeiten der Einbettung das System liefern muss, ist eine Richtungsentscheidung, die vorab getroffen werden muss, da sie Implikationen auf den zu wählenden Entwicklungsansatz hat.

Backend-integration

Zum anderen muss ein Datenaustausch zwischen den verwendeten Komponenten gewährleistet sein, etwas um ein gemeinsames Benutzerverzeichnis zu verwenden oder um Ergebnisse aus einer Bürgerbefragung in einer anderen Komponente weiterzuverwenden. Zudem ist eine redundante Datenhaltung eine typische Fehlerquelle und sollte im Sinne der Wartbarkeit nach Möglichkeit vermieden werden. Um die Interoperabilität zwischen Komponenten verschiedener Hersteller sicherzustellen, muss ggf. ein Backend-Integrationsdienst für eine Übersetzung und Kopplung der jeweiligen Datenmodelle sorgen, bspw. durch „Adapter“, die auf Schnittstellen einer Komponente zugreifen und die Daten für eine andere aufbereiten. Auch hier existieren multiple Möglichkeiten, die den Rahmen dieses Dokumentes sprengen würden.

Integration in Geschäftsprozesse

Eine weitere wichtige Aufgabe ist die Anbindung an die Infrastruktur der öffentlichen Verwaltung. Zu diesem Zweck ist eine weitere Integrations-Komponente für die Integration externer Systeme vorgesehen (in Abbildung 7 rechts). Prinzipiell liegt es im Ermessen des Vorhabenträgers, welche Schnittstellen eine Plattform bieten muss um sich sinnvoll in die öffentliche Infrastruktur und die eigenen Geschäftsprozesse einbinden zu lassen. Nachfolgend werden Vorschläge gegeben, welche Schnittstellen und Datenformate im Rahmen von E-Partizipationsprojekten typischerweise sinnvoll sind und unterstützt werden sollten. Die hier gegebenen Empfehlungen orientieren sich an SAGA 5.0 (Stand Nov. 2011), schließen jedoch auch aktuelle Entwicklungen und verbreitete Formate und Schnittstellen mit ein, die nicht notwendigerweise durch SAGA empfohlen sind. mit ein. Aus Platzgründen können an dieser Stelle nur Hinweise gegeben werden. Eine vertiefende Recherche obliegt dem Leser.

Empfehlung: Im Sinne der Informationssicherheit (siehe Kapitel 5.1.7) sollte jeglicher Datenaustausch zwischen E-Partizipations-Plattform und externen Systemen verschlüsselt erfolgen.

Exportfunktionen für Office- und Statistik-Tools

Die Möglichkeiten zum Export von Ergebnissen von Bürgerbeteiligungen gehört zu den Minimalanforderungen. Hier sollten, je nach Herstellerunterstützung, verschiedene Formate unterstützt werden

• Informationsaustausch und Informationsaufbereitung

○ Text (bspw. PDF, TXT, HTML)

○ Tabellen (bspw. PDF, CSV)

○ Strukturierter Export (bspw. XML, JSON)

• Dokumentenformate zur Weiterbearbeitung

○ Text (bspw. MS Word, ODT)

○ Tabellen (bspw. MS Excel, ODS, CSV)

Identitäts- und Zugriffsmanagement (Identity and Access Management, IAM)

Die Anbindung an Verzeichnisdienste ist für verschiedene Anwendungszwecke vorteilhaft. Durch ein zentrales Benutzerverzeichnis wird doppelte Datenhaltung vermieden. Zudem erleichtert es die Umsetzung eines Single-Sign-On (SSO) für Benutzer, die sich an mehreren Bürgerbeteiligungen beteiligen. Für Verwaltungsmitarbeiter kann der Zugang zum System ebenfalls erleichtert werden, wenn evtl. existierende Benutzerdaten für das E-Partizipationssystem wiederverwendet werden.

• Verzeichnisdienste und Protokolle

○ Lightweight Directory Access Protocol (LDAP)

○ OpenLDAP, MS Active Directory

• Authentifikationsprotokolle

○ OAuth 2.0

○ OpenID Connect

○ Security Assertion Markup Language (SAML)

Zur Erläuterung: Ein gemeinsames zentrales Benutzerverzeichnis (bspw. ein OpenLDAP-Server) ermöglicht es Benutzern, verschiedene Teile einer vernetzten (Web-) Anwendung mit denselben Zugangsdaten (Benutzername und Kennwort) zu verwenden. Dies erhöht Sicherheit und Komfort u.a. dadurch, dass das Kennwort nur noch einmal übertragen werden muss und nicht mehrere (potenziell unsichere) Kennwörter verwendet werden müssen. Diese Technik wird oft in Kombination mit SSO verwendet. Mittels SSO ist es möglich einem Benutzer nach einmaliger Anmeldung Zugriff auf alle Bestandteile einer vernetzten (Web-) Anwendung zu gewähren. Dies zielt in erster Linie auf den Komfort des Benutzers ab, der sich nicht mehrfach anmelden muss um verschiedene Teile der Anwendung zu nutzen.

Einbindung in Geschäftsprozesse der öffentlichen Verwaltung

Um die E-Partizipationsplattform effektiv in Systeme der öffentlichen Verwaltung einzubinden, sollte diese standardisierte Schnittstellen bereitstellen. Auf diese Weise lassen sich Vorgänge automatisieren (bspw. das zeitgesteuerte Auslesen von Daten oder das Einspielen aktueller Informationen). Zum Zwecke der elektronischen Aktenführung (E-Akte), die ab 2020 in der öffentlichen Verwaltung verbindlich umgesetzt werden muss, ist eine direkte Anbindung an Dokumentenmanagementsysteme über Standardschnittstellen hilfreich (unten).

• Standardisierte Schnittstellen zur Steuerung und zum Datenaustausch

○ WebServices (SOAP, REST)

• Anbindung an Dokumentenmanagementsysteme (DMS), Enterprise-Content-Management-Systeme (ECMS) und Dateisysteme (vgl. „Organisationskonzept elektronische Verwaltungsarbeit“)

○ CMIS, CIFS, WebDAV, JCR, IMAP, XDOMEA

• Austausch raumbezogener Daten (bspw. Bauleitplänen, Raumordnungsplänen und Landschaftsplänen)

○ XPlanung, ein Datenaustauschformat zum „verlustfreien Austausch von Bauleitplänen, Raumordnungsplänen und Landschaftsplänen“

• Einbindung von OpenData-Quellen

○ OParl, ein offener Standard zur Bereitstellung offener Daten über eine WebService-Schnittstelle

Import und Export von Geo-Daten und Kartenmaterial

Mit Blick auf Bürgerbefragungen zu einer räumlichen Planung (Kapitel 4.2) sollte die Möglichkeit bestehen, eigene Geo-Daten zu importieren und Kartenmaterial von Kartendiensten (wie z.B. Open-Street-Map) zu importieren.

• Import von Geo-Daten

○ ShapeFile / GeoJSON

• Anbindung an Kartendienste / Abruf von Kartenmaterial

○ Web Map Service (WMS)

○ Open-Street-Map-Tile-URL

Schriftformersetzende elektronische Verfahren

Soweit durch den Gesetzgeber zulässig, kann in bestimmten Fällen die Schriftform durch ein angemessenes elektronisches Verfahren ersetzt werden. Dies betrifft die formellen Beteiligungsverfahren mit Schriftformerfordernis. Hierdurch lassen sich die Vorteile der Digitalisierung nutzen und das Konzept der E-Partizipation wird konsequent zu Ende gedacht. Diese Möglichkeiten sind im Vorfeld durch den Vorhabensträger zu überprüfen. Anerkannte elektronische Verfahren eignen sich zur Authentifizierung textueller Inhalte aus Webformularen mittels elektronischer ID (eID) wie auch zur Zustellung signierter Dokumente.

• Authentifikation über Webformulare

○ Formulare mit elektronischer ID (eID) des neuen Personalausweises (nPA) (Quelle: Technische Richtlinie TR-03107-2 Elektronische Identitäten und Vertrauensdienste im E-Government (BSI))

• Zustellung von elektronischen Dokumenten

○ Qualifizierte elektronische Signatur (QES) (Quelle: Grundlagen der elektronischen Signatur (BSI))

○ De-Mail (Quelle: De-Mail (BSI))

Zur Erläuterung: Bei der qualifizierten elektronischen Signatur werden keine Anforderungen an den Nachrichtenkanal des Zugangs gestellt. Es kann sich um eine Zustellung per (normaler) E-Mail, File-Transfer (FTP / SFTP) oder eine formularbasierten Dokumentenupload handeln. Allein die Signatur des Dokumentes entsprechend SigG, SigV, EU-VO 910/2014 (eIDAS) ist ausschlaggebend für die Authentizität des Zustellers. Auf Empfängerseite muss eine Prüfung stattfinden, dass der Unterzeichner des Zertifikates der Sender des Dokumentes ist. Ist die Prüfung erfolgreich, so kann das Dokument für die weitere Verwendung über o.g. Schnittstellen den Verwaltungsprozessen zugänglich gemacht werden.

Die Verwendung der De-Mail stellt im engeren Sinne keine Anforderung an die Plattform direkt dar, sondern muss durch den Empfänger als zulässiges Verfahren bekanntgegeben sein. Zudem müssen sowohl Empfänger als auch Sender Zugang zur De-Mail haben, d.h. ein De-Mail-Konto eines akkreditierten Anbieters.

Die Verwendung der eID in Online-Diensten zur Authentifizierung des Nutzers ist an eine Reihe von Voraussetzungen geknüpft (siehe eID-Funktion (Online-Ausweisfunktion) des neuen Personalausweises (nPA)). Der Dienstanbieter muss über ein Berechtigungszertifikat verfügen und Zugriff auf einen eID-Service haben (bzw. einen solchen selbst betreiben). Benutzer müssen über den neuen Personalausweis und ein entsprechendes Karten-Lesegerät verfügen. Die eID-Funktion muss dabei freigeschaltet sein.