Digitalisierung von Beratungsprozessen

Die Beratung von Kunden ist zentraler Bestandteil im Banking und einer der Bastionen, die noch grosses «Digitalisierungspotenzial» bieten. Einer unserer grössten Kunden hat sich dazu entschlossen einen digitalen Ansatz in einem 8 wöchiges Projekt umzusetzen, um eine einfache Frage zu beantworten: «Buy or make»?

Das detaillierte Vorhaben und die grossen Vorteile für alle Kunden*innen können an dieser Stelle noch nicht genannt werden – sobald sich das ändert, werden wir berichten! Zurück zum Thema:

Das kleine Team bestand ausschliesslich aus sehr erfahrenen Personen (Softwareentwicklern, Product Owner). Onlu hatte die Möglichkeit erhalten, dieses kleine Entwicklungsteam tatkräftig mit einer Person zu unterstützen. Binnen 8 Wochen sollte eine Beratungslösung auf Basis von Java mittels Spring Boot und Camunda erarbeitet werden. Die Produktivität dieses Teams war enorm. Es gab so gut wie keine Störfaktoren. Die Kommunikationswege waren äusserst kurz. Die Zeit war knapp aber niemand fühlte sich negativ «gestresst». Wie bei jedem Vorhaben, gab es auch in diesem Projekt Befürworter und Widersacher. Das wirklich überraschende in diesem Fall war, dass die umgesetzte Lösung derart gut ankam, dass selbst die Widersacher überzeugt wurden und es kurz darauf klar war, dass es ein grösseres Folgeprojekt geben wird. Neben den offensichtlichen Geschäftsinteressen erfreut dies auch jede Person, die am Projekt beteiligt war.

Folgende Aufgaben hatte das Team zu bewältigen:

• Verstehen der Fachlichkeit und ableiten von Anforderungen: Zugegeben, hier wurde gemogelt. Einige Gespräche fanden vor den 8 Wochen statt und im Zweifel, wurden die Fachpersonen kurz befragt. Wichtig bei diesem Vorgehen war natürlich der Scope des Vorhabens. Es wäre utopisch jeden Use case binnen 8 Wochen abdecken zu wollen. Der POC fokussierte sich auf eine Beratungsart.
• Systemarchitektur: Die erarbeitete Systemarchitektur war einfach und effizient. Sie umfasste eine Spring Boot basierte Webapplikation, welche die fachlichen Anforderungen abdeckte. Weiterhin gab es eine zweite Applikation, welche als Wrapper für Camunda gedient hat. Diese zweite Applikation hat im Wesentlichen fachlich orientierte Schnittstellen angeboten, welche durch die Fachapplikation aufgerufen wurden. Dazu noch 1-2 Datenbanken und ein Angular-basiertes Frontend und fertig war das System. Würden wir diesen Ansatz auch in einer produktiven Version der Software verfolgen? Eher nicht – Prozesse neigen dazu sehr asynchron zu verlaufen. Dieser Umstand wurde vollständig ausgeblendet – aufgrund der Zeitanforderung und der zu erwarteten «Last» (1-5 Personen) konnte gut Komplexität eingespart werden.
• Backend-Entwicklung: Umsetzung der Backend-Komponenten mittels Java 17, Spring Boot und Camunda. Zum Frontend (oder jedem anderen API-Konsumenten) wurden eine Vielzahl von REST Schnittstellen mittels API-first Ansatz implementiert.
• Frontend-Entwicklung: Die Umsetzung des Frontends erfolgte durch «1,5» Personen. Es konnten Design-Elemente und Angular-Komponenten des Kunden verwendet werden. Dies hat die Umsetzung des Frontends massiv beschleunigt (einige Frontend-Entwickler sprachen von «etwa Faktor 3»).
• Datenbankdesign: Bei der Fachapplikation haben wir uns für eine Dokumentenorientierte Datenbank (MongoDB) entschieden. Warum? Wir brauchten und wollten in diesem Projektstadium kein festes Datenbank-Schema. Ausserdem brauchten wir keine Relationen im klassischen Sinne. Ein Dokument je Beratungsfall enthielt alle notwendigen Informationen. Anders sah das Camunda Setup aus – aus einem anderen Projekt hatten wir noch ein «ready to use» Helm Setup für Camunda. Neben den üblichen Kubernetes Ressourcen (Service, Deployment) war dort auch die MySQL Datenbank beschrieben (PVC, Volume, Statefulset). 
• Testen und Qualitätssicherung: Trotz oder gerade wegen des knappen Zeitplans waren Tests unabdingbar. Im Backend haben wir uns für einen sehr pragmatischen Ansatz entschieden: Unit Tests mittels JUnit/Mockito und System Tests mittels Karate. 
• DevOps und kontinuierliche Integration/Continuous Deployment (CI/CD): Eine Spring Boot Applikation in Openshift mit Helm paketieren und mittels Gitlab CI/CD regelmässig Ausrollen? Das war keine allzu grosse Herausforderung für uns und lief bereits ab Tag 1.