Persönliche Vorbereitung auf das technische Gespräch bei der dwpbank — kein offizielles dwpbank-Dokument.

Ali Chaghou

Ich arbeite dort, wo gewachsene Rechenzentrumslandschaften und moderne Cloud-Plattformen aufeinandertreffen.

Mein Weg in die IT begann nicht mit einem Studium, sondern im laufenden Betrieb. Dort habe ich gelernt, dass eine technische Veränderung nur dann gut ist, wenn sie für Prozesse, Menschen und den späteren Betrieb funktioniert.

DevOps Engineer · Hybrid Cloud / Data Center

Mein Weg

Vom laufenden Betrieb zu Plattformen, die andere tragen

Mein Weg begann nicht vor einem Bildschirm, sondern dort, wo Systeme im Alltag funktionieren müssen.

  1. Operativer Betrieb

    Ich startete im Wareneingang, Versand und in der Kommissionierung. Schon damals war mein Anspruch nicht einfach, die eigene Aufgabe abzuarbeiten. Für mich zählte, ob am Ende alle Sendungen vollständig und rechtzeitig das Haus verließen.

    Dort habe ich gelernt, Verantwortung nicht an der eigenen Zuständigkeit enden zu lassen.

  2. Produktionslogistik

    Mit dem Wechsel in die Produktionslogistik kam ich den Systemen hinter den Abläufen immer näher.

    Lagerverwaltung, Q-Point, Kanban, Kaizen, ERP-Umstellungen und erste Systemanbindungen waren für mich keine isolierten IT-Themen. Ich kannte die Menschen, die Prozesse und die Auswirkungen, wenn etwas nicht funktionierte.

    So wurde ich Schritt für Schritt zur Verbindung zwischen Betrieb und IT.

  3. Automatisierung

    In der Werkzeugausgabe habe ich erlebt, was gute Digitalisierung bewirken kann.

    Bestellungen, Reservierungen und die Zuordnung von Werkzeugen, Zeichnungen und Messmitteln wurden miteinander verbunden. Dinge, die vorher gesucht, manuell zugeordnet oder neu bestellt werden mussten, wurden nachvollziehbar und zuverlässig verfügbar.

    Damit verbesserte ich einen Prozess, obwohl dadurch auch ein Teil meiner eigenen bisherigen Aufgabe entfiel.

    Rückblickend begann genau dort meine heutige Haltung:

    Ich halte nicht an Aufgaben fest. Ich möchte, dass das Ergebnis besser wird.

  4. Der bewusste Wechsel

    Der Schritt in die IT war keine Flucht aus einer schlechten Situation.

    Ich hatte mir bei STAHLWILLE über viele Jahre Vertrauen, Verantwortung und eine sichere Position aufgebaut. Gleichzeitig entwickelte ich privat Websites, baute mein Homelab auf und merkte, dass ich fachlich noch weitergehen wollte.

    Deshalb absolvierte ich neben Beruf und meiner Verantwortung als Vater ein Full-Stack-Bootcamp.

    Ich entschied mich bewusst dafür, noch einmal Lernender zu sein und auf einem neuen Gebiet wieder von vorne Vertrauen aufzubauen.

  5. Cloud und Plattformen

    Heute arbeite ich mit AWS, Azure, hybriden Netzwerken, Security, Infrastructure as Code, CI/CD und geschäftskritischen Integrationen.

    Die Technologien sind andere geworden. Meine Art zu denken ist dieselbe geblieben:

    Ich möchte verstehen, wie ein vollständiger Ablauf funktioniert, wo Abhängigkeiten entstehen und wie wir Systeme sicherer, stabiler und für andere besser betreibbar machen.

  6. Technik ist nie nur Technik

    Parallel zu meiner operativen Arbeit war ich über viele Jahre im Betriebsrat und im Wirtschaftsausschuss aktiv.

    Dadurch habe ich früh gelernt, Veränderungen nicht nur technisch zu bewerten. Jede Entscheidung hat auch wirtschaftliche Auswirkungen und betrifft Menschen, die später mit der Lösung arbeiten müssen.

    Diese Perspektive begleitet mich bis heute.

Meine Haltung

Oft entscheidet nicht die Antwort über das Ergebnis, sondern die Frage, die wir uns am Anfang stellen.

Die meisten guten Lösungen beginnen für mich nicht mit einem Werkzeug, sondern mit der richtigen Frage. Oft ist die naheliegende Aufgabe gar nicht die eigentliche.

Aus der Praxis

Zwei Welten sicher verbinden

QuickSight und eine moderne AWS-Analytics-Plattform trafen auf eine geschäftskritische NAV-Umgebung mit SOAP und NTLM. Ich entwickelte eine serverlose Integrationskomponente mit privatem API Gateway, Lambda, Secrets Manager, IAM sowie Logging und Monitoring.

Die eigentliche Aufgabe lag weder ausschließlich in AWS noch in NAV, sondern in der sicheren Verbindung dazwischen.

Die bessere Frage stellen

Ein Dienstleister wollte jede Talend Runtime Engine manuell per SSH installieren. Statt nur den Zugriff abzusichern, habe ich den Prozess grundsätzlich hinterfragt und eine reproduzierbare OpenTofu-/Terraform- und GitLab-CI/CD-Lösung aufgebaut.

Wir mussten den manuellen Prozess nicht besser absichern. Wir konnten ihn weitgehend vermeiden.

Warum die dwpbank

Modernisierung ist für mich kein Abriss, sondern ein kontrollierter Umbau im laufenden Betrieb.

Mich interessiert nicht in erster Linie die Wertpapierabwicklung selbst, sondern die kritische technische Infrastruktur dahinter und die Verantwortung, die damit verbunden ist.

Die Verbindung aus gewachsenen Systemen, Cloud-Transformation, Regulierung und hohen Sicherheitsanforderungen entspricht genau dem Umfeld, in dem ich fachlich tiefer werden möchte.

In den bisherigen Gesprächen hatte ich außerdem den Eindruck, Menschen kennenzulernen, von denen ich viel lernen und mit denen ich gemeinsam langfristig Wert schaffen kann.

Von den Möglichkeiten, mit denen ich mich derzeit beschäftige, ist die dwpbank das Umfeld, in dem ich mich langfristig am stärksten sehe.

Resilienz sichtbar machen

Eine Störung ist nicht nur ein technischer Zustand. Entscheidend ist, welche Signale wir erkennen, welche Annahmen wir prüfen und welche Maßnahmen wir bewusst nicht ausführen.

Bereit
Data Center
Publisher aktiv
stabil
Hybrid-Strecke
24 ms
stabil
Queue
0 Events
bereit
Cloud Consumer
Verarbeitung aktiv
healthy
Monitoring
kein Alert
ok

Normalbetrieb. End-to-End-Verarbeitung ist stabil.

Systemstatus
Stabil
Latenz
24 ms
Queue-Tiefe
0
Consumer
Healthy
Datenverlust
0
Entscheidungsprotokoll
  1. Noch kein Incident. Starte oben, um Erkennung, Bewertung und Entscheidung nachzuvollziehen.

Vom Reden zum Bauen

Ich wollte meine Arbeitsweise nicht nur beschreiben. Deshalb habe ich die Nahtstelle zwischen Data Center und Cloud in einem reproduzierbaren Labor umgesetzt – mit einer störbaren Verbindung, Entkopplung über eine Queue, Monitoring sowie einem reproduzierbaren Störungsszenario mit Erkennung und Wiederherstellung.

Technischen Showcase öffnen