2010-2011 - Grossbank, Systementwicklung/Support, Bloomberg, Front Arena
Seit Mai 2010 arbeite ich als System-Entwickler/Betreuer bei einer Großbank in der nähe von München. Ich unterstütze, erweitere, überwache und dokumentiere die Schnittstellen zu zwei Bloomberg Marktdaten Applikationen, BPipe, auf der Basis von Python mit einer PythonBoost-Schnittstelle zur BPipe-API, und Datalicense, auf der Basis von Python und Java/SOAP. Hauptthemen sind Performanzverbesserungen im BPipe-Programm und Stabilisierung der echtzeit Preislieferungs-Mechanismus von BPipe nach Front Arena. Ausserdem bin ich Mitglied des Support-Teams für zwei Front Arena Installationen, eine Windows-basiert und eine unter Unix/Solaris. Typische Aufgaben sind die Behandlung von Sonderanfragen nach Daten oder Reports, inklusive Programmieranpassungen, die Fehlersuche bzw. -behebung sowie normale, tägliche Instandhaltung der laufenden Systemen.
2010 - Grossbank, Migrationsprojekt, Front Arena
In 2010 arbeitete ich an zwei Projekten bei einer Großbank in München. Das Hauptprojekt war die Migration von einem alten Front Arena System nach Murex. Meine Aufgabe war die Entwicklung einer Gruppe von Programmen und Skripten zum Extrahieren von allen noch lebenden Trade-Daten aus Front Arena. Diese Daten wurden laufend und am Stichtag dem Murex-Team für die Konvertierung und Importieren bereitgestellt. Ausserdem analysierte und dokumentierte ich bestehende Schnittstellen und Abfragen mit dem Ziel, Arbeitsspezifikationen herzustellen, wonach die Funktionalität in Murex nachgebildet werden konnte. Das Zweitprojekt handelte sich um den Entwurf und Implementierung einer Abfrage/Schnittstelle in Front Arena für die Übermittlung (Backloading) vom Altbestand an IRS und OIS Swaps aus Front Arena an SwapsWire, nach Maßgabe des 'SwapsWire Backload Cookbooks'.
2009 - Förderbank, Entwickler, Front Arena
Arbeitete als Entwickler in der Gruppe IT-Handel einer Förderbank in Düsseldorf. Meine Arbeit konzentrierte sich auf die Überarbeitung und Erweiterung zweier Prozessen, das Mark-to-Market Programm und die Marktgerechtigkeitskontrolle. Das Erste besteht aus Optimierungen und bank-spezifischen Funktionserweiterungen zum standard-MtM-Produkt des Herstellers. Das Zweite besteht aus einem Back-End, der Neugeschäfte erfasst und sie in Echtzeit nach Marktbedingungen und konfigurierbaren Toleranzregeln beurteilt, und einem Front-End, in Prime integrierten, GUI Programm, womit die Risikomanager die regelabweichenden Geschäfte identifizieren, kontrollieren und letztendlich absegnen können. Bei diesen Arbeiten waren Reverse-Engineering der bisherigen Prozessen, Analyse, Austausch mit den Risikomanagern, Implementierung, Testen und Dokumentieren mit dabei. Eine Zusatzaufgabe bestand aus der Implementierung und Integration eines Prototyps eines Fix-Protocol Agents (QuickFix) mit einer Schnittstelle zu Front Arena.
2007-2008 - Grossbank, Produktverantwortlicher, Front Arena
Arbeitete als alleiniger technische und fachliche Systemmanager und -betreuer für das Front Arena-Gesamtsystem (bei dessen Einführung ich 2002/3 mitwirkte) für eine grosse Bank in München. Meine Aufgaben schlossen die viele von den Börsen vorgegebenen Upgrades, die Aufrechterhaltung der Systemstabilität und Kompaktheit, trotz stets steigender Datenvolumen, die Einrichtung und Pflege verschiedenster Benutzer, die Problemdiagnose und -behebung und das Sauberhalten der Schnittstellen und Daten ein. Die breite Palette meiner Aktivitäten schenkte mir eine intime Kenntnis aller Aspekten eines Front Arena Systems und brachte mich in engen Kontakt mit den Change-Management Systemen und Usancen der Bank innerhalb einer komplexen Systemlandschaft.
2006-2007 - Grossbank, Projektmanager, Front Arena/Heterogene Umgebung
Arbeitete als Projektmanager für die Einführung und Erstintegration einer neuen Front Arena 2.2 Plattform für eine neue Aktienderivaten- Handelsgruppe bei einer grossen deutschen Bank in Zürich. Koordinierte alle Aspekte des FA-Teilprojekts vom Hardware- und Softwareinstallation und -konfiguration und Schnittstellen zu anderen Systemen, zur Befriedigung der Anforderungen des Handelsteams, Middle-Office, Compliance, Business und des Vendors. Traf agressiven 'Go-Live' Zieltermin nur acht Wochen nach meiner Ankunft im Projekt. Normalisierte die Daten- und Arbeitsabläufe, inklusive Training des Middle-Office, und stabilisierte das System, um es auch langfristig Betriebstauglich zu machen.
2006 - Grossbank, Kontrollprogramm-Entwickler, Front Arena/Python/Win32Com
In 2006 arbeitete ich als Entwickler für eine grosse Bank in Frankfurt. Es ging um ein Kontrollprogramm, in dem Bausteine für die Ausführung der P&L-Funktion zusammengestellt werden konnten. Die Bausteine konnten in einer Konfigdatei beliebig kombiniert werden und bestanden aus folgende Schritttypen: ASQL-Berichte, PortfolioSheet-Berichte, Hochladen zu Access bzw. Excel, Aufrufe zu VBA-Prozeduren, und Mailen mittels LotusNotes. Existierende Berichte habe ich dann als Beispielnutzung in das Programm eingebunden. Benutzte Komponente: Front Arena, AEL/ACM/Python, Tkinter, Win32Com, ASQL, ADFL, cygwin, cvs, Access, Excel, Lotus Notes Mail.
2005 - Landesbank, Schnittstellen-Entwickler, Front Arena/Python/Sybase
Während 2005 diente ich in der Mannschaft "Front-Arena" einer grossen Bank in München. Es kamen viele diverse Aufträge zu mir; Neuentwicklungen, Programmänderungen, Nachbesserungen, Fehlersuche und -analyse und insbesondere Performanzfragen. Ein Schwerpunkt ist Datenmengenmanagement gewesen; Aggregierung, Archivierung und Löschung. Benutzte Komponente: Front Arena, Sybase, OOP, AEL/Python, SQL, sh, cvs, SUN Solaris.
2004 - Grossbank, Schnittstellen-Entwickler, Front Arena/Python/Tkinter/Sybase
In 2004 arbeitete ich als Schnittstellen-Entwickler für eine grosse Bank in Frankfurt. Es ging um a) eine Preis- und Volitäts-Schnittstelle für den Mark-to-Market Prozess und b) eine Trade-Schttstelle für den Handel in Aktienanleihen. Die Informationen werden zuerst über eine GUI (Python/Tkinter) bestellt und dann kommen über Mercator an. Sie werden abgeholt, in einem AMBA/AEL/Python-Hook bearbeitet und fliessen dann in die Front Arena Datenbank hinein. Quittungen werden ebenfalls durch einen Hook erzeugt und an Mercator zurückgegeben. Interessantes dabei: ich habe Tkinter mit AEL so integriert, dass beliebige GUIs entworfen und aus Atlas erreicht werden können. Ich habe Objektklassen und einen Rahmen geschaffen, für die leichte Entwicklung von weiteren AEL-Hooks. Benutzte Komponente: Front Arena, Sybase, OOP, AEL/Python, Tkinter, SQL, sh, cvs, ClearCase, SUN Solaris, Excel.
2002-2003 - Grossbank, Integrator/Entwickler, Front Arena/Sybase/Perl/Solaris
Mein Hauptprojekt 2002-2003 war Integrationsarbeit in einem Team zur Einführung des Wertpapier-Trading- und Positionierungssystems Front Arena zur Risikomanagement im Aktienbereich einer grossen Münchener Bank. Ich fungierte auch als cvs-Admin. Zuständig war ich für: Entwurf, Implementierung, Pflege und Dokumentieren von Batch Programmen und externen Datenschnittstellen, Fehleranalyse und -Behebung, Performance-Test, -Analyse und -Verbesserung auf Applikations- und Datenbank-Ebene, Software Versionsverwaltung. Folgende Komponente wurden benutzt: Front Arena, Sybase, Unix, perl, python, SQL, sh, cvs, SUN Solaris.
2003 - Kabelinfrastruktur, Entwickler, Informix/Perl DBI/Solaris
Ein Zwischenprojekt in 2003 für einen Provider von Kabelinfrastruktur bestand aus zwei Teilen. 1) Die Einführung von cvs mitsamt Importieren existierender Applikationen; dazu stellte ich die GUIs WinCVS und tkcvs (auf der basis von Cygwin/XFree86) bereit. 2) Der Entwurf und Implementierung von einem Modul für asynchrone, verteilte Updates von Stammdatentabellen, inklusiv der automatischen Anpassung von Fremdschlüsselwerten. Benutzte Komponente: perl mit DBI/DBD::Informix, Trigger, Stored-Procedure, SQL unter Informix auf Solaris. Nebenbei konfigurierte ich mehrere RAID-Festplatten unter Solaris für die Informix-Datenbank.
2001 - Grossbank, Upgrade-Analyst/Entwickler, Kondor+/Sybase/Solaris
Mein voriges Hauptprojekt (2001 abgeschlossen) war die Anpassung/Upgrade einer Schnittstellen-Software zwischen dem Frontend Kondor+ und einer bankinternen Treasury-Backend-DB für eine grosse Münchener Bank. Die Bank migrierte von Kondor 1.9 auf 2.0; daher musste die Software angepasst werden, um mit den vielen damit verbundenen neuen Features und DB- und semantischen Unterschiede zurechtzukommen. Fachlich gesehen, übermittelt die Komponente die von den Händlern eingegebenen Money-Market und Foreign-Exchange Transaktionsdaten in Echtzeit und nachts im Batchverfahren von Kondor+ an eine Backend-Schnittstelle der Bank. Folgende HW/SW-Komponente wurden benutzt: Kondor+, Sybase, Unix, C, SQL, sh, cvs, Solaris.
2000-2003 Cirrus Logic, CRM-Entwicklung/Wartung, Access/NT
Mein Zweitprojekt 2000-2003 war die Pflege/Wartung einer internen CRM-Applikation für die europäischen Niederlassungen eines US-Amerikanischen Chip-Herstellers. Das System hatte ich 2000 vollständig re-engineered aus dem Entwurf eines nicht-Informatikers. Es war eine Access-Applikation mit getrennten Programm- und DB-Teilen wobei Datenänderungen durch Replikation im Intranetz vom NT-Server aus propagiert werden. Mit Windows- und Office-Upgrades habe ich viel kämpfen müssen. Die enthaltenen Datenentitäten sind Produkt, Preis, Kunden, Distributor, Project, Forecast, User und Ereignis. Alle Daten werden über Forms eingegeben; Visual Basic Module prüfen sie und steuern den Ablauf; viele Reports mit Excel-Export sind auch vorhanden. Einen automatisierten Export/Import für Forecasts erlaubt es externen Partnern, Daten per Excel-Spreadsheet in das System einzugeben.
1999 - Epcos, EDI/Lagerverwaltung-Entwicklung, Access/NT
Voriges Projekt (bei Epcos) war eine MS Access-basierte Applikation für ein Konsignationslager. Sie akzeptiert EDI-Eingaben von den Geschäftspartnern, berechnet die aktuellen Warenbestände, macht intelligente Auffüllbestellungsvorschläge, und generiert die entsprechende EDI-Ausgaben, um sie durchführen zu lassen. Natürlich sind viele verschiedene Berichte auch dabei.
1999 - Epcos, EDI-Spezifikationsautor, EDIFACT
Das Projekt zuvor (auch Epcos) war die Spezifikation von vielen Umsetzungen zwischen verschiedenen Kunden EDIFACT-Versionen und der in-house Version, für mehreren EDI-Nachrichtentypen. Dann überwachte ich das Implementieren von den Spezifikationen und prüfte, daß alles bei den Kundenanbindungen und Datendurchfluß klappte.
1997-1999 - Siemens/SBS - Entwicklung/Partnerpflege/Betrieb, EDI
Andere Projekte (bei SBS) hatten mit DB-Datenmanipulation zu tun, um EDI-Partner und Nachrichten-Informationen nutzlich für die Supportpersonal zu machen. Eine Art Information-Mining. Ein anderes Projekt (bei SBS) war eine BS2000- und PC-basierte Applikation um unverständliche interne EDI-Fehlerberichte für die externen Partnern aufzubereiten und verständlich zu machen. Die Berichte werden dann automatisch an den Partnern per e-mail geschickt. Hierfür mußte ich eine ur-einfach zu benutzende Windows User-Interface für die Supportleute programmieren.Die Hauptarbeiten bei SBS waren im Rahmen von einem dauerhaften EDI-Partner-Pflegeaufgabe. Täglich bekamen wir Berichte über alle von den Partnern zugeschickten, fehlerhaften EDI-Nachrichten. Durch intensive Rücksprache mit den Partnern, bügelten wir alle Probleme aus. Wir waren auch für das Neuanschließen von neuen externen EDI-Partnern und deren damit verbunden Unterrichten zuständig.
1994-1996 - Eigene Firma, Entwicklung, C/Windows/DLL/Treiber
Für meine eigene Firma entwickelte ich ein spezialisiertes, Windows-basiertes Produkt, die eine einfache EDI-Fähigkeit bei kleinen Kunden von großen Distributoren ermöglichte. Die Entwicklungsumgebung dafür war Windows-Treiber und -DLL Programmierung mit Visual C++.
1992 - Grossbank, Schnittstellenentwickler, Sybase/Informix/ESQL/C
Für ein Software-Haus (Siemens-Nixdorf) für eine Bank (Dresdner) entwickelte ich eine ESQL/C-Emulationsebene, um eine Untermenge der Sybase ESQL/C-Schnitstelle auf der Basis von der Informix ESQL/C-Schnittstelle zu implementieren. Dabei habe ich auch die dafür notwendigen Sybase- und Informix-Servern konfiguriert und verwaltet.
1990-1992 - Banksoftwarehaus, DB-Entwickler/Admin, Sybase/ESQL/C
Für ein Software-Haus (Infosoft), das mehreren Banken diente, arbeitete ich als Datenbank-Programmer/Entwickler und -Administrator. Wir entwarfen und entwickelten eine API für die Inhouse-Applikationen auf der Basis von der Sybase-C-Schnittstelle, unter Verwendung von Stored-Procedures und Triggern. Außerdem diente ich als Installateur und Administrator von mehreren Sybase-Datenbanken auf vernetzten Unix-PCs, wobei ich viele administrative Werkzeuge schrieb.
1985-1989 - Gerichtsverwaltung, Programmier/Analyst, Unify/C/Unix
Bei dem administrativen Büro des US-Gerichtshofs (Federal Judicial Center) arbeitete ich als Programmierer/Analyst. Wir entwickelten ein System, um die Prozeßverwaltung zu modernisieren. Dieses war auf der Basis von der Unify Datenbank unter Unix. Dort habe ich alles mögliche in dem Projekt gemacht, inklusive Entwurf, Implementierung, Testen, Installation, DB-Design, Daten-Konvertierung, Optimierung und Applikationssicherheit.
1984 - NASA, Programmierer, COBOL/MVS/JCL
Vor langer, langer Zeit war ich auch mal COBOL Maintenance Programmierer (IBM 370/MVS/JCL) bei der NASA.