Antragsportal der Steuerberaterkammern setzt auf Cloud-Architektur

Für mehr als 100.000 Mitglieder stellt das neue OZG-Antragsportal der Steuerberaterkammern rund um die Uhr 24 Leistungen zentral bereit. Um ausfallsicher, einfach wartbar und flexibel erweiterbar zu sein, setzt das Portal auf eine Microservice-Architektur und den Betrieb in einem Kubernetes-Cluster. Wir werfen einen Blick auf die technische Umsetzung der Software, die mithilfe der Enterprise Low Code Plattform A12 entwickelt wurde.

Seit dem 19. September 2023 stellt das Antragsportal der Steuerberaterkammern (StBK) für die Mitglieder in allen 16 Bundesländern vereinheitlichte digitale Leistungen an einem zentralen Ort bereit. Sortiert sind sie in fünf Bereiche: Steuerberaterprüfung, Aus- und Fortbildung, Bestellung und Verzicht, Berufsausübungsgesellschaften sowie sonstige Anträge nach StBerG, dem Steuerberatungsgesetz. Umgesetzt wurde das OZG-Projekt in nur 14 Monaten unter Federführung der Steuerberaterkammern Nürnberg und München in Zusammenarbeit mit mgm.

„Ausschlaggebend für die schnelle Umsetzung des Portals war die Frist des OZG. Durch die enge Kooperation der Kammern konnten wir ein gemeinsames Angebot schaffen, das unseren Mitgliedern heute eine viel komfortablere Antragsstellung ermöglicht“, erklärt Moritz Alt, Hauptgeschäftsführer der federführenden Steuerberaterkammer Nürnberg. „Gleichzeitig haben wir damit die Basis für eine umfassendere Modernisierung unserer IT geschaffen. Wir treiben sukzessive die Cloud-Transformation unserer Systeme voran, um den Service für unsere Mitglieder weiter zu verbessern und interne Aufwände zu reduzieren.“

Modellierte Formulare, Validierungsregeln und Druckvorlagen

Umgesetzt wurde das individuelle Software-Projekt schließlich auf Basis der Enterprise Low Code Plattform A12. Die fachlichen Inhalte – also die Formulare der 24 Leistungen inklusive der zugrundeliegenden Datenmodelle sowie Validierungs- und Berechnungsregeln – wurden mit den Modellierungswerkzeugen von A12 definiert. Dadurch wurde der Entwicklungsaufwand von Anfang an reduziert und auch zukünftige fachliche Änderungen sind durch Anpassung der jeweiligen Modelle schnell umsetzbar. Der Modellierungsansatz kam auch für die Gestaltung der aus den Antragsdaten generierten PDFs zum Einsatz.

Innerhalb des Gesamtprojekts liegen die Modelle in einem eigenen Repository und werden als Artefakte bereitgestellt. Da Änderungen an den Modellen aus fachlicher Sicht eher selten auftreten, übernimmt mgm als Dienstleister deren Pflege und Aktualisierung. Bei regelmäßigen und häufigen Änderungen empfiehlt sich jedoch stets, die fachlich Verantwortlichen in die Modellierung der Inhalte einzubinden. Im Steuerumfeld ist beispielsweise ein Prozess etabliert, bei dem die jeweiligen Fachabteilungen mit den Modellierungswerkzeugen von A12 die Änderungen eigenständig einpflegen und dabei jeweils die aktuellen Neuerungen der Steuergesetzgebung berücksichtigen.

Microservices updaten mit Zero-Downtime

Während die fachlichen Inhalte modelliert werden konnten, konzentrierte sich die technische Umsetzung beim StBK-Antragsportal auf die Entwicklung einer robusten und zukunftsfähigen Portal-Infrastruktur. Durch den Einsatz des A12 Projekt-Templates waren eine Reihe von Basisfunktionalitäten, ein bewährter Tech-Stack und eine sichere Konfiguration von Anfang an gegeben. Darauf aufbauend wurde eine Microservice-Architektur entwickelt, die wesentliche Funktionalitäten des Antragsportals wie zum Beispiel den Payment-Service kapselt und einen effizienten Betrieb gewährleistet.

„Dank der entwickelten Architektur sind wir in der Lage, Zero-Downtime-Updates durchzuführen“, erklärt Guido Wischrop, der mgm-seitig die technische Projektleitung verantwortete. „Wenn sich zum Beispiel der Preis einer Leistung ändert, können wir im laufenden Betrieb ein Update des Payment-Service einspielen. Kubernetes hält dafür die alte Instanz am Leben bis die neue Instanz verfügbar ist und genutzt werden kann.“ Um die Ausfallsicherheit des Systems zu gewährleisten, läuft darüber hinaus jeder Dienst mindestens zweimal.

