Migration einer MS Access Anwendung zu Angular/Spring Boot: Ein Erfahrungsbericht
In der sich schnell entwickelnden Welt der Unternehmens-IT stehen viele Firmen vor der Herausforderung, veraltete Systeme zu modernisieren. In den vergangenen Monaten hatten wir Kontakt zu mehreren Unternehmen, welche vor der Herausforderung stehen, MS Access Anwendungen zeitnah abzulösen und «Cloud ready» zu gestalten. Kürzlich unternahmen wir unser erstes Projekt dieser Art und lösten eine langjährig genutzte MS Access Anwendung durch eine moderne Webanwendung mit Angular und Spring Boot ab. Dieser Artikel beleuchtet die technischen Aspekte und Herausforderungen dieses Projekts.
Ausgangssituation und Beweggründe
Die bestehende MS Access Lösung hatte jahrelang gute Dienste geleistet, stiess jedoch an ihre Grenzen:
- Konzentration des Fachwissens auf wenige Mitarbeiter
- Absehbares End-of-Life von MS Access
- Begrenzte Skalierbarkeit bei steigender Nutzerzahl
- Neue Anforderungen zur unternehmens- oder kantonsübergreifenden Datenteilung
Technische Umsetzung
Bevor wir uns dem Design der Architektur widmen konnten, mussten eine Reihe von Fragen hinsichtlich der Rahmenbedingungen und vor allem nicht-funktionalen Anforderungen geklärt werden. Die rein funktionalen Anforderungen hingegen, waren recht offensichtlich: Es soll (im ersten Schritt) den gleichen Funktionsumfang bieten. Nur eben etwas schöner und vielleicht auch etwas schneller.
Die Rahmenbedingungen waren schnell gesetzt. Der Kunde setzte auf eine Kubernetes-Infrastruktur, hatte eine lauffähige CI/CD Umgebung basierend auf Gitlab und verwendete Helm fürs Templating (und release management). Die neue Anwendung soll sich nahtlos in das Setup einreihen. Auch Datenbanken (nicht MS Access) konnten – mittels internem Bestellverfahren – zeitnah bereitgestellt werden.
Da das Unternehmen eine interne Komponentenbibliothek auf Basis von Angular pflegt, lag auch die Wahl des Frontend-Frameworks nah. Andere Abteilungen im gleichen Unternehmen setzten zunehmend auf Spring Boot Backends, wodurch auch das im Wesentlichen keine Fragen offen liess.
Systemarchitektur
Die Systemarchitektur ist relativ einfach gestaltet. Ein Angular basiertes Frontend wird über einen ngix Kubernetes Pod an den Client ausgeliefert. Zur Authentifizierung kommt Keycloak zum Einsatz (OAuth2 mit Open ID Connect). Die Daten werden über das Sprint Boot Backend aus der Datenbank zusammengestellt und an den Client übertragen.
Sowohl Keycloak, als auch das Angular Frontend und Spring Boot Backend laufen in einem eigenen Pod. Die Datenbank wurde vom Storage-Team des Kunden – ausserhalb des Clusters – bereitgestellt.
Frontend (Angular)
- Implementierung einer Single Page Application (SPA)
- Verwendung von unternehmensinternen Design-Komponenten für ein konsistentes UI
- Keycloak Anbindung mittels OAuth2/OIDC
- State Management mit NgRx zur effektiven Verwaltung des Anwendungszustands
Backend (Spring Boot)
- Entwicklung von RESTful APIs zur Kommunikation mit dem Frontend
- Umsetzung der Geschäftslogik – Modularisiert nach ermittelten Kontext-Elementen
- Nutzung von Spring Security (JWT Token Verifikation, Mapping der Claims auf Authorities, Schützen der REST Endpunkte)
- Integration von Hibernate ORM für effizientes Datenbankmanagement
Datenbank
- Migration der Tabellen und Daten von MS Access zu PostgreSQL
- Implementierung von Datenbankindizes und Optimierung von Abfragen
Deployment
- Containerisierung der Anwendung mit Docker
- Orchestrierung mit Kubernetes für verbesserte Skalierbarkeit und Verwaltbarkeit
- Implementierung einer CI/CD-Pipeline mit Jenkins für automatisierte Tests und Deployments
Herausforderungen und Lösungsansätze
Datenmigration
Über die Jahre hat sich eine beträchtliche Anzahl an Datensätzen gesammelt, welche in die neue Datenbankstruktur überführt werden mussten. Zusätzlich gab es eine einige Tabellen, welche zwar noch Datensätze beinhielten, die effektiv aber nicht mehr genutzt wurden. Die Vermutung lag nah, dass es sich dabei um Tabellen aus früheren Releases handelte, die höchstwahrscheinlich mal zur Geschäftslogik beitrugen. Derartige Tabellen mussten identifiziert und beim Import in die neue Struktur ausgelassen werden.
Erschwerend kam hinzu, dass einige Tabellen natürliche Schlüssel verwendeten und eine Umschlüsselung zu Problemen bei anderen Systemen hervorrufen würde. Beim Import dieser Daten musste dies unbedingt berücksichtigt werden (gleichwohl das neue Datenbankschema konsequent auf Surrogatschlüssel gesetzt hat, um diese Herausforderung nicht noch einmal durchleben zu müssen).
Letztendlich wurde ein überschaubares ETL-Tool umgesetzt, welches die Daten schrittweise aus der existierenden MS Access Datenbank extrahiert, in die neue Struktur überführt (transformiert) und in die neue Datenbank geladen hat. Abschliessend hat es noch einige Validierungsaufgaben durchgeführt, um eine korrekte Überführung zu verifizieren.
«Versteckte Geschäftslogik»
Die Geschäftslogik der Formulare wurde in der MS Access Lösung primär durch Makros und Visual Basic Code abgebildet. Diese Logiken lagen zum Teil deutlich fragmentierter vor, als ursprünglich erwartet. Die Kohäsion war gering, wodurch das Verständnis über die implementierte Geschäftslogik nur schrittweise aufgebaut werden konnte.
Diese Herausforderung wurde bereits in der Analyse erkannt und bearbeitet. Währenddessen wurde auf Ideen aus dem Domain Driven Design zurückgegriffen. Es konnten Bounded Context(e) abgeleitet werden, Entitäten platziert und letztendlich mit den «Code Snippets» (welche die Geschäftslogik enthielten» verknüpft werden. Das Vorgehen entspricht vermutlich nicht ganz der Idee von Eric Evans (Autor des DDD-Klassikers «Domain Driven Design»), hat sich aber als praktikables Vorgehen erwiesen.
Benutzerakzeptanz
Eine zugegebenermassen unerwartete Herausforderung war – zumindest zu Beginn – die Benutzerakzeptanz. Vermutlich lässt sich dies mit einer Analogie erklären: Jeder der schon einmal einen Mitarbeiter eines Kassensystems beobachtet hat, kennt dieses Phänomen. Es erscheint ein unfassbar grosses und komplex wirkendes Formular auf dem Bildschirm doch der/die Mitarbeiter/in schafft es sich – durch Tastenkombinationen und intensiver Nutzung der Tab-Taste – innerhalb 1-2 Sekunden durch das Formular zu bewegen und den Prozess abzuschliessen. Wird dieses Formular nun auf eine neue Applikation gebracht, funktionieren die eingebrannten Muster nicht mehr. Eine ähnliche Herausforderung wurde während der ersten Nutzertests auf der neuen Lösung erkannt. Design-Elemente welche wir clever und gut platzier ansehen, stiessen auf Widerstand. Platzierungen von Elementen erschienen uns zwar logisch, waren für die Anwender/innen aber störend. Und ganz wichtig: Die Tab-Reihenfolge der Elemente(!).
Letztendlich führte das Feedback zu einigen Umgestaltungen der neuen Formulare welche abschliessend dann doch wohlwollend angenommen wurden.
Lessons Learned
Welche Punkte haben rückblickend massgeblich zum Projekterfolg beigetragen?
- Gründliche Analyse: Eine detaillierte Untersuchung der bestehenden Anwendung, insbesondere der versteckten Geschäftslogik, ist unerlässlich.
- Nutzerfeedback einbeziehen: Die frühzeitige Einbindung der Endnutzer kann unerwartete Herausforderungen bei der Benutzerakzeptanz aufdecken.
- Flexibilität in der Umsetzung: Die Bereitschaft, Designs und Funktionen basierend auf Nutzerfeedback anzupassen, ist entscheidend für den Erfolg.
- Datenmigration planen: Die Komplexität der Datenmigration sollte nicht unterschätzt werden. Ein solider ETL-Prozess mit Validierungsschritten ist wichtig.
- Solides Software-/Architekturdesign: Man sollte immer im Hinterkopf behalten, dass alle was wir heute schreiben, irgendwann gewartet werden muss. Kohäsionsfreie Code-Snippets wie in der ursprünglichen Lösung erschweren dies massgeblich.
- Kontinuierliche Schulung: Das Entwicklungsteam sollte sowohl in modernen als auch in älteren Technologien geschult sein, um Legacy-Systeme effektiv zu modernisieren.
Fazit
Die Migration von MS Access zu einer modernen Webanwendung war ein komplexes, aber lohnendes Unterfangen. Die neue Architektur bietet verbesserte Skalierbarkeit, Wartbarkeit und Zukunftssicherheit. Gleichzeitig stellte das Projekt das Entwicklungsteam vor neue Herausforderungen und bot Gelegenheit zur Weiterbildung in modernen und alten Technologien.
Der Teufel steckt wie immer im Detail. Das traf vor allem auf die verstreute Geschäftslogik zu, welche im Vorfeld zusammengesucht und kategorisiert werden musste. Für Unternehmen, die vor einer ähnlichen Aufgabe stehen, empfiehlt sich eine gründliche Planung und schrittweise Implementierung. Das klingt nach «alles wie immer», aber vor dem Hintergrund, dass eine bestehende Applikation ja «nur» auf eine andere Technologie portiert werden muss, wird dies von Aussenstehenden gerne unterschätzt. Altlasten möchte man ungerne portieren. Meiner Erfahrung nach ist es niemals ein reiner Portierungsvorgang. Es gibt immer noch die Schritte: Analysiere was da ist, überlege was behalten werden soll, räume das Bestehende auf, stelle sicher, dass du es verstanden hast, portiere es und teste das Ergebnis (gleiche es mit der Ursprungslösung ab).
Die Investition in moderne Technologien kann langfristig zu erheblichen Vorteilen in Bezug auf Effizienz und Wettbewerbsfähigkeit führen.
PS: Es gibt auch eine Variante mit Power Automate. Hier ein Erfahrungsbericht über die Migration einer MS Access-Anwendung zu Power Automate.