Abbildung 8 zeigt den empfohlenen grundlegenden Aufbau der RA. Die Abbildung skizziert zudem das Zusammenspiel der RA mit ihrer „Umgebung“ (Nutzer bzw. Nutzergruppen, Systeme der öffentlichen Verwaltung). Die Architektur orientiert sich an dem etablierten Modell einer Mehrschichtenarchitektur, wie sie in SAGA 4.0 (siehe Kapitel 5.1) vorgeschlagen wird. Dieses Architekturmuster sieht eine Einteilung von Architekturelementen in voneinander isolierte Schichten vor. Dies hat verschiedene Vorteile: Zum einen sorgt die Trennung für eine Entkoppelung der Schichten und somit für ein hohes Maß an Flexibilität und gute Wartbarkeit, da eine Veränderung in einer Schicht keine Auswirkungen auf eine andere Schicht haben kann. Bspw. lässt sich so die verwendete Datenbank durch eine performantere ersetzen, wenn die Anforderungen an die Performance im Laufe der Zeit steigen.
Generell trägt die Aufteilung eines komplexen Systems in kleinere, weniger komplexe Bestandteile (Komponenten), die über definierte Schnittstellen miteinander kommunizieren, zur Beherrschbarkeit der Komplexität bei. Sie fördert bereits auf Architekturebene die Wartbarkeit, Flexibilität und Erweiterbarkeit des Systems. So lässt sich im Idealfall eine Komponente des Systems durch eine andere austauschen, ohne dass andere Komponenten angepasst werden müssten. Sie schafft zudem Übersichtlichkeit und verbessert das Verständnis für den Aufbau des Systems. Je nach Komplexität ist es üblich, große Komponenten wiederum in kleinere Komponenten zu zerlegen (Modularisierung). Zudem ist beim Schichtenmodell gefordert, dass ein Austausch von Daten nur zwischen direkt angrenzenden Schichten erfolgt, was sowohl zur Übersichtlichkeit und Verständlichkeit beiträgt wie auch zur Sicherheit des Systems.
Abbildung 8 Referenzarchitektur für E-Partizipationsprojekte in der Öffentlichen Verwaltung basierend auf dem Schichtenmodell nach SAGA 4.0
Die Einteilung in Schichten bildet somit eine sinnvolle und direkte Variante der Aufteilung in Komponenten. Es wird hier auf oberster Ebene zwischen Datenhaltung, Anwendungslogik, Präsentationslogik und Client-Schicht unterschieden. Dabei bildet die Datenhaltungsschicht eine Abstraktion für jede Form der langfristigen (persistenten) Datenhaltung. Sie wird deswegen oft auf als Persistenzschicht bezeichnet. Typischerweise kommt hier ein Datenbank-Managementsystem (DBMS) zum Einsatz, wie bspw. Oracle oder MySQL. Es ist aber auch jede andere Form der Datenhaltung denkbar, bspw. in Textdateien (auch wenn dies nicht empfehlenswert ist). Wichtig ist, dass die Datenhaltungsschicht eine definierte und bestenfalls standardisierte Schnittstelle bereitstellt, über die Daten abgerufen und gespeichert werden können. SQL (Structured Query Language) oder LDAP (Lightweight Directory Access Protocol) bilden solche. Sofern dieser Standard beachtet wird, lässt sich bspw. eine SQL-Datenbank gegen eine beliebige andere austauschen.
Die Anwendungslogik, oft auch Mittelschicht oder Geschäftslogik genannt, bildet die Funktionen des Systems (Geschäftsprozesse) ab (siehe Kapitel 4). Hier werden Daten verarbeitet und an angrenzende Schichten (etwa zur Speicherung oder zur Ausgabe an den Benutzer) weitergegeben, sowie ggf. Transaktionen mit externen Systemen abgewickelt. Im Falle von E-Partizipationslösungen werden bspw. Benutzereingaben aus der Präsentationsschicht (unten) entgegengenommen, geprüft, und im zur Speicherung an die Datenhaltungsschicht gegeben oder Daten von dort gelesen, aggregiert und zu Berichten zusammengefasst.
Die Präsentationsschicht bereitet die Daten aus der Anwendungslogik für die Präsentation auf einem Endgerät (Client, siehe unten) auf und verarbeitet umgekehrt Benutzerinteraktionen, die clientseitig getätigt werden, für die Anwendungslogik auf. Typischerweise geschieht die Darstellung via HTML, also als Webseite, was eine weitgehende Unabhängigkeit gegenüber verschiedenartigen Clients schafft, da nahezu alle gängigen Endgeräte mindestens einen Browser zur Darstellung und Interaktion mitbringen bzw. unterstützen.
Schließlich bildet der Client das Endgerät und somit die benutzerseitige „Endstufe“ der Anwendung. Sie unterstützt die direkte Interaktion mit dem Benutzer. Typischerweise handelt es sich um Desktop-Computer, Laptops, Tablet-PCs oder Smartphones. Neben Webseiten, die im Browser dargestellt werden, sind spezifische Anwendungsprogramme gängig. Letztere bieten oftmals Vorteile im Hinblick auf die Benutzerfreundlichkeit und Geschwindigkeit, sind jedoch aufwändig zu entwickeln und zu pflegen. Zudem müssen Anwendungsprogramme für verschiedene Clients (z.B. ein PC mit Windows-Betriebssystem) spezifisch entwickelt werden, was erhebliche Kosten darstellt. Gleiches gilt für Smartphone-Apps, die jeweils für eine bestimmte Plattform (bspw. Android oder iPhone) entwickelt werden müssen. Im Sinne der Wirtschaftlichkeit bildet eine responsive Webanwendung (siehe Kapitel 5.1.1) ein gutes Verhältnis zwischen Kosten, Benutzerfreundlichkeit und Abdeckung verschiedener Endgeräte.
Eine Umsetzung anhand verteilter Architekturmuster ist ebenfalls denkbar. So ist im Hinblick auf eine E-Partizipationsplattform möglich, dass verschiedene Bestandteile einer mehrstufigen Bürgerbefragung nicht von zentraler Stelle aus, sondern von verteilten Anbietern zusammengestellt werden. So empfiehlt SAGA im Hinblick auf verteilte Systeme das Modell der Service-orientierten Architektur (SOA) und entsprechende Standards (wie die Web-Service Description Language, WSDL). In den letzten Jahren (Stand 2017) sind sog. Microservices als Variante der der SOA populär geworden. (Microservices lassen sich als Spezialfall einer SOA betrachten, bei der die Aufteilung in möglichst eng abgegrenzte Aufgaben sowie die Unabhängigkeit voneinander im Vordergrund stehen. Microservices können zudem durchaus eigene Benutzerschnittstellen mit sich bringen, die dann über Integrationsmechanismen komponiert werden können.) Beide Muster gehen von einer mehr oder weniger starken Aufteilung einer komplexen Anwendung in einzelne, logisch abgrenzbare Dienste („Services“) aus, die durch unabhängige Teams, isoliert von den übrigen Diensten, entwickelt, gepflegt und betrieben werden und über definierte Schnittstellen miteinander kommunizieren. (Die räumlich-technische Verteilung des Systems ist dabei als Konsequenz einer erwünschten Dezentralisierung der Verantwortlichkeiten auf organisatorischer Ebene zu sehen. Auch hier sind eine Entkopplung der Komponenten, eine Reduktion der Komplexität und die Verbesserung der Wartbarkeit zentrale Zielsetzungen.)
Es ist dabei zu beachten, dass Architekturmuster generell (so auch SOA oder Microservices) bereits früh im Prozess der Softwareentwicklung festgelegt werden und nicht für eine spätere, „nachträgliche Anwendung“ mit existierenden Produkten gedacht sind, die i.Allg. ebenso wenig für ein Zusammenspiel als Dienste im Rahmen einer SOA konzipiert sind wie für eine Aufteilung in Microservices. SOA oder Microservies sollten daher nur in Betracht gezogen werden, wenn (a) eine komplette Neuentwicklung (Fall 1, Kapitel 5.3.2) geplant ist und (b) der verteilte Aufbau und damit einhergehend eine Aufteilung der Verantwortlichkeiten erwünscht (oder nicht vermeidbar) ist.
Unklarer Bezug zwischen Text und Grafik. Wünschenswert wäre, dass sich die Schicht-Beschreibung einfach in der Grafik erkennen lässt.
