Referenzarchitektur Frontend
Die Referenzarchitektur Frontend beschreibt die grundlegenden Rahmenbedingungen sowie die architekturellen Leitlinien für die Entwicklung des IT-Systemtyps Frontend in Anwendungen. Sie dient als verbindliche Grundlage für die Gestaltung und Umsetzung benutzerorientierter Komponenten im Kontext moderner Geschäftsanwendungen.
Wie in Einbettung Frontends in der fachlichen Referenzarchitektur dargestellt, erfolgt grundsätzlich eine Unterteilung der Geschäftsanwendung (GA) in zwei IT-Systeme: das Backend (GK) zur Bereitstellung fachlicher Logik und Services sowie das Frontend (GKGUI) als Benutzeroberfläche zur Interaktion mit dem Anwender.
Diese softwaretechnische Trennung erfolgt ausschließlich aus technologischen und organisatorischen Gründen: Frontend und Backend können unabhängig voneinander entwickelt, betrieben und skaliert werden und setzen in der Regel unterschiedliche Technologien sowie potenziell getrennte Entwicklungsteams ein. Aus Sicht der Anwender bleibt die Anwendung dabei weiterhin als einheitliches System wahrnehmbar.
Dieses Strukturprinzip gilt analog für Querschnittsanwendungen (QA), die entsprechend in QK (Backend) und QKGUI (Frontend) gegliedert werden.
Die Referenzarchitektur Frontend fokussiert sich auf die Beschreibung von Rahmenbedingungen und konzeptionellen Leitlinien für den IT-Systemtyp Frontend sowie dessen Interaktion mit anderen IT-Systemtypen, insbesondere dem Backend, zu dem aufgrund der Darstellung und Verarbeitung fachlicher Anwendungsfälle in der Regel eine enge funktionale Kopplung besteht.
1. Zielbild & Geltungsbereich
Geltungsbereich
-
Alle neu zu entwickelnden Frontends für Anwendungen (Standardsoftware ausgeschlossen)
-
Kürzlich entwickelte Bestandsanwendungen, die bereits als Single-Page Application umgesetzt wurden
-
Explizit ausgeschlossen sind alte Bestandsanwendungen, die noch auf Basis von JSF entwickelt wurden
Die unten beschriebenen Zielbilder sowie der Geltungsbereich der Referenzarchitektur Frontend konzentrieren sich auf die Bereitstellung von Frontends als Single-Page Applications. Geschäftsanwendungen in der öffentlichen Verwaltung sind überwiegend Business-Anwendungen, die auf die Verarbeitung von Daten sowie eine geringe Anzahl von Anwendern (Sachbearbeitern) ausgelegt sind. Anforderungen wie schnelle LCP (Largest Contentful Paint) oder Search Engine Optimization (SEO) haben keine hohe Priorität, sodass der Architekturstil Server-Side Rendering (SSR) zunächst ausgeklammert werden kann.
Auf Basis dieser Architekturvorgabe werden zwei konkrete Zielbilder besprochen: Single-Page Application (SPA) mit direkter Backend-Anbindung sowie die Architekturvariante mit Backend-for-Frontend (BFF).
1.1. Single-Page Application (SPA) mit direkter Backend-Anbindung
Darstellung der Frontends in der softwaretechnischen Architektur inklusive Security zeigt die softwaretechnische Darstellung von Frontends in einer Anwendungslandschaft. Im Vergleich zur allgemeinen Darstellung der softwaretechnischen Referenzarchitektur geht die folgende Abbildung näher auf die bereits in der Einführung erwähnte Verteilung von Frontend und Backend ein.
Durch die Verwendung von SPAs befindet sich der Frontend-Teil der GA im Webbrowser des Anwenders, während der Backend-Teil weiterhin auf den Servern der Anwendungslandschaft betrieben wird. Zur strukturierten, sicheren und einheitlichen Anbindung der Frontends an die Backend-Systeme ist verpflichtend ein zentrales API-Gateway als querschnittliche Komponente vorzuschalten. Das API-Gateway ist ein Bestandteil der Systemlandschaft und wird in der software-technischen Referenzarchitektur detailliert beschrieben.
1.2. Architekturvariante mit Backend-for-Frontend (BFF)
Darstellung der Frontends in der softwaretechnischen Architektur mit der Variante BFF zeigt eine Variante für die Darstellung von SPAs in der softwaretechnischen Referenzarchitektur unter Verwendung eines Backend-for-Frontend (BFF).
Dabei wird eine zusätzliche Anwendung zwischen Backend und Frontend auf der Serverseite vorgesehen, um das Backend über eine spezifische API vom Frontend zu entkoppeln. Diese Vorgehensweise erhöht zunächst die Komplexität, ist jedoch ein bewährtes Muster, um folgende Herausforderungen zu lösen:
-
Auslieferung unterschiedlicher Darstellungen je nach Endgerät (Smartphone, Tablet, Desktop).
-
Umsetzung von Performance-, Sicherheits- oder Skalierbarkeitsanforderungen, die speziell für die Kommunikation zwischen Frontend und Backend relevant sind.
-
Vorverarbeitung, Filterung und Validierung sensibler oder sicherheitskritischer Daten im Backend, bevor sie an das Frontend gesendet werden – ohne die Backend-API für andere Dienste einschränken zu müssen.
1.3. Architekturvariante: Modularisierte Single Page Application mit Native Federation
Die Architekturvariante Native Federation beschreibt eine modularisierte Single Page Application (SPA), bei der fachlich abgegrenzte Anwendungsdomänen (z. B. „Suche“, „Fallbearbeitung“, „Administration“) als eigenständig lieferbare Frontend-Komponenten umgesetzt und zur Laufzeit durch eine zentrale Anwendungskomponente (Shell) integriert werden.
| Eine Shell-Anwendung ist die zentrale Anwendungskomponente innerhalb einer modularisierten Single Page Application. Sie stellt den technischen Rahmen der Anwendung bereit und integriert fachliche Frontend-Komponenten zur Laufzeit. |
Im Unterschied zu einer „einfachen“ SPA (ein Build-Artefakt, ein Deployment) erlaubt diese Variante getrennte Build- und Bereitstellungsprozesse je Komponente und reduziert damit Kopplungseffekte zwischen Organisationseinheiten und Liefergegenständen (Artefakten).
Die erhöhte Komplexität ist gerechtfertigt, wenn organisatorische oder technische Rahmenbedingungen eine Modularisierung erfordern; insbesondere dann, wenn mehrere Organisationseinheiten oder Auftragnehmer parallel an derselben Anwendung arbeiten und unabhängige Release-Zyklen bzw. Freigaben benötigt werden.
Native Federation ist sinnvoll, wenn mehrere der folgenden Entscheidungskriterien erfüllt sind:
-
Skalierung von Organisationseinheiten: Mindestens drei Teams (oder mehrere Dienstleister) entwickeln parallel an derselben Anwendung, und die zentrale Integration eines monolithischen Frontends führt zu Blockaden im Bereitstellungsprozess.
-
Unabhängige Freigaben: Fachliche Anwendungsdomänen müssen getrennt bereitgestellt werden (z. B. aufgrund unterschiedlicher Roadmaps, Abnahme- oder Freigabeprozesse bzw. Wartungsfenster).
-
Fachliche Modularisierbarkeit: Die Anwendung lässt sich entlang stabiler fachlicher Domänen strukturieren, ohne dauerhaft stark domänenübergreifenden UI-Zustand oder eng verflochtene Nutzungsszenarien zu erzwingen.
-
Governance- und Architekturvorgaben: Es bestehen verbindliche Regeln für Schnittstellen, Versionierung, Deprecation und Freigabeprozesse, um die kontrollierte Laufzeitintegration unabhängig bereitgestellter Frontend-Komponenten sicherzustellen. Ohne diese Architekturvorgaben besteht das Risiko von Laufzeitinkompatibilitäten und Beeinträchtigungen der Gesamtanwendung. Ein minimaler Rahmen umfasst:
-
Definition und Dokumentation von Integrationsschnittstellen,
-
verbindliche Versionierungsregeln (z. B. Semantic Versioning gemäß IsyFact-Versionierungskonzept),
-
geregelte Deprecation- und Übergangsfristen bei inkompatiblen Änderungen,
-
versionierte Einbindung externer Komponenten (keine ungebundenen „Latest“-Referenzen),
-
etablierte Freigabe- und Qualitätssicherungsprozesse vor produktiver Integration.
-
-
Betriebs- und Sicherheitsanforderungen: Sicherheits- und Supply-Chain-Kontrollen (z. B. kontrollierte Bezugsquellen, Nachvollziehbarkeit von Build-Artefakten) sowie etablierte Verfahren für Protokollierung, Monitoring und Nachvollziehbarkeit sind organisatorisch und technisch umgesetzt.
-
Testkonzept: Es existiert ein belastbares Testkonzept mit einer Kombination aus Schnittstellen- (Contract-)Tests und Integrations- bzw. Smoke-Tests, um die Kompatibilität zwischen Shell-Komponente und fachlichen Komponenten kontinuierlich sicherzustellen.
Sind diese Voraussetzungen nicht gegeben (z. B. nur ein bis zwei Teams, gemeinsamer Freigabezyklus, hohe funktionale Verflechtung), ist eine einfache SPA oder ein modular strukturierter Monolith (klare Modulgrenzen innerhalb eines gemeinsamen Build-Artefakts) in der Regel wirtschaftlicher und risikoärmer.
Native Federation ist somit kein Standardvorgehen, sondern eine gezielte Architekturentscheidung zur Skalierung von Organisation, Lieferfähigkeit und Modernisierungsfähigkeit bei großen, langfristig betriebenen Anwendungen. == Architekturgrundsätze & -regeln für Frontends Dieses Kapitel beschreibt die übergreifenden Architekturgrundsätze und -regeln für die Gestaltung von Frontends im Geltungsbereich dieser Referenzarchitektur.
Die hier formulierten Grundsätze sind verbindlich und dienen als normative Leitplanken für alle neu zu entwickelnden Frontends sowie für relevante Weiterentwicklungen bestehender Anwendungen.
Ziel ist es, eine einheitliche, sichere, wartbare und langfristig evolvierbare Frontend-Landschaft sicherzustellen. Konkrete technische Ausprägungen und Detailvorgaben werden in den nachfolgenden Kapiteln behandelt.
1.4. Architekturgrundsätze
1.4.1. AG-1: Trennung von Frontend und Backend
Frontend und Backend MÜSSEN als eigenständige IT-Systemtypen mit klar abgegrenzten Verantwortlichkeiten konzipiert und betrieben werden. Diese Trennung SOLL eine unabhängige Entwicklung, den separaten Betrieb sowie eine evolvierbare Weiterentwicklung ermöglichen.
1.4.2. AG-2: Frontend als nicht vertrauenswürdige Komponente
Der IT-Systemtyp Frontend DARF NICHT als vertrauenswürdige Komponente betrachtet werden. Sicherheits- oder fachkritische Entscheidungen DÜRFEN NICHT im Frontend getroffen werden, sondern in Backend-Systemen.
1.4.3. AG-3: Standardisierung vor projektspezifischen Sonderlösungen
Die Gestaltung von Frontends SOLL einheitlichen architektonischen, technologischen und organisatorischen IsyFact-Standards des BVA folgen. Abweichungen MÜSSEN begründet und dokumentiert werden.
1.4.4. AG-4: Evolvierbarkeit und Austauschbarkeit
Frontend-Architekturen SOLLEN so gestaltet werden, dass technologische Weiterentwicklungen, der Austausch einzelner Komponenten sowie funktionale Erweiterungen mit vertretbarem Aufwand möglich sind
1.4.5. AG-5: Modularer Aufbau entlang fachlicher Verantwortlichkeiten
Frontends SOLLEN modular aufgebaut sein. Die Strukturierung SOLL sich primär an fachlichen Verantwortlichkeiten und Anwendungsdomänen orientieren, nicht ausschließlich an technischen Schichten.
1.4.6. AG-6: Einheitlicher Zugriff auf Backend-Systeme
Der Zugriff von Frontends auf Backend-Systeme SOLL einheitlich erfolgen. Hierfür SOLL ein zentrales API-Gateway als vermittelnde Komponente vorgesehen werden.
1.4.7. AG-7: Backend-for-Frontend als optionale Architekturvariante
Ein Backend-for-Frontend (BFF) SOLL als optionale Architekturvariante vorgesehen werden, wenn Anforderungen an Vorverarbeitung, Sicherheit, Performance oder Entkopplung zwischen Frontend und Backend bestehen.
1.4.8. AG-8: Security und Datenschutz by Design
Sicherheits- und Datenschutzanforderungen SOLLEN von Beginn an integraler Bestandteil der Frontend-Architektur sein. Personenbezogene Daten MÜSSEN auf das notwendige Minimum beschränkt und zweckgebunden verarbeitet werden.
1.4.9. AG-9: Modularisierung nur bei nachgewiesenem Bedarf
Eine Laufzeit-Modularisierung (z. B. via Native Federation) SOLL nur eingesetzt werden, wenn organisatorische oder fachliche Gründe dies erfordern (z. B. mehrere Teams/Lieferanten, unabhängige Release-Zyklen). Andernfalls SOLL eine einfache SPA oder ein modularer Monolith bevorzugt werden.
1.4.10. AG-10: Kontrollierte Runtime-Integration über Shell
Frontends, die aus mehreren unabhängig bereitgestellten Modulen bestehen (Native Federation), SOLLEN über eine zentrale Shell-Anwendung integriert werden. Die Shell SOLL ausschließlich Integrations- und Querschnittsaufgaben (z. B. Routing, Authentifizierung, Layout, Fehlerbehandlung) übernehmen; fachliche Logik SOLL in den Fachmodulen verbleiben.
1.4.11. AG-11: Verbindliche Integrationsverträge und Versionierung
Bei der Integration unabhängig deployter Frontend-Module über Native Federation MÜSSEN öffentliche Schnittstellen (Contracts) definiert, versioniert und über Deprecation-Regeln gesteuert werden. Die produktive Einbindung SOLL versiongebunden erfolgen (keine ungebundenen „Latest“-Referenzen), um Laufzeitinkompatibilitäten zu vermeiden.
7. UX, UI & Accessibility
Die Gestaltung der Frontends folgt verbindlichen Leitlinien zu User Interface (UI), User Experience (UX) sowie zur Barrierefreiheit. Diese Rahmenvorgaben sind im Bedienkonzept umfassend beschrieben. Darin finden sich sowohl UI/UX-Richtlinien für Bedienelemente, Fenstertypen und Layoutstrukturen als auch zentrale Anforderungen zur Barrierefreiheit. Insbesondere werden relevante Akzeptanzkriterien der WCAG 2.2 berücksichtigt, um sicherzustellen, dass alle Anwendungen für Nutzende mit unterschiedlichen Fähigkeiten uneingeschränkt und normkonform zugänglich sind.