Tiziano Bruno - Florian Bunsmann - Nick Godzieba

Nataliia Melnyk - Jan Röper - Leon Steiner

@work2

Team Micro

@work2

Auftraggeber


Die AKA Ausfuhrkredit-Gesellschaft mbH ist eine Spezialbank für Exportfinanzierung mit Sitz in Frankfurt am Main. Gegründet wurde die AKA 1952 auf Betreiben von Hermann Josef Abs als privatrechtliches Pendant zur KFW. Das Bankhaus ist nach ihrer Bilanzsumme eines der 100 größten deutschen Kreditinstitute, obwohl sie lediglich rd. 100 Mitarbeiter beschäftigt. Ein besonderer Fokus liegt auf Festzinssatzkrediten, die aus dem ERP-Sondervermögen (European Recovery Program) subventioniert werden. Hierbei handelt es sich um mit Hermesbürgschaften abgesicherte Kredite die Kreditnehmern in über 70 Entwicklungs- und Schwellenländern gewährt werden. Die 18 Gesellschafterbanken der AKA decken alle Säulen des Bankenwesens ab, die öffentlich rechtlichen Kreditinstitute, die privaten Geschäftsbanken und die Genossenschaftsbanken.

Vision


Die AKA Bank vergibt Kredite an Unternehmen in Entwicklungs- und Schwellenländern. Regulatorische Vorgaben der BaFin erlauben die Kreditvergabe generell nur unter der Voraussetzung, dass sich die AKA Bank vorher von der Identität des Kreditnehmers überzeugt hat. Dies dient der Vermeidung von Terrorismusfinanzierung und Geldwäsche. Die Identifikationsprüfung ist bisher ein manueller Prozess, bei dem ein Mitarbeiter der AKA Bank sich persönlich von der Identität der Gegenseite überzeugen muss. In Zukunft möchte die AKA Bank möglichst darauf verzichten, sich mit jedem Klienten persönlich zu treffen und stattdessen auf das Internetgestützte Videoidentifikation von IDnow umstellen. Dies dient auch zur Verbesserung der Sicherheit, da der gewählte Dienstleister Software nutzt, die das Risiko in der Identitätsfeststellung von Personen auf ein Minimum reduziert, da die Sicherheitsmerkmale der jeweiligen Ausweise in deren Datenbank hinterlegt sind. Unser Projekt legt den Grundstein für das Vorhaben der AKA Bank, all ihre papiergestützten Prozesse zu digitalisieren. Dies soll mithilfe von weiteren externen Service-Anbietern geschehen.

Projekt


Die Aufgabe des Projektes war es, einen Microservice zu erstellen, welcher ein komfortables und nutzerfreundliches Bedienen der IDnow-Schnittstelle ermöglichen und deren Antworten an ein internes System weitergereicht werden sollten. Zudem sollte der Microservice der Bank zusätzliche Funktionalität, wie zum Beispiel das Senden von E-Mails mit einem Identifizierung Link an zu identifizierende Personen unterstützen. Dieser Microservice musste in der IT-Umgebung der AKA lauffähig sein, in der das Backend mit Linux-Derivaten betrieben wurde. Zur Implementierung standen Sprachen wie Java, bei der Vorwissen in der Bank bestand, Go als vielversprechende Neuentwicklung und JavaScript als weiterer Kandidat zur Wahl.

User Stories

Es waren für das Projekt 5 User Stories zu implementieren. Von oben nach unten:
  • Neuer Prozess: Die AKA schickt Daten der zu identifizierenden Person. Daraufhin wird eine E-Mail an die E-Mail-Adresse der zu identifizierenden Person geschickt mit einem generierten Link, der die Person zu IDnow weiterleitet.
  • Status Abruf: Unser System fragt regelmäßig den Status von Identifizierungen von IDnow an und leitet Änderung an das interne System weiter.
  • Ergebnis Abruf: Bei Anfrage der AKA wird das Ergebnis eines Identifizierungsprozesses von IDnow abgerufen.
  • Prozesse Archivieren: Nach jedem Abschluss einer Identifikation wird automatisch die Archivierung bei IDnow beantragt.
  • Prozess Löschen: Die AKA kann bei Bedarf Identifizierungen bei IDnow löschen. Dies ist für DSGVO-Konformität wichtig.

User Stories

Build Pipelines

Wir haben eine Build Pipeline für die Feature Branches und eine für den Master Branch. Bei den Feature Branches wird das Projekt mittles Maven gebaut, danach wird von SonarQube eine Qualitätsanalyse durchgeführt. Die Ergebnisse werden UpSource mitgeteilt, so dass sie beim manuellen Code Review ersichtlich sind. Das Mergen in den Master Branch ist ein manueller Prozess.
Beim Master Branch wird das Projekt ebenfalls mittels Maven gebaut. Der Quellcode wir außerdem dem SonarQube Quality Gate mitgeteilt, von diesem analysiert und die Ergebnisse der Statistik hinzugefügt. Es wird ein Docker Container erstellt, dieser wird im Testsystem deployed und die Integration Tests werden ausgeführt. Das Deployment in das Produktivsystem erfolgt manuell.

