2010 - Grossbank, Migrationsprojekt, Front Arena
Bisher in 2010 habe ich an zwei Projekten bei einer Großbank in München gearbeitet. Das Hauptprojekt war die Migration von einem alten Front Arena System nach Murex, obwohl meine Arbeit nur mit der Front Arena-Seite zu tun hatte. Meine Aufgabe war die Entwicklung einer Gruppe von Programmen und Skripten zum Extrahieren von allen Daten aus Front Arena, die mit den noch lebenden Trades zu tun hatten. Diese Daten werden laufend und am Stichtag dem Murex-Team bereitgestellt. Ausserdem analysierte und dokumentierte ich bestehende Schnittstellen und Abfragen mit dem Ziel, dem Murex-Team Arbeitsspezifikationen zu geben. 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.
Deutschland: z.Zt. nur München, wegen meines neuen Kindes