ITler in der Finanzbranche: Alles, nur nicht streng und öde

Viele Entwickler scheuen sich, bei einer Bank anzufangen. Dabei sind die Vorurteile über die Arbeit in der Finanzbranche längst nicht mehr wahr.

Ein Erfahrungsbericht von Alex Mansour veröffentlicht am 19. Juni 2022, 9:00 Uhr

Ob es in der IT von Banken in Wirklichkeit so zugeht? (Bild: Pexels)

Immer wieder höre ich im Freundes- und Bekanntenkreis diese Vorurteile: Die Arbeit bei einer Bank sei eintönig und langweilig, die Projekte träge und uninteressant. Ob man immer im Anzug arbeiten müsse und ob die Leute eingebildet seien, werde ich auch oft gefragt. Als jemand, der schon länger bei einer Bank arbeitet, kann ich da nur sagen: Diese Vorurteile stimmen überhaupt nicht (mehr).

Vorurteil 1: Verkrustete Strukturen

Eine Bank ist in der Regel ein großes Unternehmen und ein gängiges Vorurteil lautet: Je größer das Unternehmen, desto verstrickter ist dessen IT-Landschaft. Updates von Technologien oder das Migrieren alter Systeme wird so immer teurer und aufwendiger, die Risiken werden so groß, dass Software nicht mehr auf dem neuesten Stand gehalten wird. Die Folge sind jede Menge technische Schulden.

Wir setzen dagegen moderne Projekt-Methodologien wie Dev-Ops und SAFe ein. Durch das Zurückgeben der Verantwortung von Systemen an ihre Entwickler braucht man zudem kein dediziertes Wartungsteam mehr, das ohnehin unmöglich alle fachlichen und technischen Nuancen jeder Applikation kennen kann.

Die Verantwortung dafür, die eigene Arbeit zu pflegen und zu warten, hat sich bei meiner Firma bewährt, die Softwareentwicklung ist dadurch eindeutig nachhaltiger. Wir bieten für unsere Nutzer während der normalen Arbeitszeiten Support an. Funktioniert ein System nicht, können sie ein Ticket erstellen und das Problem wird gelöst.

Damit nicht immer nur eine Person diese Aufgabe hat, haben wir einen Plan, in dem steht, welche Mitarbeiter wann für Betriebsprobleme verantwortlich sind. Der oder die Zuständige muss dann zusehen, dass das Problem behoben wird. Allerdings geht es primär darum zu merken, dass ein Ticket angekommen ist. Es muss nicht zwingend von demjenigen gelöst werden, der gerade Schicht hat.

Für diese Arbeit werden neue Mitarbeiter vom Team geschult. Wenn man die Applikationen einigermaßen im Griff hat und weiß, wie Probleme gelöst werden, wird man in den Plan mit aufgenommen. Natürlich will man lieber Entwicklungsarbeit leisten und keinen Support. Dennoch ist diese Arbeit wichtig und unser Team führt sie gewissenhaft aus.

Vorurteil 2: Veraltete Technologien

Ein weiteres Vorurteil ist, dass Banken träge sind, nicht mit der Zeit gehen und auf veralteten Programmiersprachen und Technologien hängen bleiben. Auch das erlebe ich anders. Der Gebrauch neuer Technologien ist möglich, da die Entwickler bei der Wahl der einzusetzenden Programmiersprachen und Frameworks sehr frei sind.

Zum Beispiel bauen wir momentan ein neues System, für das wir Kotlin einsetzen, die Applikation deployen wir in die Cloud. Außerdem werden Postgres-Datenbanken verwendet.

In den letzten Jahren wurden Angular und Typescript im Frontend bei uns sehr beliebt, im Backend wird dagegen meist auf Java und bekannte Frameworks wie Spring und JPA in Kombination mit Oracle-Datenbanken gesetzt.

Hier und da finden sich auch exotische Ausnahmen. So sind einige Systeme im Einsatz, bei denen man auf die Vorteile von künstlicher Intelligenz angewiesen ist.

Diese werden weder mit Java noch mit Angular entwickelt, sondern mit anderen, für diese Aufgabe besser geeigneten Werkzeugen gebaut (auf die ich nicht genauer eingehen kann). Es gibt jedenfalls keine verbotenen oder verpönten Standards, die unter keinen Umständen eingesetzt werden dürfen.

Und wie sieht es mit den anderen Vorurteilen aus? Lange Arbeitszeiten, dröge Projekte, strikte Kleiderordnung?