Dev-Interview mit Roland
In diesem Interview quatschen wir mit Roland von der CPU AG über Softwareentwicklung im Bankenbereich, Modernisierung von Legacy-Software und die Auswahl des richtigen Tech-Stacks – von Dev zu Dev.
Ilja: Hallo Roland! Erzähl einfach was über dich, was du machst, was CPU AG macht und dann schauen wir mal, wohin es uns verschlägt.
Roland: Wie alle nun wissen, bin ich der Roland. Ich bin seit 2019 bei der CPU. Ich hab mich ganz oldschool einfach als Full Stack Entwickler (Java / Angular) beworben. Ich habe mal vor langer Zeit Informatik studiert – das war noch zur Jahrtausendwende. Ich habe dann lange Zeit andere Sachen gemacht und bin jetzt wieder zur Informatik zurück.
Die CPU steht auf zwei Beinen. Die interne Entwicklung, wo wir für diverse Banken Software entwickeln, zum Beispiel ein Refinanzierungsregister oder die Abbildung von internen Abläufen bei der Baufinanzierung. Die Anwendungen sind lange im Einsatz, manche seit 10-15 Jahren. Diese müssen natürlich immer auf den aktuellen Stand gehalten oder manchmal auf moderne Tools / Sprachen / Architekturen umgestellt werden. Im internen Team sind wir 8 Entwickler:innen und wir haben noch eine Menge Consultants die extern bei Kunden eingesetzt werden.
Ilja: IT Dienstleistungsunternehmen gibt es ja wie “Sand am Meer”. Was unterscheidet euch von anderen? Was zeichnet euch aus?
Roland: Wir sind spezialisiert auf die Bankenbranche, wir haben also das Know-How über Abläufe in Banken und was die rechtlichen Voraussetzungen sind – das ist wichtig für die Produktentwicklung. Wir könnten natürlich sagen, wir gehen in den Autohandel – aber das würde nicht funktionieren.
Die Erstellung von Lieferungen ist einer meiner persönlichen Arbeitsbereiche. Ich bin verantwortlich für den gesamten Build. Unsere Software wird im Jenkins gebaut. Ich erstelle und warte die gesamten Jenkins-Skripte, die Jenkins-Umgebung und was als Ergebnis für den Kunden herauskommt. Ich führe zum Beispiel auch die Installation beim Kunden durch. Bei uns sitzt man als Entwickler:in nicht im stillen Kämmerchen – so wie man sich das Klischeehaft vlt. vorstellt – sondern ich hab stets Kontakt mit dem Kunden. Ich bin also nicht nur in der Code-Erstellung tätig, sondern ich bin in allen Bereichen mit dabei.
Ilja: Wie geht ihr bei den Builds im Jenkins vor? Macht ihr Pipeline-as-Code mit Groovy und Libraries, oder noch der klassische Weg über UI?
Roland: Das war eins der Projekte, die ich in den letzten Wochen auf meinem Tisch hatte. Die Umstellung der ganzen Jenkins-Umgebung auf eine Shared Library. Ich habe also die ganzen Groovy Bibliotheken aufgesetzt, die Pipelines umgestellt und entsprechend die Mitarbeiter dahin gebracht, dass sie eigenständig ihre Pipelines erstellen können. Denn es soll so sein, dass jeder geschwind eine eigene Pipeline erstellen kann. So eine Pipeline besteht nun nicht mehr aus dutzenden Zeilen Code, sondern aus einem Konfigurationsblock und der Rest ist schon in der Shared Library hinterlegt. Es war ein sehr spannendes Projekt, weil es nicht so viel mit Coden zu tun hatte.
Ilja: Ein Teil von CI / CD ist ja auch immer Continuous Delivery. Bei einer Web-Plattform wie EntwicklerHeld können wir mehrfach am Tag deployen,auch vollautomatisiert. Ich kann mir aber vorstellen, dass das im Bankensegment anders oder gar nicht funktioniert?
Roland: Das mit der CD (Continuous Delivery) ist natürlich hochgegriffen. Wir haben keinen Einfluss / direkten Zugriff auf die Umgebungen beim Kunden. Die sind abgeschottet. Tatsächlich erstellen wir nur Lieferungen. Die Installation beim Kunden ist dann ausgelagert. Da muss jetzt niemand hinfahren, wir können das Remote über abgesicherte Verbindungen machen bzw. begleiten. Falls ein Fehler auftritt, sind wir direkt an der Quelle und wissen eher, wo das Problem ist.
Ilja: Spannend. Wo bist du noch involviert?
Roland: Wenn es ums Codieren geht – dann eher im Backend. Da haben wir einen Standard-Stack: Java / Spring Boot. Das hab ich hier mit aufgebaut. Da kenn ich mich am besten aus. Beim Frontend arbeite ich auch mit – bin aber eher nicht so der Designer, der hübsche Oberflächen macht. Aber ich beweg mich in beiden Bereichen – Frontend und Backend.
An Java haben sich schon so viele Totengräber zu Tode gegraben und es lebt immer noch.
Ilja: Wenn ich Java höre, frage ich immer gerne nach der Version, die eingesetzt wird? Manche Unternehmen sind da immer noch im Java 6 Bereich unterwegs. Wie ist das bei euch?
Roland: Wir haben tatsächlich noch ältere Versionen im Einsatz. Also Altsoftware, die auf Java 7 läuft. Es gibt auch keine Bemühungen, diese auf eine höhere Version hochzusetzen, der Aufwand wäre gigantisch, der Effekt wäre minimal. Bei den Neuentwicklungen sind wir mit Java 11 eingestiegen und haben mittlerweile auf Java 17 hochgezogen, kompilieren aber noch gegen Java 11 und verwenden dementsprechend noch keine Features von der 17. Generell werden wir da nur die LTS Versionen verwenden, also keine halbjährlichen Zwischenversionen, das ist einfach zu viel Aufwand.
Ilja: Der Support für Java 7 ist ja abgelaufen, ist das ein Problem? Vor Allem im Bankenumfeld?
Roland: Bei der Frage muss ich leider passen, weil ich mit den alt Systemen wenig zu tun habe. Aber selbst wenn es noch Support gibt für eine Java Version, müssen die entsprechenden Updates auch eingespielt werden und das passiert immer über ein Change Request vom Kunden, das machen wir nicht auf dem System des Kunden proaktiv.
Ilja: Wenn ich Banken höre, da kommen bei mir immer bestimmte Topics hoch. Habt ihr noch viel mit Cobol Systemen zu tun? Da gibt es ja wahrscheinlich keine REST Schnittstelle mit der man sich einfach integrieren kann?
Roland: Also ich persönlich bin mit so alten Systemen noch nicht in Berührung gekommen. Aber wir ersetzen gerade in einem Projekt eine ältere Software mit einer Neuentwicklung. Und da sieht man im Code an vielen Stellen, dass die Alt-Software noch auf Terminal basiert. Da ist die Eingabe dann rein mit den Keycodes. Aber die Software ist im Einsatz und wird gewartet. Diese Systeme abzulösen wird noch länger brauchen.
Ilja: Du hast ja gesagt, dass ihr eure Altsysteme modernisiert oder durch neue ersetzt. Für neue Mitarbeiter:innen ist es meiner Erfahrung weniger abschreckend in aktuelleren Systemen zu arbeiten, als mit Systemen, die alte Technologien oder einen exotischen Stack verwenden. Wie siehst du das?
Roland: Da kriegst du niemanden mehr. Deswegen ist ein ganz wichtiger Faktor bei der Auswahl des Software-Stacks: Wie ist die Verfügbarkeit von den entsprechenden Entwickler:innen? Wenn man also überlegt, nimmt man statt Angular vlt. VueJS oder React, muss man direkt sagen, Angular hat eine größere Entwickler:innenbasis. Oder beim Backend: Nimmt man was anderes als Java wirds in Deutschland wieder eng – Java kann jeder, durch die Ausbildung und Hochschulen. Viele haben es im Einsatz, es gibt umfangreiche Bibliotheken, wo eigentlich alles abgedeckt wird. Die ganz Infrastruktur wird schon bereitgestellt. An Java haben sich schon so viele Totengräber zu Tode gegraben und es lebt immer noch.
Ilja: Auf jeden Fall. Ich finde es spannend, dass ihr das so macht. Wir sprechen von Fachkräftemangel, aber die Entscheidungen über die Technologien werden in der Entwicklungsabteilung beschlossen – die den Recruiting Aspekt oft nicht im Kopf hat.
Roland: Die Entscheidung über die verwendeten Technologien hat weitreichende Konsequenzen auf Recruiting, aber auch auf die spätere Wartung und Betrieb. Du kriegst die Technologien nicht mehr so schnell los, wenn sie einmal beim Kunden laufen.
Deswegen ist ein ganz wichtiger Faktor bei der Auswahl des Software-Stacks: Wie ist die Verfügbarkeit von den entsprechenden Entwickler:innen?
Ilja: Lass uns tiefer in den Entwickler:innen Alltag bei CPU gehen. Was ist so eine typische Aufgabe? Nehmen wir mal an, ich fange frisch an, wie läuft das ab?
Roland: Je nachdem, was deine Präferenzen sind, also Backend oder Frontend, könntest du im Frontend einen abgegrenzten Dialog bauen. Es gibt zum Beispiel in einer Software eine Systemeinstellungsseite und da kommen immer wieder neue Dialoge hinzu wenn es neue Konfigurationsoptionen gibt. Dort kann man ganz abgegrenzt einen Dialog entwickeln, diese in das ganze Framework einbinden, die Navigation einbauen, die Anbindung ans Backend durchführen – ggf. das Backend im entsprechenden Endpunkt um die neue Option erweitern. Das wäre ein kleines abgegrenztes Thema für den Anfang. Nach ein paar Monaten Einarbeitung ist es nicht unüblich, dass man ein ganzes Projekt für einen Kunden zugeteilt bekommt.
Ilja: Was war deine Highlight-Aufgabe bis jetzt bei der CPU AG?
Roland: Die Banken sind ja noch durchaus sehr konservativ, wenn es darum geht, wie Technologie eingesetzt wird und auch einer Cloud Technologie gegenüber sind sie sehr zurückhaltend eingestellt. Es gibt dafür natürlich Gründe und ganz spezifische Vorgaben von der BaFin, wie die Datensicherheit und die Auslagerung von Daten behandelt werden. Was ich aber gemacht habe, ist unsere ganze Software cloud-fähig zu machen. Also Frontend, Backend, Datenbank komplett in die Cloud umgesetzt. Das wird noch länger in meiner Erinnerung bleiben.
Ilja: Was waren da so die Herausforderungen bzw. die Stolpersteine?
Roland: Also bei mir war es zum Beispiel die erste Berührung mit Kubernetes und den ganzen Technologien, die dahinter stehen. Docker ist ja dann eine Grundtechnologie, die man braucht – auch da musste ich mich erstmal einarbeiten.
Zur Zeit ist unsere Architektur: Frontend in Angular, ausgeliefert von einem NGINX. Im Backend sind die meisten Komponenten Java, die im Tomcat laufen. Wir haben aber auch ein paar Legacy-Komponenten in C/C++ oder in C#, die aufgrund des hohen Aufwands nicht neugeschrieben werden. Da haben wir sogar eine gewisse Bindung, dass wir das ganze im Microsoft IIS laufen lassen müssen. Bei IIS sind wir auf einen Microsoft Server angewiesen und Microsoft Server und Docker Container sind noch – sagen wir es mal so – ein bisschen speziell. Und dieses ganze “Gebäude” in die Cloud zu portieren, das war eine spannende Geschichte.
Ilja: Klingt nach einem coolen Projekt – auch für die persönliche Weiterentwicklung. Man hat dann bei zukünftigen Entscheidungen im Kopf, dass man bestimmte Sachen in neuen Modulen nicht mehr einbaut, weil sie bei der Cloud Migration im Weg stehen würden.
Roland: Richtig. Es ist nicht das tägliche Brot und man muss sich entsprechend immer wieder einarbeiten und reinfuchsen – learning by doing.
Ilja: Ist Kotlin als Technologie für euch ein Thema? Als nächster Evolutionsschritt für Java-Projekte?
Roland: Für mich gibt es bei all diesen Java-Derivaten keinen richtigen Grund da rein zugehen, es sei denn, es wird von dem unterliegenden Stack / Framework erwartet. Zum Beispiel Groovy für Jenkins oder Kotlin für Android – da komm ich nicht drum rum. Aber ich muss nicht “jeder Sau, die durchs Dorf getrieben wird, nachrennen”. Klar, ist der Code an der einen Stelle etwas kürzer oder etwas schöner. Aber da könnte man auch sowas wie Lombok einsetzen – einmal eingerichtet sparst du dir 90% Code-Schreiben, musst aber keine neue Sprache dafür lernen. Das sind wir wieder bei der Wahl des Tech-Stacks.
Ilja: Roland, vielen Dank! Wir haben die Zeit gut gefüllt und es hat mir sehr viel Spaß gemacht!
Roland: Mir auch!
PS: Wir sind immer auf der Suche nach neuen motivierten Entwickler:innen für unser Team! 😊
Über CPU AG – So beschreiben wir uns selbst
Die CPU Consulting & Software GmbH ist im Bereich Professional Services seit mehr als drei Jahrzehnten als erfolgreicher IT-Dienstleister im Bankenumfeld tätig. Als Tochterunternehmen der CPU Gruppe richten wir unsere Kompetenzen auf die erfolgreiche Umsetzung von Softwareprojekten unserer Kunden vor Ort aus.