Anbindung von zwei Identity Providern und einem Payment Provider

Bevor die Nutzer:innen des Portals einen Antrag stellen, müssen sie sich anmelden. Dafür hat das Entwicklungsteam im Laufe des Projekts zwei SAML Identity Provider (IDP) mithilfe der A12-Komponente User Management, Authentification & Authorization (UAA) angebunden:

• Die BundID ermöglicht einer breiten Öffentlichkeit, die Dienste des Portals zu nutzen. Nach einer Anmeldung via BundID ist es zum Beispiel möglich, die Zulassung zur Steuerberaterprüfung zu beantragen.
• Die Steuerberaterplattform bietet eine verifizierte Steuerberater-Identität. Sie ist die Voraussetzung, um Anträge zu stellen, die ausschließlich für die im Steuerberaterverzeichnis geführten Berufsträger zugänglich sind.

Für mehrere Leistungen der Steuerberaterkammern wird eine Bearbeitungsgebühr fällig. Um den Bezahlvorgang auch direkt über das neue Portal abzuwickeln, ist ein Payment-Provider angebunden. Die Wahl fiel auf das Verfahren GiroCheckout des Finanzdienstleisters S-Public Services. „Die Payment API war gut dokumentiert und ließ sich problemlos einbinden. Nichtsdestotrotz war dabei eine hohe Sorgfalt geboten. Man muss auch Spezialfälle berücksichtigen – zum Beispiel: Was passiert, wenn der Payment Provider nicht erreichbar ist? Oder nach der Zahlung ein Verbindungsproblem auftritt?“, sagt Guido Wischrop.

Automatisiertes Routing der Anträge in die richtige Kammer

Eine Besonderheit des Portals besteht in der automatisierten Zustellung der ausgefüllten Anträge in die richtige der angebundenen Kammern und dort an die zuständige Person in der Sachbearbeitung. Für diesen Mechanismus ist ein eigens entwickelter Discovery-Service zuständig. Er ermittelt anhand von Parametern wie dem Wohnort und dem Arbeitsplatz, welche Kammer und Abteilung für das jeweilige Anliegen zuständig ist. Falls die Zuständigkeit nicht eindeutig bestimmt werden kann, öffnet sich als Fallback-Lösung ein Dialog, in dem die Nutzer:innen die Kammer manuell auswählen können.

Perspektivisch lassen sich die Antragsdaten direkt in strukturierter Form in die nachgelagerten Systeme der jeweiligen Kammer übertragen. Eine API dafür ist bereits implementiert. Da die Systeme der Sachbearbeitung jedoch noch nicht vereinheitlicht sind und aktuell modernisiert werden, wurde zunächst ein Storage-Box-Konzept für die Datenübergabe umgesetzt: Das Antragsportal exportiert die Antragsdaten als PDF und legt sie in den Verzeichnissen einer Storage-Box ab, die über einen abgesicherten Kanal via Samba-Protokoll beziehungsweise Secure File Transfer Protocol  mit den Dokumentenmanagementsystemen in der Sachbearbeitung synchronisiert werden.

Modularer Aufbau ermöglicht Erweiterung um zusätzliche Funktionalitäten

Bei der in Produktion gegangenen Version des Steuerberaterportals entfällt ein Großteil der entwickelten Funktionalität auf die Frontend-Seite. Das Backend ist bislang im Grunde genommen nur dafür da, die eingegangenen Anträge entgegenzunehmen und richtig weiterzuleiten. Ergänzend zu diesem grundlegenden Transportmechanismus lassen sich in Zukunft aber weitere Features rund um die Kommunikation zwischen Kammermitgliedern und Sachbearbeiter:innen realisieren.

„Der Livegang des Antragsportals war ein wichtiger Meilenstein. Der Betrieb läuft seitdem sehr stabil“, resümiert Moritz Alt von der Steuerberaterkammer Nürnberg. „Darauf aufbauend treiben wir die Modernisierung unserer internen Infrastruktur weiter voran. In gewisser Weise lässt sich der erfolgreiche Projektabschluss also auch als neuer Anfang für die bundesweiten Systeme der Steuerberaterkammern verstehen.“

Weitere Informationen:

• News vom Livegang: Live nach 14 Monaten: Steuerberaterkammern schaffen zentrales OZG-Antragsportal
• Im Fokus: das OZG-Antragsportal der Steuerberaterkammern