Startseite der Beteiligung
Dialog IT-Planungsrat | Open Government Moderne Verwaltung

Öffentlichkeitsbeteiligung zur Referenzarchitektur für E-Partizipationssoftware

Inhaltsverzeichnis

  • Referenzarchitektur für E-Partizipationssoftware
    • 2 Einführung E-Partizipation
    • 3 Anforderungen an die Software: Basisfunktionen
      • 3.1 User Stories
      • 3.2 Arbeitsprozesse beachten
    • 4 Konkrete Anwendungsfelder: Szenario-spezifische Anforderungen
      • 4.1 Szenario 1: Rückmeldungen zu einem Text einholen
        • 4.1.1 User Stories
        • 4.1.2 Notwendige und wünschenswerte Anforderungen
        • 4.1.3 Exkurs: Innovative Ansätze für E-Partizipation
      • 4.2 Szenario 2: Rückmeldungen zu einer räumlichen Planung einholen
        • 4.2.1 User Stories
        • 4.2.2 Notwendige und wünschenswerte Anforderungen
        • 4.2.3 Exkurs: Innovative Ansätze für E-Partizipation
      • 4.3 Szenario 3: Ideen zu einem Thema sammeln
        • 4.3.1 User Stories
        • 4.3.2 Notwendige und wünschenswerte Anforderungen
        • 4.3.3 Exkurs: Innovative Ansätze für die Anwendung der Funktionen
      • 4.4 Auswertung von Beteiligungsverfahren
    • 5 Technische Umsetzung
      • 5.1 Nicht-funktionale Anforderungen und Spezifikation
        • 5.1.1 Usability, Barrierefreiheit und Responsivität
        • 5.1.2 Mandantenfähigkeit
        • 5.1.3 Interoperabilität
        • 5.1.4 Operabilität
        • 5.1.5 Wartbarkeit, Erweiterbarkeit und Flexibilität
        • 5.1.6 Skalierbarkeit, Performanz und Verfügbarkeit
        • 5.1.7 Informationssicherheit und Datenschutz
        • 5.1.8 Open-Source-Basis
        • 5.1.9 Unterstützung offener Standards
        • 5.1.10 Exkurs: Innovative Ansätze für E-Partizipation
      • 5.2 Strukturelle Merkmale und Rahmenbedingungen
      • 5.3 Referenzarchitektur für E-Partizipationslösungen
        • 5.3.1 Zielsetzungen einer Referenzarchitektur
        • 5.3.2 Entwicklungsansätze
        • 5.3.3 Aufbau der Referenzarchitektur für E-Partizipationslösungen
        • 5.3.4 Interoperabilität als Schlüsselanforderung
        • 5.3.5 Exemplarischer Aufbau
42 von 43

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.

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

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-alonebetrieben 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 Portletskapseln, die unabhängig voneinander entwickelt werden können.

Grundlegende Möglichkeiten der Frontend-Integration

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 gespiegeltauf 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.

42 von 43

2 Beiträge

Sortieren nach:
Datum
Anzahl Kommentare
Anzahl Bewertungen

Technologiebewertung?

"Abbildung 8 zeigt grundlegende Möglichkeiten der Frontend-Integration (siehe auch: https://www.innoq.com/blog/st/2014/11/web-based-frontend-integration/). 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). " Warum wird in einem Referenzdokument auf die Webseite eines Unternehmes verlinkt? Siehe https://www.innoq.com/blog/st/2014/11/web-based-frontend-integration/ Warum wird hier eine konkrete Technologie genannt wie Angular JS? Bitte weitere nennen oder entfernen - ansonten besteht die Gefahr von wertenden Tendenzen für Technologien die nichts in einem solchen Referenzdokument verloren haben. Welches Werkzeug (Framework, Programmiersprache) man einsetzt hat nichts mit dem grundsätzlichen Gedanken von MVC als Pradigma oder AJAX als Technik zu tun.

Geo Standards und Formate

"Import und Export von Geo-Daten und Kartenmaterial" Da in diesem Dokument SAGA mehrfach referenziert wird und explizit von Karten gesprochen wird sollten außerdem weitere Formate und Standards genannt werden. SAGA referenziert die OGC Standards - die auch im INSPIRE Kontext - genutzt werden. Hier sind WMS; WFS, WMTS und WCS zu nennen. OSM Tiling Schemes sind nett, aber kein Standard sondern ein Community Standard und wird nicht offiziell von Deutschen Verwaltungen genutzt. Für performante Kartendarstellungen sind WMTSe das Mittel der Wahl. Die Auflistung der Standards finden sich in den SAGA Dokumenten. Weitere Schnittstellen (z.B. Restful Interfaces) und JSON basierte Formate sind im speziellen bei mobilen Anwendungen für den Datenaustausch und die Performance wichtig, weil viele wohl etablierte Geo Standards auf XML setzen bei denen zu viel nutzlose Boilerplate mitgeschliffen wird (Datenvolumen).

Gegenstände

Übersicht

Informationen

Übersicht
  • Hintergrund zur Beteiligung
  • Design Thinking-Workshop
  • Entwurf Referenzarchitektur (Download *.pdf 1.8 MB)
zum Seitenanfang
Anmelden

Anmelden

Anmelden

Datenschutzeinstellungen

Es werden für den Betrieb der Seite technisch notwendige Cookies gesetzt. Darüber hinaus können Sie Inhalte von Drittanbietern erlauben. Ein Widerruf ist jederzeit möglich.
Weitere Informationen finden Sie unter Datenschutzerklärung und Impressum.