Build Pipeline

Deployment Umgebung

Bei der Build Pipeline des Master Branches entsteht als Artefakt ein Docker Container. Dieser enthält unsere Anwendung, Cron jobs für Zeit gesteuerte Funktionen und eine Instanz von Postfix. Unsere Anwendung verschickt E-Mails über Postfix, dieser leitet sie über den SMTP-Server der AKA Bank nach außen. Ist der Server nicht verfügbar, wiederholt Postfix den Prozess, bis die E-Mails vom Server angenommen wurden. Unsere Anwendung kommuniziert mit der Schnittstelle von IDnow, die notwendigen Daten werden in einer externen Instanz von PostgreSQL gespeichert und die Ergebnisse werden der AKA Bank mitgeteilt.

Docker container

Lessons Learned


Rechtzeitiges Beginnen von Aufgaben

Auch wenn bei unserem Projekt ein Sprint eine Dauer von zwei Wochen hatte, hat es sich als sinnvoll erwiesen die erste Woche nicht ungenutzt verstreichen zu lassen, da ausgerechnet in der zweiten Wochen dann unkalkulierbare Verzögerungen durch andere Veranstaltungen, sowie andere Verpflichtungen auftraten und somit trotz der langen Vorlaufzeit ein nicht unerheblicher Zeitdruck entstand um die internen Deadlines einzuhalten.

Frühzeitige Deadlines von Aufgaben

Um keine Nachtschichten einlegen zu müssen und in Panik gerade rechtzeitig vor Abgabeende fertig zu werden, wurden teaminterne Deadlines festgelegt um dem vorzubeugen. Dies erwies sich allgemein als sehr nützlich und nervenschonend.

Dokumentationen sind keine Garantie

Bei unserer Arbeit mit der Anbindung an den Drittanbieter, lag uns eine ausführliche Dokumentation der API vor. Allerdings stießen wir beim Testen schnell auf ungewöhnliche Fehlermeldungen, welche nach ausgiebigem Testen auf geänderte bzw. fehlende Parameter zurückzuführen sind, deren Änderungen zu diesem Zeitpunkt noch nicht der offiziellen Dokumentation zu entnehmen waren.

Agenda muss vorher bestehen

Unsere anfänglichen Meetings sprengten den zeitlich angedachten Rahmen dauerhaft und erheblich. Das hatte vor allem damit zu tun, dass während des Meetings die Agenda nicht eingehalten wurde und Punkte die zu einem späteren Thema gepasst hätten vorgezogen wurden. Das hatte zur Folge, dass weit von dem eigentlichen Agendapunkt abgeschweift wurde und es alle Beteiligten Zeit und Mühe kostete um wieder zum eigentlichen Thema bzw. zum nächsten angedachten Thema zurückzukommen. Nachdem jeder eigene Punkte vor dem Meeting der Agenda hinzufügen musste und sich generell besser an dieser orientiert wurde, wurden die Meetings produktiver und um einiges kürzer.

Ausreichende Puffer vor Meetings bei Nutzung des öffentlichen Nahverkehrs

Wiederholt machten wir die Erfahrung, dass es im öffentlichen Nahverkehr rund um Frankfurt und Darmstadt zu zum Teil erheblichen Verspätungen und Ausfällen kam. Als Gegenmaßnahme haben wir die Pufferzeiten verlängert, zu denen wir uns vor einem Kundenmeeting getroffen haben, was zumindest zu einem Teilerfolg geführt hat und insgesamt unsere Pünklichkeit verbessert hat.

Backlog Items präzise und für alle verständlich spezifizieren

Am Anfang der Projektimplementierung kam es häufiger vor, dass die Beschreibung eines Items schlüssig und verständlich erschien, bei der Implementierung allerding häufig Rückfragen und daraus größere teaminterne Nachbesprechungen entstanden. Somit wurde die Ausführlichkeit der Beschreibung überarbeitet und ab diesem Zeitpunkt lieber überdeutlich und bis ins kleinste Detail spezifiziert, um keine Fragen offen zu lassen.

Kommunikation ist der Schlüssel zum Erfolg

Es stellte sich heraus, dass bei der Implementierung von zwei thematisch nahe beieinander liegenden Backlog-Items durch zwei verschiedene Teammitglieder beide nahezu dasselbe implementierten. Grund hierfür war, dass bei der Erstellung der Backlog-Items noch nicht ersichtlich war, dass die beiden Attribute, für die jeweils ein Backlog-Item erstellt wurde, in Wahrheit ein und dasselbe Attribut waren. Nach diesem Vorfall waren alle Teammitglieder dazu angehalten, häufiger mit Teammitgliedern zu kommunizieren deren Aufgabenbereiche den eigenen thematisch nahe lagen und jeden Verdacht der Doppelarbeit sofort zu äußern.

Verwendete Tools