Die Entwicklung des digitalen Rechnungseingang InvoiceR startete vor ungefähr vier Jahren auf der grünen Wiese. In Bezug auf eine Software ist damit gemeint, dass die Umsetzung ohne Abhängigkeiten zu alten Vorgängerversionen komplett frisch gestartet werden konnte und daher auch architektonisch zunächst noch alles offen stand.
Diese Freiheit wurde genutzt und durch die Umsetzung diverser technischer Prototypen konnte die optimale Architektur gefunden werden. In diesem Artikel werden die wichtigsten Eckpfeiler der InvoiceR-Architektur für technisch Interessierte aufgezeigt und Vor- und Nachteile ausgeführt.
Front- vs. Backend
Die wohl offensichtlichste architektonische Eigenschaft ist die Aufteilung der Anwendung in ein Front- und ein Backend. Für browser-basierte Applikationen hat sich diese Unterteilung mittlerweile etabliert und hat sogar dazu geführt, dass sich innerhalb der Entwickler-Gemeinde spezialisierte Berufsbezeichnungen etabliert haben. Man ist entweder Fronend- oder Backend-Entwickler:in oder hat sich auf beide Seiten spezialisiert und nennt sich dann Fullstack-Entwickler:in.
Einfach erklärt besteht das Backend aus sämtlichem Programmcode, welcher auf einem Server ausgeführt wird. Dieser Code enthält die Business-Logik wie z.B. die Berechnung der Mehrwertsteuer, das Weiterführen eines Prozess, Speichern der Rechnungs-Daten in einer Datenbank oder die Kommunikation mit Drittsystemen wie dem ERP. Das Backend hat selber keine Benutzeroberfläche – diese Aufgabe wird vom Frontend übernommen. Als Frontend wird der Programm-Code bezeichnet, welcher im Browser des Benutzers zur Anwendung kommt und letztendlich die Benutzeroberfläche im Browser «zeichnet». Die Kommunikation dieser beiden Bereiche findet über eine REST-Schnittstelle statt. Diese Schnittstelle kann übrigens auch von Dritt-Applikationen genutzt werden, wenn diese Daten von InvoiceR beziehen möchten.
Ein großer Vorteil dieser Unterteilung ist die klare Trennung von Benutzer-Oberfläche und Business-Logik, welche beim Einsatz dieses Models (fast) automatisch erreicht wird. Außerdem ermöglicht die Trennung eine viel einfachere Skalierbarkeit der Anwendung bei allfälligen Performance-Problemen. So kann bei InvoiceR, falls nötig, das Backend ohne weiteres auf mehreren Servern parallel betrieben werden. Als Nachteil erachten wir, dass die Entwicklung insgesamt durch die Aufteilung etwas aufwändiger und komplexer wird.
Jobbasierte Datenverarbeitung
Die allermeisten System-Aktionen werden in InvoiceR jobbasiert durchgeführt. Dies bedeutet, dass für einzelne Aufgaben wie z.B. die Archivierung einer Rechnung zuallererst ein Job-Eintrag in der Datenbank angelegt wird. Erst danach wird die Ausführung der Aufgabe angestossen. Der Datenbank-Eintrag erlaubt es im Fehlerfall die entsprechende Aufgabe erneut auszuführen. Ist beispielsweise das Dokumenten-Archiv kurzzeitig für InvoiceR nicht erreichbar, wird die Job-Ausführung, also die Ablage der Rechnung, einfach später nochmals ausgeführt.
Auch sämtliche Zustandsübergänge im Workflow eines Rechnungs-Dokuments werden mit einem Job-Eintrag abgesichert. Der konsequente Einsatz dieser Architektur führt dazu, dass die InvoiceR-Daten zu jedem Zeitpunkt in sich konsistent sind. Ein plötzlicher Stromausfall oder ein Server-Problem ist für InvoiceR also kein Problem. Auch bei der Kommunikation mit Drittsystemen können inkonsistente Zustände zwischen den Systemen minimiert werden.
Plugins
Einer der grössten Vorteile von InvoiceR gegenüber Lösungen von Mitbewerbern ist die einfache Erweiterbar- und Individualisierbarkeit der Applikation. Damit diese Flexibilität jedoch eine einfache Aktualisierung der Applikation auf den Kundensystemen nicht verhindert, wurde bereits zu Beginn der Entwicklung auf eine Architektur mit starken Plugin-Möglichkeiten gesetzt. Konkret bedeutet dies, dass jede Klasse mit Business-Logik im InvoiceR überschrieben werden kann und diese angepasste Logik wird dann in einem kundenspezifischen Plugin-Projekt abgelegt. Durch diese architektonische Trennung der Basis-Applikation von den kundenindividuellen Anpassungen kann der Code in der Basis problemlos erweitert/aktualisiert werden, ohne dass man Gefahr läuft, die Individualisierungen zu verlieren. In seltenen Fällen, wenn eine Plugin-Schnittstelle angepasst werden muss, werden sofort nach der Anpassung allfällige Probleme bei individuellen Anpassungen sichtbar und können behoben werden.
Außerdem wird auch sämtlicher Programmcode, welcher zur Kommunikation mit Drittsystemen dient, in Plugins ausgelagert. Z.B. wird die Datei-Ablage in ein Archiv-System, die Verbuchung in ein ERP-System oder Daten-Extraktion durch einen Service-Anbieter in Plugins gemacht. Ein Wechsel eines Drittsystems führt daher lediglich zum Austausch des Plugins und einer Anpassung der Konfiguration und kann schnell durchgeführt werden.
Plugins können beispielsweise zusätzliche Schritte im Prozess beschreiben, bestehende Schritte abändern und Schnittstellen zu Drittsystemen implementieren.
Bereit für die Zukunft
Rückblickend hat es sich gelohnt, durch die Umsetzung diverser Prototypen einen relativ grossen Aufwand in Kauf zu nehmen um die optimale Architektur für InvoiceR zu finden:
- Neue Features können einfach hinzugefügt werden ohne grundlegende Änderungen an der Basis-Applikation vornehmen zu müssen.
- Die Benutzeroberfläche ist klar von der Business-Logik getrennt. Dadurch kann die Oberfläche neuen Anforderungen an die Benutzer-Interaktion angepasst werden.
- Die Anwendung ist breit skalierbar und kann Millionen von Rechnungen verwalten.
Dank der stabilen und zuverlässiger Code-Basis ist der Kreditoren-Workflow bestens gerüstet für die Zukunft.
