cashEngine eine Plattform fü den algorithmischen Handel von Cryptowährungen auf verschiedenen Börsen.
Verantwortlichkeiten:
Aktivitäten
cashEngine
Architektur, Design und Implementierung einer Microservices Plattform für automatisierten, Hochfrequenz- und Niedriglatenzhandel von Cryptowährungen mit eigenen Handelsstrategien.
Die Implementierung der Plattform folgt komplett modernen Modellen und Mustern wie zum Beispiel: Microservices Architektur, asynchrone und reactive Programmierung, ereignisgetriebene Nachrichtenverarbeitung, verteiltes und zustandsloses Design und NO-SQL Datenhaltung um ein Maximum an horizontaler Skalierbarkeit zu gewährleisten.
Die Core-Komponenten wurden in Rust neu implementiert.
Das Reisendeninformationssystem ist eine Cloud basierte Streaming-Plattform die Nachrichten aus verschiedenen Quellen empfängt, filtert, transformiert und an verschiedene Ziele veröffentlicht, mit dem Ziel Reisende und Personal mit Echtzeitinformationen über Reisen und Fahrzeuge zu versorgen.
Verantwortlichkeiten:
Aktivitäten
Analyse, Design, Implementierung, Pflege und Migration von Microservices. Das Reisendeninformationssystem ist eine Plattform, die aus hunderten von Microservices besteht und Echtzeitinformationen zu Reisen wie zum Beispiel Fahrten, Zwischenhalte, Gleise und Plattformen, Bahnhöfe und Stationen, hörbare Ansagen, Vehikel-Konfigurationen und -Features, Zugteile, Ankunft- und Abfahrtzeiten und vieles mehr zur Verfügung zu stellen.
Die Informationen kommen aus offiziellen Fahrplänen, physischen Sensoren, Prognoseautomaten, Benutzereingaben und anderen Quellen. Sie gehen an Reisende, Personal, Bahnhöfe und Busstationen, Fahrzeuge, Google und andere Ziele. Zuletzt werden sie auf Displays und Anzeigern in Stationen, an Gleisen und in Fahrzeugen selbst, auf Geräten des Personals, in Apps (DB Navigator) und Google angezeigt, sowie als Ansage an Bahnhöfen, Stationen und Gleisen durchgegeben und im DB Vertrieb weiterverarbeitet.
Mein Team ist für die Ausgangskanäle an verschiedene Abnehmer verantwortlich, welche diese Informationen hauptsächlich auf physikalische Ansager und Anzeiger an Bahnhöfen, Stationen, Gleise und in Vehikel bringen.
Technisch werden rund 30 Microservices betrieben, die Events aus Kafka Topics und RabbitMQ Queues in einem Kubernetes Cluster filtern, aggregieren, transformieren und verarbeiten und an verschiedene Abnehmer via RabbitMQ oder Kafka veröffentlichen. Jeder Microservice wird in mehreren partitionierten Instanzen betrieben, um einen hohen Durchsatz bei geringer Latenz zu gewährleisten.
In dieser Umgebung analysiere ich Geschäftsanforderungen, entwerfe und implementiere neue Services und Datenflüsse, erweitere und optimiere bestehende Services, und setzte Feature Requests um. Teil des Projektes beinhaltet eine Migration der kompletten Plattform in eine andere Cloud.
Die Kommunikation und Koordinierung aller beteiligten Teams und deren Mitglieder ist in einem sehr strikten Scrum und Scaled Scrum Prozess eingebettet.
(Name auf Anfrage) ist ein System das Kreditdaten von Institutionen, Unternehmen und natürlichen Personen sammelt und diese verschiedenen Institutionen wie die Europäische Zentralbank bereitstellt.
Verantwortlichkeiten:
Aktivitäten
Analyse, Design, and Implementierung von Optimierungen.
(Name auf Anfrage) sammelt massive Bestände von Kreditdatenmeldungen aus ganz Deutschland. Die Daten durchlaufen verschiedene Workflows wie Validierung, Aggregation und regelbasierte Engines. Einige dieser Workflows sind sehr kritisch und haben eine inakzeptable Laufzeit und sind somit das Ziel ständiger Optimierungen.
In meiner Rolle als Performance Optimierter analysierte ich einen dieser kritischen Workflows nach Optimierungsmöglichkeiten, um die Laufzeit signifikant zu senken. Des Weiteren basierte das System noch auf schwergewichtigen EJB Beans, welche ich zu CDI Beans migrierte.
Als Ergebnis wurde die Laufzeit des Workflows von rund 8 Stunden auf rund 4 Stunden optimiert, welche die Anforderungen der Fachabteilung erfüllte. Weitere Optimierungsansätze und Tests zeigten, dass durch Architekturänderungen und weitere Entwicklungsaufwände die Laufzeit sogar auf bis zu 15-30 Minuten gesenkt werden kann. Neben den Optimierungen und der CDI Migration half ich dem Team während der Release-Phase einige Blocker-Bugs zu beheben und migrierte den Test-Container von OpenEJB zu TomEE.
1&1 Telecommunication SE ist ein Provider für alle Arten von Telekommunikationsdiensten.
IONOS SE ist ein mit 1&1 eng verbundenes Unternehmen, dass Rechenzentrumdienste wie Webhosting, Domains, E-Mail-Hosting, Server und Private Cloud Lösungen anbietet.
(Name auf Anfrage) ist eine Abteilung in IONOS SE, welche verantwortlich das Produkt Dedicated Server betreibt.
Verantwortlichkeiten:
Aktivitäten:
(Name auf Anfrage) Carveout:
Analyse, Design, Orchestrierung and Implementierung einer Infrastrukturänderung welche durch die rechtliche Separation der beiden Unternehmen IONOS and 1&1 getrieben ist.
IONOS war ehemals ein Bereich innerhalb 1&1 welcher in ein eigenständiges Unternehmen ausgegliedert wurde. Aufgrund der gemeinsamen Historie sind beide Unternehmen noch sehr eng miteinander verflochten und nutzen daher noch gemeinsame Ressourcen wie die Master Database. Das Projekt (Name auf Anfrage) Carveout adressiert diesen Missstand. Die Master Datenbank ist eines der zentralen Ziele der Entflechtung mit dem Ziel 1&1 Geschäftsdaten strikt von IONOS rein technischen Daten zu trennen.
(Name auf Anfrage) Carveout führt darüber hinaus eine generelle Service Orientierte Architektur (SOA) ein, basierend auf RESTful Interfaces, um das Problem zu lösen, dass die Master Datenbank nicht mehr als Schnittstelle für technische Kommunikation zwischen verschiedenen Abteilungen zweckentfremdet, sondern als reiner Datenspeicher genutzt wird.
Meine Aufgabe besteht darin die konkreten Bedingungen, Anforderungen und Konsequenzen zu analysieren, um einen Fahrplan für die Implementierung der (Name auf Anfrage) Carveout-Änderungen für das (Name auf Anfrage) Team zu erstellen, und diese dann auch umzusetzen.
Dabei soll durch enge Zusammenarbeit mit Teams die abhängig von (Name auf Anfrage) -Diensten sind oder von denen (Name auf Anfrage) abhängig ist ein möglichst reibungsfreier Übergang garantiert werden.
Als Ergebnis wird 1&1 und IONOS SE auf voneinander unabhängigen Masterdaten operieren und versteckte Abhängigkeiten zwischen verschiedenen Diensten und Abteilungen für weitere künftige Entflechtungen sichtbar.
Entwicklung RESTful API & Modernisierung und Verbesserung der Codebasis:
(Name auf Anfrage) basiert auf einer stark veralteten Codebasis mit viel historisch gewachsenen Code, welcher von Programmiereinsteigern entwickelt wurde.
Meine Hauptaufgabe ist die Planung und Implementierung des Übergangs von veralteten Zugriffsschemata auf SOA-Konzepte die von (Name auf Anfrage) eingeführt werden.
Dazu entwerfe ich eine OpenAPI 3 - RESTful API-Spezifikation um volle Unterstützung für das SOA-Konzept ?Inversion of Control and Dependency? herzustellen. Basierend auf dieser Spezifikation entwerfe und implementiere ich einen RESTful Service der nach Fertigstellung dem (Name auf Anfrage) Team übergeben wird.
Weitere Aufgaben sind die Analyse, Evaluierung, Reverse Engineering, Bewertung und Dokumentation der existierenden Codebasis, sowie die Beratung des (Name auf Anfrage) Teams der Entwicklungsprozess mithilfe eines Wechsels von der Programmiersprache Perl zu Python, Golang oder ähnliches verbessert werden kann, und wie in diesem Kontext eine moderne CD/CI Pipeline implementiert und betrieben werden kann um ein schleichende Erosion der Software in Zukunft zu vermeiden.
Darüber hinaus berate ich das Team in generellen Themen rund um modernes Softwaredesign, Architektur, OOP, funktionale- and aspektorientierte Entwicklung und Stolperfallen.
Als Ergebnis wird das (Name auf Anfrage) auf einer kleineren, konsistenteren, verständlicheren, testbaren und fehlerfreieren Quellcodebasis arbeiten, was sich in einem stabileren Produktionsbetrieb niederschlägt. Internen und externen Ressourcen des Betriebsumfelds operieren an klar definierten Grenzen, und grenzüberschreitende Kommunikation wird durch einen neuen RESTful Service organisiert.
SAP Cloud Platform als eine offene Platform-as-a-Service (PaaS) bietet In-Memory Möglichkeiten, Core Plattform Services und Microservices zum Entwickeln und Erweitern intelligenter, mobile-fähiger Cloud Applikationen. Die Plattform ist für die Beschleunigung der digitalen Transformation konzipiert, indem sie schnelle Hilfe und einfache und ökonomische Entwicklung der exakten Kundenapplikation unterstützt ohne in On-Premise Infrastruktur zu investieren. Basierend auf offenen Standards bietet die SAP Cloud Platform komplette Flexibilität und Kontrolle über die Wahl der Cloudtypen, Frameworks und Applikationen.
SAP Cloud Platform Core SLES 12 HA Migration:
Analyse, Design, Entwicklung und Migration des bestehenden Betriebssystems SUSE Linux Enterprise Server 11 auf die Version 12 welches die Basis der SAP Cloud Persistence Services (SAP ASE 15.7 / 16.0) für Standalone und High-Availability Setups ist und damit einhergehend die Ablösung von Chef Cookbooks basierter Provisionierung durch die Migration auf Bash Shell Scripte.
Aufgrund des auslaufenden Supports des Betriebssystems SLES 11 musste dies auf die aktuellere Version SLES 12 migriert werden. Um einen sanften Übergang zu garantieren analysierte und validierte ich die genutzten SAP ASE Syste und ihre Komponenten auf ihre Kompatibilität mit dem neuen Betriebssystem, sowie dessen Kernel und der vorhandenen Xen Virtualisierung. Dabei löste ich Abhängigkeiten und Versionskonflikte auf.
Die existierende DevOps automatisierung durch Chef war zu komplex, fehleranfällig und imkompatibel mit künftigen Szenarien der Cloudplattform, so dass ich diese in einfache Shell Scripts migrierte. Dabei wurden auch existierende Shell Scripts angepasst oder erweitert, und volle Unterstützung für den veralteteen System Service Manager SysV init.d, sowie den neuen systemd zu gewährleisten.
Als Ergebnis erhält SAP SE künftig weiterhin vollen Support für das der SAP Cloud zugrundeliegende Betriebssystem SLES und kann selbst seinen Kunden vollen Support für seine cloudbasierte SAP ASE System auf tausenden von Persistenzservern bieten.
Darüber hinaus ist die DevOps automation und die Provisionierung neuer SAP ASE Instanzennun deutlich simpler und robuster.
Sobald alle SLES 11 basierten Virtuellen Maschinen auf SLES 12 migriert sind kann SAP den Support für das veraltete SLES 11 und dessen SysV init.d reibungsfrei einstellen.
SAP Cloud Platform Core HA & DR Datenbank-Fehlerüberwachungsentwicklung:
Architektur, Design, Implementierung und Erweiterung von Hochverfügbarkeits- (HA) und Desaster Recovery Patterns und Funktionen für Sybase ASE Datenbanken inklusive komplexer Monitoring Patterns.
Um die im Service Level Agreement definierte Generelle Verfügbarkeit für hochverfügbare und Desaster Recovery-fähige Sybase ASE Datenbank Server auf all SAP Cloud Rechenzentren und Landschaften zu erreichen entwarf und implementierte ich HADR Fehler- und Ausfallüberwachung für Sybase ASE Datenbankserver in einem vorgegebenen engen Zeitrahmen.
Als Ergebnis können SAP Cloud Platform Kunden hochverfügbare und Desaster-Recovery-fähige Sybase ASE Datenbanken erfolgreich zu einer gegebenen Frist angeboten werden und das SAP Cloud Platform Service Level Agreement erfüllt werden
(Name auf Anfrage) ist eine Landschaft bestehend aus mehreren Enterprise-Systemen, die alle Kreditmeldungen deutschland- und EU-weit entgegen nimmt und Kreditrisiken verwaltet. Diese Systeme bilden die Grundlage für das gesamte Berichtswesen der Bankenaufseher.
Verantwortlichkeiten:
Aktivitäten:
WebFOCUS Business Intelligence Architektur für (Name auf Anfrage)
Architektur, Design und Spezifikation der Integration aller (Name auf Anfrage)-Systeme in die Business Intelligence Plattform WebFOCUS.
(Name auf Anfrage)-ist eine Sammlung von mehreren Bankenaufsichtsrechtlichen Systems die künftig als Datenquelle in die 3-Party Business Intelligence Plattform WebFOCUS integriert werden sollen, um alle Arten von Auswertungen zu ermöglichen.
In meiner Rolle als Architekt entwickelte und spezifizierte ich die gesamte übergeordnete Architektur, den BPMN Prozessfluss, und die Zeitliche Planung der Integration des (Name auf Anfrage)-Systems in die BI Plattform WebFOCUS. Die Architektur und Spezifikation wird von WebFOCUS-Experten in Zusammenarbeit mit der Fachabteilung und den (Name auf Anfrage)-Softwareentwicklungsteams implementiert.
Das Ergebnis der Architektur und Spezifikation ermöglicht der Bankenaufsicht künftig (Name auf Anfrage)-Daten in ihren Auswertungen zu benutzen. Zusätzlich ist die Bankenaufsicht über die geschätzten Aufwände, sowie dem zu erwartenden Bereitstellungstermin informiert.
WebFOCUS Business Adapter für (Name auf Anfrage)
Architektur, Design, Spezifikation und Prototypimplementierung einer geschäftsnahen Abstraktionsebene für Ad-hoc-Auswertungen.
(Name auf Anfrage) ist das Nachfolgesystem für (Name auf Anfrage) und basiert auf einem technisch sehr anspruchsvollen Datenmodell. Bankenaufseher nutzen die Drittanbieterplattform WebFOCUS Business Intelligence. Aufgrund der technischen Komplexität des (Name auf Anfrage) Datenmodells war es den Bankenaufsehern bisher nicht möglich dieses für ihr Berichtswesen zu nutzen.
In meiner Rolle als Business Analyst sammelte ich alle Informationen über die Geschäftsabläufe und Berichtsanforderungen der Bankenaufsicht und spezifizierte und modellierte eine geschäftsnahe Zwischenschicht zwischen den WebFOCUS-Benutzern und dem Datenmodell. Die Implementierung dieser Schicht wurde durch Experten von WebFOCUS implementiert.
Als Ergebnis kann die Bankenaufsucht nun Daten aus (Name auf Anfrage) in ihre Berichte mit aufnehmen. Entsprechende Abstraktionsschichten werden nun analog zu der geschaffenen auch für andere noch nicht in WebFOCUS eingebundene Systeme eingeführt.
Interface Analyse
Analyse aller eingehenden, ausgehenden und internen Schnittstellen aller (Name auf Anfrage) Applikationen.
Aufrund der ähnlichen Geschäftsnatur der Deutsche Bundesbank und der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) existieren in beiden Instituten ähnliche Daten. Um der BaFin weitere ausgehende Schnittstellen bereitzustellen werden alle Schnittstellen aller ( Name auf Anfrage)-Systeme analysiert.
Das Ziel ist es der BaFin weitere Schnittstellen ohne signifikante Entwicklungsaufwände bereitstellen zu können.
Click Statistics Collector ist ein ETL System, dass Klickstatistiken zu Analystenpublikationen von verschiedenen Lieferanten zu Abrechnungszwecken sammelt, normalisiert und speichert.
Es ist eine Business-Managed Applikation, deren Entwicklung ich derzeit parallel zu meinem Hauptprojekt ?FastBase? betreibe.
Verantwortlichkeiten:
Aktivitäten:
Click Statistics Collector
Architektur, Design und Implementierung der
Click Statistics Collector Applikation.
Analysten der Commerzbank erstellen Marktforschungs- und Analysepublikationen und stellen diese für Kunden über die Kanäle verschiedener Anbieter wie Reuters, Bloomberg, Standard & Poors oder FactSet zur Verfügung. Die Aufgabe des (Name auf Anfrage) ist die sich daraus ergebenden ?Welcher Kunde klickte wann auf welche Publikation?-Informationen zu sammeln und intern vorzuhalten.
Das System setzt sich zusammen aus anbieterspezifischen Imports und zeitgesteuerten Prozessen welche die Daten sammeln, validieren, normalisieren und in eine gemeinsame Datenbank laden.
Durch die Benutzung dieses Systems ist die Commerzbank nun in der Lage Abrechnungen auf Ebene einzelner Benutzerkonten zu erstellen. Zusätzlich wird es verwendet um eine Vielzahl an Berichten zu erstellen die zum Beispiel als Basis für Neuverhandlungen von Verträgen oder für die Preisbildung von Publikationen dienen.
Zusätzlich wird mit der Inbetriebnahme des Systems eine regulatorische MiFiD2 Vorgabe erfüllt die vorgibt dass alle Klickstatistiken von internen und externen Portalen nachverfolgbar sein müssen.
FastBase ist ein System das eine Vielzahl an Diensten und Benutzeroberflächen zur Verfügung stellt um Marktanalysten, sowie internen und externen Kunden verschiedene Arten von Daten für den täglichen Gebrauch bereitzustellen. Dabei handelt es sich hauptsächlich um Instrument- und Marktdaten, Zinskurven und Prognosen,
Das System bedient mehr als 250 Kunden und Abnehmersysteme.
Verantwortlichkeiten:
Aktivitäten:
Forecast Service
Architektur, Design und Implementierung des RESTful Service ?Forecast Service? sowie des dazugehörigen Clients als flexibles Excel Addin.
Da in der Vergangenheit alle Prognosedaten über hunderte Excel Dateien verteilt waren die sich gegenseitig referenzierten, war die Änderung von Prognosedaten nicht nur mit hohen Aufwänden verbunden, sondern auch sehr fehleranfällig.
Durch den neuen Forecast Service können Benutzer nun ohne technische Kommunikation zwischen den involvierten Abteilungen Prognosedaten parallel lesen und schreiben. Alle technischen Fehler der Excel Dateien wurden eliminiert und der Prozess fehlerhafte Daten zu finden und zu korrigieren wurde maximal vereinfacht.
Zusätzlich wurde mit dem Dienst ein Team Excellence Audit-Befund behoben der vorgibt dass
Änderungen an Prognosedaten nachverfolgbar und versioniert sein müssen.
FastBase Service
Architektur, Design und Implementierung eines neuen JSF Dienstes ?(Name auf Anfrage) Service? um die Weiterentwicklung der bankinternen Client Applikation zu ermöglichen. Der bisherige Client war in Visual Basic 6 entwickelt worden, welches stark veraltet und in der Bank auch nicht mehr verfügbar ist. Dadurch lag die Weiterentwicklung lange auf Eis. Alle Funktionalitäten des bisherigen Clients wurden in einen neuen Java Server Faces Dienst adaptiert und optimiert und sind nun durch den Webbrowser verfügbar.
Der neue Dienst eliminiert eine Reihe von Fehler des veralteten Clients und stellt die Möglichkeit zum Hinzufügen und Weiterentwickeln von Kerngeschäftsfunktionen wieder her.
Der Dienst erfüllt alle Standards und Richtlinien der Bank für moderne Softwarearchitektur und trennt zusätzlich alle Benutzer durch die Schnittstelleneigenschaft des Web-Frontend vom direkten Zugriff auf die Datenbankebene.
Scheduler Re-Design und Referenzimplementierung eines Prototyps
Architektur, Design und Referenzimplementierung eines UC4-gesteuerten Scheduler-Prototyps, sowie Implementierung von beispielhaften (Name auf Anfrage) Prozessen.
Derzeit erfolgt die Steuerung aller ETL-Prozesse in (Name auf Anfrage) durch eine stark angepasste ?Activity BPMN Engine?-Applikation. Diese ist nicht nur äußerst fehleranfällig, sondern gibt generell auch nur sehr wenig Rückmeldung. Sie verstößt auch gegen die bankinterne Scheduler-Richtlinie. Darüber hinaus erfordert sie ein solch beträchtliches Maß an Wissen um ihre Eigentümlichkeiten, dass zwei Entwickler nahezu komplett an die Entwicklung und Fehlerbehebung von absoluten Basisfunktionalitäten gebunden sind.
Die Implementierung einer neuen Scheduling-Plattform auf der Basis von UC4 wird zu einer wesentlich saubereren und leichter zu verstehenden Architektur führen und somit zwei Entwicklerressourcen freisetzen.
Zusätzlich wird die Scheduler-Richtlinie eingehalten da die gemanagte UC4 Plattform verwendet wird. Das neue Design kann leicht von der ?SPManager?-Referenzimplementierung für weitere Prozesse adaptiert werden.
SPManager
Architektur, Design und Implementierung einer Applikation zur Verwaltung von Stored SQL Procedures. (Name auf Anfrage) beinhaltet mehr als 2500 Stored Procedures welche direkt durch die Fachabteilung auf dem produktiven System geändert werden.
Bisher war es aufgrund von Zugriffsbeschränkungen und mangelnder Kommunikation sehr schwierig die produktiven Stored Procedures synchron zu denen in der Entwicklungsumgebung zu halten. Das führte bei Liefereinsätzen in der Produktionsumgebung oft zu Fehlern wenn solche geänderten Stored Procedures durch neue Softwarepakete adressiert wurden. Darüber hinaus gab es keine Revisionskontrolle oder Änderungsverfolgung der Stored Procedures.
Der SPManager findet auf täglicher Basis neue und geänderte Stored Procedures in der Produktionsumgebung und meldet diese samt Quellcode an die Entwicklungsabteilung zur Einpflege in die Revisionskontrolle. Dadurch sind alle Stored Procedures in TFS versioniert, was zu wesentlich unaufgeregteren Liefereinsätzen führt. Zusätzlich werden auf wöchentlicher Basis Nutzungsstatistiken gemeldet um unbenutzte Stored Procedures aufzuspüren.
Der SPManager ist die Prototyp- und Referenzimplementierung der neuen UC4-basierten Scheduling-Plattform.
Generelle Aktivitäten:
silver9 ist ein Unternehmen und eine Plattform zum Handeln und Verwalten von elektronischen Waren. Zur Plattform gehört auch ein Onlineshop.
Verantwortlichkeiten:
Aktivitäten:
Photon
Architektur, Design und Implementierung der Mehrbenutzerapplikation ?Photon?.
Photon ermöglicht es Händlern international mit Waren zu handeln.
Es verfügt über verschiedene Module wie Kunden- und Geschäftspartnerverwaltung,- internationaler Versand, internationale Steuer- und Gebührenverwaltung und mehr.
Die Applikation erlaubt die Handhabung eines kompletten Geschäftslebenszyklus von Angebot, Auftrag, Ausführung über Rechnungsstellung und mehr.
(Name auf Anfrage) beinhaltet automatisierte Schnittstellen-ETL-Prozesse um Lagerbestände und Preise von Waren von verschiedenen Geschäftspartnerunternehmen zu beziehen um daraus Verkaufspreise und Warenbestände zu ermitteln. Es verfügt zudem über ein Modul zur Verwaltung der Inhalte auf den Webseiten des Onlineshops und eine Modul zur Verwaltung von Dokumenten. Darüber hinaus beinhaltet (Name auf Anfrage) ein Modul um Waren über einen Onlineshop zu verkaufen.
Das (Name auf Anfrage)-System sowie der Onlineshop nutzen beide Responsive Design um den Zugriff gleichermaßen über mobile Endgeräte und Desktopgeräte mit einer einzigen Implementierung zu gewährleisten.
Beschreibung
Das Projekt hatte keinen konkreten Namen. Es war ein übergreifendes Projekt und umfasste mehrere Handelsabteilungen und beinhaltete verschiedene Applikationen um Synergieeffekte zu erzeugen.
Die hauptsächlichen Interessensgruppen waren:
Ich begleitete das Projekt in verschiedenen Rollen:
Verantwortlichkeiten:
Abteilung:
Das Projekt umfasste 3 bis 8 Entwickler. Inklusive Fachabteilunskoordinatoren, Management, Administration und Referenzkunden umfasste das Projekt bis zu 30 Personen. Die Handelsabteilungen, das Management und die Entwickler waren über Frankfurt, London, New York und Indien verteilt.
Aktivitäten
Austausch der Handelsplattform der ETF Borrowing & Lending-Abteilung
Beratung, Leitung und mehrphasiges Architekturdesign über den Austausch der kompletten Handelsplattform der New York ETF Borrowing & Lending-Abteilung von Pirate und FlexTrade hin zu Bloomberg SSEOMS, BasketTrader, CGI und MUREX.
Die übergeordneten Ziele waren die komplette Handelsplattform auszutauschen um Lizenzkosten durch die Benutzung von Bloomberg SSEOMS zu sparen, einen transparenteren Fluss von Handelsdaten durch die Nutzung des hauseigenen FIX Message Backbones zu erreichen und die Commerzbank Richtlinie zu erfüllen die vorgibt, dass alle Positionen der Bank in MUREX gehalten werden müssen. Des Weiteren wurde erwartet dass die neue Plattform eine höhere Gesamtgeschwindigkeit aufweisen wird.
Da das Projekt das Sparen von mehreren Millionen Euros garantierte, wurde es als ein COIN Projekt akzeptiert.
In meiner Rolle als Business Analyst arbeitete ich eng mit der Fachabteilung zusammen um optimale Lösungen für konkrete Probleme zu finden und alle potentiellen Probleme und Schwachstellen aufzuzeigen.
In meiner Rolle als Softwareinfrastrukturarchitekt erarbeitete ich optimale Datenflüsse um sicherzustellen, dass alle existierenden Schnittstellen und regulatorischen Berichte weiterhin versorgt werden. Ich beriet die Fachabteilung welche Teile der Plattform durch welche Alternativen ausgetauscht werden können und welche zwingende Erweiterungen benötigen. Ich erstellte Aufwandsschätzungen für verschiedene Architekturvorschläge und mehrphasige Migrationen.
In meiner Rolle als Chef-Entwickler erweiterte oder entwarf ich Applikationen und Prototypen die existierende Teile von Pirate und FlexTrade ersetzten. Ebenso spezifizierte ich die Anforderungen für einen neuen Dienst ?MUREX Position Service? welcher auf Anfrage aktuelle Positionen aus MUREX bereitstellte. Dieser Dienst wurde von der MUREX-Abteilung implementiert und in Betrieb genommen und später auch von verschiedenen anderen Abteilungen genutzt. Zusätzlich plante, verteilte und verfolgte ich alle Aktivitäten der Entwickler und berat diese bei komplexen Problemen.
In meiner Rolle als Onsite Koordinator koordinierte ich alle Kommunikation, Wissenstransfers und Aktivitäten unserer Entwicklerkollegen in Indien.
Seit der Inbetriebnahme der neuen Handelsplattform wurden durch das bessere Lizenzmodell von Bloomberg SSEOSM eine Menge an Kosten eingespart. Als weiteres Ergebnis sind nun alle Positionen in MUREX in Echtzeit vorhanden und damit die Richtlinie erfüllt dass alle Positionen in MUREX verfügbar sein müssen. Auch war es der Bank nun möglich eine Übersicht über alle bankweiten Positionen in einem System zu haben, was täglich vom Management und Direktorium zur Entscheidungsfindung genutzt wird.
Die neuen Handelsdatenflüsse durch den bankeigenen FIX Message Backbone befolgten alle Standards und Regeln was einerseits zu einem leichter verständlichen Routing und andererseits zu einer wesentlich transparenteren Nachverfolgung von Handelsaufträgen führte. Administratoren konnten nun durch die Benutzung von Standard-Tools einen besseren Support für problematische Aufträge bieten.
Durch die Nutzung von neu entwickelter oder existierender Hochgeschwindigkeitsapplikationen konnte die Gesamtgeschwindigkeit stark gesteigert werden. Täglich wiederkehrende Prozesse wie zum Beispiel das Rebalancing des Hauptkontos konnten so stark optimiert werden dass sie nun nur Minuten anstelle von Stunden benötigen.
Mit dem Einführen von Expertensystemen (Rule Engines) im Handelsdatenfluss konnten das Management, die Händler, Administratoren und Entwickler eine Menge an Zeit sparen da die Kommunikation zwischen den Personen nun auf einer standardisierten Regelsprache basiert.
BasketTrader
Architektur, Design und Weiterentwicklung der existierenden Applikation ?BasketTrader? zum Etablieren einer abteilungsübergreifenden Lösung für Investment-Banking und Handel. BasketTrader ist eine Frontendapplikation zur Eingabe und Überwachung von Handelsaufträgen in Echtzeit.
Die Applikation bezieht in Echtzeit Preise von verschiedenen Anbietern und zeigt diese dem Benutzer zur Finden einer Handelsentscheidung an. Des Weiteren können Handelsaufträge mit den Marktpreisen generiert werden. Für den Bezug dieser Preisdaten wurden verschiedene steckbare Module (Plug-Ins) für die Preislieferanten Bloomberg und Reuters realisiert
Es wurde auch ein Modul hinzugefügt dass die Benutzerkonfiguration aus einer Datenbank lädt.
BasketTrader wurde für die New Yorker ETF Borrowing & Lending-Handelsabteilung dahingehend erweitert, dass auch ETFs, Swaps, Cash-Amounts und andere Typen von Instrumenten gehandelt und verwaltet werden konnten. Um geliehene und verliehene Positionen der Handelsabteilung in Balance zu halten wurde ein präziser Algorithmus implementiert der das Rebalancing eines Kontos mit mehreren Unterkonten und einer Vielzahl von Instrumententypen im Wert von mehr als 4 Milliarden US Dollar auf Abruf vornahm.
Als Ergebnis dieses Algorithmus wurde dem Rebalancing-Händler ein fertig zu handelndes Portfolio mit Kauf- und Verkaufsaufträgen angeboten um das Konto täglich ein- oder mehrmals in Balance zu bringen. Um die Balance des Kontos zu ermitteln wurden alle Positionen der Abteilung von dem bankinternen WebService MUREX Position Service abgerufen.
Ebenso wurden alle Geschäftsprozesse wie das Erzeugen oder die Rückgabe von ETFs, außerbörslicher Handel oder der Kontotransfer von Positionen implementiert
BasketTrader wurde von bis zu 3 Entwicklern parallel entwickelt und von bis zu 30 Händlern genutzt. Weitere Informationen über den BasketTrader und seine Geschichte sind in diesem Dokument in der Zeitspanne von 09.2008 bis 03.2011 verfügbar.
CGI
Architektur, Design und Implementierung des Kerns und Prototyps des regelbasierten Expertensystems (Rules Engine) ?CGI? als handelsabteilungsübergreifende Lösung zum Buchen von ausgeführten Handelsaufträgen in MUREX für die Verwaltung von Positionen und spätere Rechnungsstellung. CGI ist eine ETL-Prozessapplikation für Handelsnachrichten. Es extrahiert und transformiert eingehende FIX Protocol-Nachrichten über Handelsausführungen in MUREX-spezifische Stored SQL Procedure Aufrufe und führt diese aus.
Bisher nutzte die Cash Equities Handelsabteilung die hauseigene Applikation ?SSEOMS-MF?. Diese war sehr intransparent und verkompliziert entwickelt worden und hatte einige ernsthafte Geschwindigkeitsprobleme bei Buchungen von hochvolumigen Transaktionen in MUREX.
Hinzu kam eine Anforderung für die New York ETF Borrowing & Lending Handelsabteilung alle Transaktionen ebenfalls in MUREX zu buchen, da die Applikation Pirate durch ihre interne Positionsverwaltung gegen eine bankinterne Richtlinie verstieß.
Eine weiterte Anforderung der Administration und des Supports war es die Regeln, zu Beispiel Mappings, die während der Transformation zur Anwendung kamen im laufenden Betrieb ändern zu können ohne auf einen neuen Liefereinsatz angewiesen sein zu müssen.
CGI wurde als hochflexible, multi-threaded und Regelsätze-basierte Pipeline entworfen mit multiplen und steckbaren Handlern für maßgeschneiderte Nachrichtenverarbeitung in jeder der Input-, Transformations-, und Output-Stufen.
Der Kern wurde um das Business-Rules-Managementsystem Drools konzipiert. CGI konnte mit generellen Transformationsregeln gefüttert werden welche allen Handelsabteilungen gemein waren. Diese konnten für jede Abteilung mit spezifischen Regelsätzen überschrieben oder mit Neuen erweitert werden. Auf diese Weise konnten verschiedene Nachrichten von multiplen Abteilungen mit gemeinsamen und spezifischen Regelsätzen in einer einzigen Instanz verarbeitet werden. Die Regeln wurden in einer Java-basierten domänenspezifischen Sprache (DSL) verfasst.
Die Applikation wurde an die New Yorker ETF Borrowing & Lending Handelsabteilung ausgeliefert während die Handelsplattform Pirate ausgetauscht wurde. Zur Anwendung kamen allgemeine Nachrichtenhandler, sowie allgemeine und abteilungsspezifische Regeln.
Später wurde CGI an die Cash Equities Handelsabteilung mit allgemeinem und abteilungsspezifischen Regelsätzen und einigen spezifischen Nachrichtenhandlern ausgeliefert.
Die Diskussionen um CGI auch an die Flow Trading Handelsabteilung auszuliefern dauern aktuell noch an. Aktuell gibt es auch eine Diskussion ob CGI für den Londoner Index Arbitrage-Handel eingesetzt werden kann.
Des Weiteren wird diskutiert ob CGI künftig als System für das Routing von Handelsaufträgen fungieren kann, da die Natur des Systems dies zulässt. Somit kann der existierende ESA-Router ersetzt werden und eine gemeinsame Codebasis und DSL geschaffen werden wodurch Kosten eingespart werden können.
Durch die Verwendung von CGI als geschäftsregelbasierte Transformations-Engine zum Generieren von MUREX Positionen aus FIX Protocol-Nachrichten heraus erhielt die Bank eine abteilungsübergreifende Lösung, die auf alle Eigenheiten der jeweiligen Abteilung eingehen kann, Die Lösung kann auch für komplett andere, ebenfalls in der regelbasierten Domäne angesiedelten Probleme, wie zum Beispiel Routing wiederverwendet werden.
Im Ergebnis konnte die ETF Borrowing & Lending Handelsabteilung durch den Einsatz vn CGI erfolgreich von Pirate weg migriert werden und die bankinterne Richtlinie zum Halten von Positionen in MUREX implementieren.
Die Cash Equities Abteilung konnte erfolgreich von der undurchsichtigen SSEOMS-MF Schnittstellenapplikation weg migriert werden. Administratoren und Supporter konnten nun Regeln im laufen Betrieb in einer einfachen Sprache anpassen. Zusätzlich wurden alle Geschwindigkeitsprobleme gelöst. Eine Messung ergab dass eine Stunde Verarbeitung in SSEOMS-MF auf eine Minute Verarbeitung in CGI beschleunigt werden konnte. Hochvolumige Transaktionen sind nun nahezu in Echtzeit in MUREX verfügbar.
Neben den technischen Vorteilen profitierten beide Handelsabteilungen von der strikten Trennung der Geschäftsregeln von der technischen Implementierung. Die Kommunikation der Entwickler, Administratoren, Supporter, Händler und des Management konnte stark verbessert werden, da alle Regeln in einer gemeinsam verständlichen Sprache formuliert waren. Dadurch wurden das Hinzufügen oder Ändern von Regeln, sowie das Finden von Problemen für alle involvierten Personen wesentlich einfacher.
CGI wurde von bis zu 2 Entwicklern parallel entwickelt. Meine Aufgabe war es eine Lösung für die ursprünglichen Probleme und Anforderungen zu erarbeiten, den Kern und Prototyp zu implementieren, der allgemeine und abteilungsspezifische Regelsätze verarbeiten kann.
Sobald CGI ein startklares System war, dass die Erfüllung aller funktionalen Anforderungen beweisen konnte, übergab ich die weitere Evolution an einen Mitarbeiter der die konkreten Geschäftsregeln und spezifischen Nachrichtenhandler in Zusammenarbeit mit den Fachabteilungen und Händlern implementierte.
Ich entwickelte CGI parallel zum BasketTrader und konzentrierte mich wieder auf die Entwicklung des BasketTrader nachdem die Entwicklung von CGI von meiner Seite soweit fortgeschritten war dass ich es übergeben konnte.
Weitere Aktivitäten
FastBase ist ein System das eine Vielzahl an Diensten und Benutzeroberflächen zur Verfügung stellt um Marktanalysten, sowie internen und externen Kunden verschiedene Arten von Daten für den täglichen Gebrauch bereitzustellen. Dabei handelt es sich hauptsächlich um Instrument- und Marktdaten, Zinskurven und Prognosen,
Das System bedient mehr als 250 Kunden und Abnehmersysteme.
Verantwortlichkeiten:
Aktivitäten:
Reverse Engineering, Migration, DownloadService
Reverse-Engineering des gesamten
FastBase Systems in Zusammenarbeit mit der Fachabteilung und einem Software Architekten nachdem alle FastBase Entwickler im Zuge der Übernahme der Dresdner Bank diese über Nacht verließen.
Migration und Integration des gesamten Systems aus der alten Welt der Dresdner Bank in die neue Welt der Commerzbank.
Architektur, Design, Implementierung und Integration eines neuen DownloadService für die
FastBase ETL-Prozesse mit Unterstützung für HTTP, HTTPS, FTP, SFTP, LOCAL und SMB Protokolle und optionaler Proxy Authentifizierung.
Ich wechselte als Interim-Entwickler und Reverse-Ingenieur in das
FastBase Projekt als sich dieses in einer kritischen Phase befand um dem Projekt zu helfen am Leben zu bleiben bis ein neuer langfristiger Entwickler gefunden wurde.
Nach dem Reverse-Engineering des Kerns wurden alle Ergebnisse und Diagramme der Fachabteilung und dem neuen Entwickler übergeben.
Als Ergebnis der Migration überlebte das
FastBase System in der neuen Welt der Commerzbank und existiert dort auch heute noch.
Die Benutzung des neuen DownloadService erlaubt es der Fachabteilung und den Entwicklern neue Download-Prozesse als Teil von ETL-Prozessen durch einfache Konfiguration aufzusetzen.
Die gemeinsame Codebasis spart Kosten indem Codeduplikate vermieden werden und reduziert das Risiko neue Fehler zu implementieren.
Das Projekt hatte keinen konkreten Namen. Es war ein übergreifendes Projekt und umfasste mehrere Handelsabteilungen und beinhaltete verschiedene Applikationen um Synergieeffekte zu erzeugen.
Die hauptsächlichen Interessensgruppen waren:
Verantwortlichkeiten:
Abteilung:
Das Projekt umfasste bis zu 3 Entwickler.
BasketTrader
Architektur, Design und Implementierung einer abteilungsübergreifenden Lösung für Investment-Banking und Handel. BasketTrader ist eine Frontendapplikation zur Eingabe und Überwachung von Handelsaufträgen in Echtzeit.
BasketTrader is eine FIX Protocol-konforme, modulare, hochperformante Java Swing GUI, die von Händlern für hochvolumige Transaktionen von Einzelinstrumenten oder Instrumentenlisten mit einer niedrigen Latenz eingesetzt wird.
Er unterstützt alle Arten von Instrumenten aus multiplen Instrumentenuniversen. Das Instrumentenuniversum ist als modulare Implementierung realisiert (Plug-In). Dadurch können abteilungsspezifische Instrumentendatenbank, Instrumente von anderen Anbietern oder andere bankinterne Instrumentenuniversen kaskadiert genutzt werden. Die Applikation verwaltet und visualisiert komplette Lebenszyklen wie Eingabe, Ausführung und Überwachung von Handelsaktivitäten.
Während einer Handelsaktivität wird eine Reihe von Informationen angezeigt wie zum Beispiel der Zustand des Geschäfts und entsprechende Fehler, der Fortschritt des Geschäfts, die Anzahl der ausgeführten Einheiten, durchschnittliche Ausführungspreise und mehr.
Für jedes Instrument in einem Warenkorb sind Echtzeitpreise (BID und ASK) sichtbar. Die Preislieferung ist eine Implementierung eines Reuters RFA Clients. Sie unterstützt verschiedene Markttiefen die optional auch angezeigt werden können.
BasketTrader bietet ein frei konfigurierbares Modul um Handelsnachrichten mit spezifischen Informationen anzureichern, die von Händlern im Frontend eingegeben werden können oder fix sind.
Die Flow Trading Abteilung nutzt dieses Modul um den Händlern die Eingabeparameter einer algorithmischen Handels-Engine zu offerieren. Dadurch können die Händler die Handels-Engine instruieren wie ein Handel getätigt werden soll. Beispiele sind das defensive Handeln entsprechend des volumen- oder zeitgewichteten Durchschnittspreises (VWAP / TWAP).
Die Cash Equities Abteilung nutzt dieses Modul um den Nachrichtenrouter ESA Router zu instruieren wohin ein Handelsauftrag geleitet werden soll.
BasketTrader wurde von bis zu 3 Entwicklern parallel entwickelt und von bis zu 15 Händlern im Flow Trading und 2 Händlern in Cash Equities genutzt. Aufgrund seiner Möglichkeiten FIX Protocol-Nachrichtenkommunikationen sehr tief inspizieren zu können wird es auch von einer unbekannten Anzahl an Entwicklern in der Bank als Diagnosetool genutzt.
Weitere Aktivitäten
Object+ ist ein in Amsterdam ansässiges Softwarehaus dass die Applikation
Universal Fix Gateway entwickelt und vertreibt.
Universal Fix Gateway ist ein komponentenbasiertes FIX Protocol Nachrichtenverarbeitungssystem dass FIX Nachrichten enkodieren, dekodieren, routen und auf verschiedene Arten verarbeiten kann.
Das Ziel war es einen
Universal Fix Gateway für die Fortis Bank zu entwickeln um Aktienangebote (Quotes) von der schwedischen OMX Börse zu empfangen und in einer Datenbank zu speichern.
Verantwortlichkeiten:
Universal Fix Gateway
Design und Implementierung eines Fix Message Translator und eines Fix Quotation Datenbankmoduls für den Universal Fix Gateway, sowie Inbetriebnahme der Lösung in der Umgebung des Kunden.
Als Ergebnis der Installation des kundenspezifischen Universal Fix Gateway konnte die Fortis Bank neue Prozesse für OMX-Handelsgeschäfte in ihrer Clearance- und Settlement Abteilung aufsetzen,
(Name auf Anfrage) ist ein System, dass alle Handelsgeschäfte der Commerzbank auf Legalität und Marktkonformität prüft.
Verantwortlichkeiten:
Aktivitäten:
UC4 Migration
Design, Implementierung und Migration aller existierenden Crontab- und manuellen Prozesse auf die UC4 Scheduling-Plattform.
Bisher wurden alle Prozesse entweder manuell oder durch Crontab gestartet. Crontab verletzte die Scheduling-Richtlinie.
Als Lösung wurden alle Prozesse auf die UC4 Scheduling-Plattform migriert und im Ergebnis die Aufwände der Administration durch automatisierte anstelle von manuellen Prozessen
minimiert. Zusätzlich wurde die Scheduling-Richtlinie durch den Wegfall von Crontab implementiert
MDDS ist das zentrale System in der Bank um statische und Marktdaten von verschiedenen Lieferanden zu sammeln und intern anzubieten.
Die Daten werden normalisiert und in einer SQL Datenbank, sowie einem Flatfile-System gespeichert. MDDS verteilt die Daten an mehr als 200 Kunden und Abnehmersysteme. Kern des MDDS Systems ist eine riesige Erweiterung des Assetmanagementsystems Asset Control.
Verantwortlichkeiten:
Aktivitäten
MDDS
Design und Implementierung verschiedener Modules und ETL-Prozesse für MDDS unter Beachtung der gegebenen Architektur.
Periodische Migrationen von MDDS auf neue Versionen des Kernsystems Asset Control.
MDDS ist das zentrale System in der Bank um statische und Marktdaten von verschiedenen Lieferanden zu sammeln und intern anzubieten.
Das Einsammeln der Data ist in mehr als 350 ETL-Prozessen implementiert, die alle innerhalb eines komplexen Scheduling-Plans getriggert werden.
Das Ziel des Projektes war die Migration des kompletten Scheduling-Plans von der vorherigen Scheduling-Plattform Autosys auf die neue UC4 Plattform.
MDDS wurde als erstes Pilotprojekt ausgewählt um die Migration auf UC4 durchzuführen und UC4 als eine stabile Plattform zu evaluieren.
UC4 was war im Begriff die neue bankweite Standardplattform für das Scheduling zu werden.
Verantwortlichkeiten:
Aktivitäten:
UC4 Migration
Design, Implementierung, Migration und Inbetriebnahme aller Prozesse auf die neue UC4 Plattform und Entwicklung einer API für die programmatische Kontrolle von UC4 aus MDDS Prozessen heraus.
Im Ergebnis der Pilotmigration erwies sich UC4 als robuste und stabile, flexible und komfortable Scheduling-Plattform. Später wurde UC4 der neue Standard in der Bank und andere Abteilungen nutzten die entwickelte API um UC4 von ihren Applikationen heraus zu steuern.
Für MDDS war die Migration ein voller Erfolg, da die Flexibilität und Visualisierungsmöglichkeiten jene von Autosys bei weitem übertrafen.
Freiberufliche Tätigkeit als Webentwickler
Verantwortlichkeiten:
Aktivitäten
Website Development
Design und Entwicklung verschiedener Webseiten für verschiedene Kunden.
Consultec AG war ein Unternehmen dass die Applikation Infotainment entwickelte und verkaufte.
Infotainment, als verteiltes Multimedia-, Präsentations- und Content-Managementsystem, konnte multiple zeitgesteuerte Werbespots verschiedener Formate auf einem einzigen Bildschirm anzeigen. Es war zusammen mit einer Content-Managementapplikation paketiert.
Das Ziel war ein Reverse-Engineering der Infotainment Software und das Training künftiger Entwickler und Content-Schöpfer.
Verantwortlichkeiten:
Aktivitäten:
Infotainment
Reverse-Engineering der Infotainment Software, Erweiterung kleinerer Features und Behebung von Fehlern.
Entwicklung einer Webapplikation für ein Partnerunternehmen die Händlerprovisionen anzeigt.
Rolle: Chef-Entwickler, Architekt, Business Analyst, Netzwerkadministrator
Beschreibung:
FBP Business Consulting GmbH und Südwest AG waren eng verbundene Unternehmen in der Geschäftsberatungsindustrie. Sie boten eine Reihe von industriespezifischen Diensten für Kunden an.
Verantwortlichkeiten:
Aktivitäten:
Generelle Aktivitäten
Entwicklung von Schnittstellen und ETL-Prozessen für verschiedene Datenlieferanten und Kundensysteme.
Entwicklung von kundenspezifischen Softwarelösungen.
Administration eines Netzwerkes mit bis zu 150 PCs und Servern.
cashEngine eine Plattform fü den algorithmischen Handel von Cryptowährungen auf verschiedenen Börsen.
Verantwortlichkeiten:
Aktivitäten
cashEngine
Architektur, Design und Implementierung einer Microservices Plattform für automatisierten, Hochfrequenz- und Niedriglatenzhandel von Cryptowährungen mit eigenen Handelsstrategien.
Die Implementierung der Plattform folgt komplett modernen Modellen und Mustern wie zum Beispiel: Microservices Architektur, asynchrone und reactive Programmierung, ereignisgetriebene Nachrichtenverarbeitung, verteiltes und zustandsloses Design und NO-SQL Datenhaltung um ein Maximum an horizontaler Skalierbarkeit zu gewährleisten.
Die Core-Komponenten wurden in Rust neu implementiert.
Das Reisendeninformationssystem ist eine Cloud basierte Streaming-Plattform die Nachrichten aus verschiedenen Quellen empfängt, filtert, transformiert und an verschiedene Ziele veröffentlicht, mit dem Ziel Reisende und Personal mit Echtzeitinformationen über Reisen und Fahrzeuge zu versorgen.
Verantwortlichkeiten:
Aktivitäten
Analyse, Design, Implementierung, Pflege und Migration von Microservices. Das Reisendeninformationssystem ist eine Plattform, die aus hunderten von Microservices besteht und Echtzeitinformationen zu Reisen wie zum Beispiel Fahrten, Zwischenhalte, Gleise und Plattformen, Bahnhöfe und Stationen, hörbare Ansagen, Vehikel-Konfigurationen und -Features, Zugteile, Ankunft- und Abfahrtzeiten und vieles mehr zur Verfügung zu stellen.
Die Informationen kommen aus offiziellen Fahrplänen, physischen Sensoren, Prognoseautomaten, Benutzereingaben und anderen Quellen. Sie gehen an Reisende, Personal, Bahnhöfe und Busstationen, Fahrzeuge, Google und andere Ziele. Zuletzt werden sie auf Displays und Anzeigern in Stationen, an Gleisen und in Fahrzeugen selbst, auf Geräten des Personals, in Apps (DB Navigator) und Google angezeigt, sowie als Ansage an Bahnhöfen, Stationen und Gleisen durchgegeben und im DB Vertrieb weiterverarbeitet.
Mein Team ist für die Ausgangskanäle an verschiedene Abnehmer verantwortlich, welche diese Informationen hauptsächlich auf physikalische Ansager und Anzeiger an Bahnhöfen, Stationen, Gleise und in Vehikel bringen.
Technisch werden rund 30 Microservices betrieben, die Events aus Kafka Topics und RabbitMQ Queues in einem Kubernetes Cluster filtern, aggregieren, transformieren und verarbeiten und an verschiedene Abnehmer via RabbitMQ oder Kafka veröffentlichen. Jeder Microservice wird in mehreren partitionierten Instanzen betrieben, um einen hohen Durchsatz bei geringer Latenz zu gewährleisten.
In dieser Umgebung analysiere ich Geschäftsanforderungen, entwerfe und implementiere neue Services und Datenflüsse, erweitere und optimiere bestehende Services, und setzte Feature Requests um. Teil des Projektes beinhaltet eine Migration der kompletten Plattform in eine andere Cloud.
Die Kommunikation und Koordinierung aller beteiligten Teams und deren Mitglieder ist in einem sehr strikten Scrum und Scaled Scrum Prozess eingebettet.
(Name auf Anfrage) ist ein System das Kreditdaten von Institutionen, Unternehmen und natürlichen Personen sammelt und diese verschiedenen Institutionen wie die Europäische Zentralbank bereitstellt.
Verantwortlichkeiten:
Aktivitäten
Analyse, Design, and Implementierung von Optimierungen.
(Name auf Anfrage) sammelt massive Bestände von Kreditdatenmeldungen aus ganz Deutschland. Die Daten durchlaufen verschiedene Workflows wie Validierung, Aggregation und regelbasierte Engines. Einige dieser Workflows sind sehr kritisch und haben eine inakzeptable Laufzeit und sind somit das Ziel ständiger Optimierungen.
In meiner Rolle als Performance Optimierter analysierte ich einen dieser kritischen Workflows nach Optimierungsmöglichkeiten, um die Laufzeit signifikant zu senken. Des Weiteren basierte das System noch auf schwergewichtigen EJB Beans, welche ich zu CDI Beans migrierte.
Als Ergebnis wurde die Laufzeit des Workflows von rund 8 Stunden auf rund 4 Stunden optimiert, welche die Anforderungen der Fachabteilung erfüllte. Weitere Optimierungsansätze und Tests zeigten, dass durch Architekturänderungen und weitere Entwicklungsaufwände die Laufzeit sogar auf bis zu 15-30 Minuten gesenkt werden kann. Neben den Optimierungen und der CDI Migration half ich dem Team während der Release-Phase einige Blocker-Bugs zu beheben und migrierte den Test-Container von OpenEJB zu TomEE.
1&1 Telecommunication SE ist ein Provider für alle Arten von Telekommunikationsdiensten.
IONOS SE ist ein mit 1&1 eng verbundenes Unternehmen, dass Rechenzentrumdienste wie Webhosting, Domains, E-Mail-Hosting, Server und Private Cloud Lösungen anbietet.
(Name auf Anfrage) ist eine Abteilung in IONOS SE, welche verantwortlich das Produkt Dedicated Server betreibt.
Verantwortlichkeiten:
Aktivitäten:
(Name auf Anfrage) Carveout:
Analyse, Design, Orchestrierung and Implementierung einer Infrastrukturänderung welche durch die rechtliche Separation der beiden Unternehmen IONOS and 1&1 getrieben ist.
IONOS war ehemals ein Bereich innerhalb 1&1 welcher in ein eigenständiges Unternehmen ausgegliedert wurde. Aufgrund der gemeinsamen Historie sind beide Unternehmen noch sehr eng miteinander verflochten und nutzen daher noch gemeinsame Ressourcen wie die Master Database. Das Projekt (Name auf Anfrage) Carveout adressiert diesen Missstand. Die Master Datenbank ist eines der zentralen Ziele der Entflechtung mit dem Ziel 1&1 Geschäftsdaten strikt von IONOS rein technischen Daten zu trennen.
(Name auf Anfrage) Carveout führt darüber hinaus eine generelle Service Orientierte Architektur (SOA) ein, basierend auf RESTful Interfaces, um das Problem zu lösen, dass die Master Datenbank nicht mehr als Schnittstelle für technische Kommunikation zwischen verschiedenen Abteilungen zweckentfremdet, sondern als reiner Datenspeicher genutzt wird.
Meine Aufgabe besteht darin die konkreten Bedingungen, Anforderungen und Konsequenzen zu analysieren, um einen Fahrplan für die Implementierung der (Name auf Anfrage) Carveout-Änderungen für das (Name auf Anfrage) Team zu erstellen, und diese dann auch umzusetzen.
Dabei soll durch enge Zusammenarbeit mit Teams die abhängig von (Name auf Anfrage) -Diensten sind oder von denen (Name auf Anfrage) abhängig ist ein möglichst reibungsfreier Übergang garantiert werden.
Als Ergebnis wird 1&1 und IONOS SE auf voneinander unabhängigen Masterdaten operieren und versteckte Abhängigkeiten zwischen verschiedenen Diensten und Abteilungen für weitere künftige Entflechtungen sichtbar.
Entwicklung RESTful API & Modernisierung und Verbesserung der Codebasis:
(Name auf Anfrage) basiert auf einer stark veralteten Codebasis mit viel historisch gewachsenen Code, welcher von Programmiereinsteigern entwickelt wurde.
Meine Hauptaufgabe ist die Planung und Implementierung des Übergangs von veralteten Zugriffsschemata auf SOA-Konzepte die von (Name auf Anfrage) eingeführt werden.
Dazu entwerfe ich eine OpenAPI 3 - RESTful API-Spezifikation um volle Unterstützung für das SOA-Konzept ?Inversion of Control and Dependency? herzustellen. Basierend auf dieser Spezifikation entwerfe und implementiere ich einen RESTful Service der nach Fertigstellung dem (Name auf Anfrage) Team übergeben wird.
Weitere Aufgaben sind die Analyse, Evaluierung, Reverse Engineering, Bewertung und Dokumentation der existierenden Codebasis, sowie die Beratung des (Name auf Anfrage) Teams der Entwicklungsprozess mithilfe eines Wechsels von der Programmiersprache Perl zu Python, Golang oder ähnliches verbessert werden kann, und wie in diesem Kontext eine moderne CD/CI Pipeline implementiert und betrieben werden kann um ein schleichende Erosion der Software in Zukunft zu vermeiden.
Darüber hinaus berate ich das Team in generellen Themen rund um modernes Softwaredesign, Architektur, OOP, funktionale- and aspektorientierte Entwicklung und Stolperfallen.
Als Ergebnis wird das (Name auf Anfrage) auf einer kleineren, konsistenteren, verständlicheren, testbaren und fehlerfreieren Quellcodebasis arbeiten, was sich in einem stabileren Produktionsbetrieb niederschlägt. Internen und externen Ressourcen des Betriebsumfelds operieren an klar definierten Grenzen, und grenzüberschreitende Kommunikation wird durch einen neuen RESTful Service organisiert.
SAP Cloud Platform als eine offene Platform-as-a-Service (PaaS) bietet In-Memory Möglichkeiten, Core Plattform Services und Microservices zum Entwickeln und Erweitern intelligenter, mobile-fähiger Cloud Applikationen. Die Plattform ist für die Beschleunigung der digitalen Transformation konzipiert, indem sie schnelle Hilfe und einfache und ökonomische Entwicklung der exakten Kundenapplikation unterstützt ohne in On-Premise Infrastruktur zu investieren. Basierend auf offenen Standards bietet die SAP Cloud Platform komplette Flexibilität und Kontrolle über die Wahl der Cloudtypen, Frameworks und Applikationen.
SAP Cloud Platform Core SLES 12 HA Migration:
Analyse, Design, Entwicklung und Migration des bestehenden Betriebssystems SUSE Linux Enterprise Server 11 auf die Version 12 welches die Basis der SAP Cloud Persistence Services (SAP ASE 15.7 / 16.0) für Standalone und High-Availability Setups ist und damit einhergehend die Ablösung von Chef Cookbooks basierter Provisionierung durch die Migration auf Bash Shell Scripte.
Aufgrund des auslaufenden Supports des Betriebssystems SLES 11 musste dies auf die aktuellere Version SLES 12 migriert werden. Um einen sanften Übergang zu garantieren analysierte und validierte ich die genutzten SAP ASE Syste und ihre Komponenten auf ihre Kompatibilität mit dem neuen Betriebssystem, sowie dessen Kernel und der vorhandenen Xen Virtualisierung. Dabei löste ich Abhängigkeiten und Versionskonflikte auf.
Die existierende DevOps automatisierung durch Chef war zu komplex, fehleranfällig und imkompatibel mit künftigen Szenarien der Cloudplattform, so dass ich diese in einfache Shell Scripts migrierte. Dabei wurden auch existierende Shell Scripts angepasst oder erweitert, und volle Unterstützung für den veralteteen System Service Manager SysV init.d, sowie den neuen systemd zu gewährleisten.
Als Ergebnis erhält SAP SE künftig weiterhin vollen Support für das der SAP Cloud zugrundeliegende Betriebssystem SLES und kann selbst seinen Kunden vollen Support für seine cloudbasierte SAP ASE System auf tausenden von Persistenzservern bieten.
Darüber hinaus ist die DevOps automation und die Provisionierung neuer SAP ASE Instanzennun deutlich simpler und robuster.
Sobald alle SLES 11 basierten Virtuellen Maschinen auf SLES 12 migriert sind kann SAP den Support für das veraltete SLES 11 und dessen SysV init.d reibungsfrei einstellen.
SAP Cloud Platform Core HA & DR Datenbank-Fehlerüberwachungsentwicklung:
Architektur, Design, Implementierung und Erweiterung von Hochverfügbarkeits- (HA) und Desaster Recovery Patterns und Funktionen für Sybase ASE Datenbanken inklusive komplexer Monitoring Patterns.
Um die im Service Level Agreement definierte Generelle Verfügbarkeit für hochverfügbare und Desaster Recovery-fähige Sybase ASE Datenbank Server auf all SAP Cloud Rechenzentren und Landschaften zu erreichen entwarf und implementierte ich HADR Fehler- und Ausfallüberwachung für Sybase ASE Datenbankserver in einem vorgegebenen engen Zeitrahmen.
Als Ergebnis können SAP Cloud Platform Kunden hochverfügbare und Desaster-Recovery-fähige Sybase ASE Datenbanken erfolgreich zu einer gegebenen Frist angeboten werden und das SAP Cloud Platform Service Level Agreement erfüllt werden
(Name auf Anfrage) ist eine Landschaft bestehend aus mehreren Enterprise-Systemen, die alle Kreditmeldungen deutschland- und EU-weit entgegen nimmt und Kreditrisiken verwaltet. Diese Systeme bilden die Grundlage für das gesamte Berichtswesen der Bankenaufseher.
Verantwortlichkeiten:
Aktivitäten:
WebFOCUS Business Intelligence Architektur für (Name auf Anfrage)
Architektur, Design und Spezifikation der Integration aller (Name auf Anfrage)-Systeme in die Business Intelligence Plattform WebFOCUS.
(Name auf Anfrage)-ist eine Sammlung von mehreren Bankenaufsichtsrechtlichen Systems die künftig als Datenquelle in die 3-Party Business Intelligence Plattform WebFOCUS integriert werden sollen, um alle Arten von Auswertungen zu ermöglichen.
In meiner Rolle als Architekt entwickelte und spezifizierte ich die gesamte übergeordnete Architektur, den BPMN Prozessfluss, und die Zeitliche Planung der Integration des (Name auf Anfrage)-Systems in die BI Plattform WebFOCUS. Die Architektur und Spezifikation wird von WebFOCUS-Experten in Zusammenarbeit mit der Fachabteilung und den (Name auf Anfrage)-Softwareentwicklungsteams implementiert.
Das Ergebnis der Architektur und Spezifikation ermöglicht der Bankenaufsicht künftig (Name auf Anfrage)-Daten in ihren Auswertungen zu benutzen. Zusätzlich ist die Bankenaufsicht über die geschätzten Aufwände, sowie dem zu erwartenden Bereitstellungstermin informiert.
WebFOCUS Business Adapter für (Name auf Anfrage)
Architektur, Design, Spezifikation und Prototypimplementierung einer geschäftsnahen Abstraktionsebene für Ad-hoc-Auswertungen.
(Name auf Anfrage) ist das Nachfolgesystem für (Name auf Anfrage) und basiert auf einem technisch sehr anspruchsvollen Datenmodell. Bankenaufseher nutzen die Drittanbieterplattform WebFOCUS Business Intelligence. Aufgrund der technischen Komplexität des (Name auf Anfrage) Datenmodells war es den Bankenaufsehern bisher nicht möglich dieses für ihr Berichtswesen zu nutzen.
In meiner Rolle als Business Analyst sammelte ich alle Informationen über die Geschäftsabläufe und Berichtsanforderungen der Bankenaufsicht und spezifizierte und modellierte eine geschäftsnahe Zwischenschicht zwischen den WebFOCUS-Benutzern und dem Datenmodell. Die Implementierung dieser Schicht wurde durch Experten von WebFOCUS implementiert.
Als Ergebnis kann die Bankenaufsucht nun Daten aus (Name auf Anfrage) in ihre Berichte mit aufnehmen. Entsprechende Abstraktionsschichten werden nun analog zu der geschaffenen auch für andere noch nicht in WebFOCUS eingebundene Systeme eingeführt.
Interface Analyse
Analyse aller eingehenden, ausgehenden und internen Schnittstellen aller (Name auf Anfrage) Applikationen.
Aufrund der ähnlichen Geschäftsnatur der Deutsche Bundesbank und der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) existieren in beiden Instituten ähnliche Daten. Um der BaFin weitere ausgehende Schnittstellen bereitzustellen werden alle Schnittstellen aller ( Name auf Anfrage)-Systeme analysiert.
Das Ziel ist es der BaFin weitere Schnittstellen ohne signifikante Entwicklungsaufwände bereitstellen zu können.
Click Statistics Collector ist ein ETL System, dass Klickstatistiken zu Analystenpublikationen von verschiedenen Lieferanten zu Abrechnungszwecken sammelt, normalisiert und speichert.
Es ist eine Business-Managed Applikation, deren Entwicklung ich derzeit parallel zu meinem Hauptprojekt ?FastBase? betreibe.
Verantwortlichkeiten:
Aktivitäten:
Click Statistics Collector
Architektur, Design und Implementierung der
Click Statistics Collector Applikation.
Analysten der Commerzbank erstellen Marktforschungs- und Analysepublikationen und stellen diese für Kunden über die Kanäle verschiedener Anbieter wie Reuters, Bloomberg, Standard & Poors oder FactSet zur Verfügung. Die Aufgabe des (Name auf Anfrage) ist die sich daraus ergebenden ?Welcher Kunde klickte wann auf welche Publikation?-Informationen zu sammeln und intern vorzuhalten.
Das System setzt sich zusammen aus anbieterspezifischen Imports und zeitgesteuerten Prozessen welche die Daten sammeln, validieren, normalisieren und in eine gemeinsame Datenbank laden.
Durch die Benutzung dieses Systems ist die Commerzbank nun in der Lage Abrechnungen auf Ebene einzelner Benutzerkonten zu erstellen. Zusätzlich wird es verwendet um eine Vielzahl an Berichten zu erstellen die zum Beispiel als Basis für Neuverhandlungen von Verträgen oder für die Preisbildung von Publikationen dienen.
Zusätzlich wird mit der Inbetriebnahme des Systems eine regulatorische MiFiD2 Vorgabe erfüllt die vorgibt dass alle Klickstatistiken von internen und externen Portalen nachverfolgbar sein müssen.
FastBase ist ein System das eine Vielzahl an Diensten und Benutzeroberflächen zur Verfügung stellt um Marktanalysten, sowie internen und externen Kunden verschiedene Arten von Daten für den täglichen Gebrauch bereitzustellen. Dabei handelt es sich hauptsächlich um Instrument- und Marktdaten, Zinskurven und Prognosen,
Das System bedient mehr als 250 Kunden und Abnehmersysteme.
Verantwortlichkeiten:
Aktivitäten:
Forecast Service
Architektur, Design und Implementierung des RESTful Service ?Forecast Service? sowie des dazugehörigen Clients als flexibles Excel Addin.
Da in der Vergangenheit alle Prognosedaten über hunderte Excel Dateien verteilt waren die sich gegenseitig referenzierten, war die Änderung von Prognosedaten nicht nur mit hohen Aufwänden verbunden, sondern auch sehr fehleranfällig.
Durch den neuen Forecast Service können Benutzer nun ohne technische Kommunikation zwischen den involvierten Abteilungen Prognosedaten parallel lesen und schreiben. Alle technischen Fehler der Excel Dateien wurden eliminiert und der Prozess fehlerhafte Daten zu finden und zu korrigieren wurde maximal vereinfacht.
Zusätzlich wurde mit dem Dienst ein Team Excellence Audit-Befund behoben der vorgibt dass
Änderungen an Prognosedaten nachverfolgbar und versioniert sein müssen.
FastBase Service
Architektur, Design und Implementierung eines neuen JSF Dienstes ?(Name auf Anfrage) Service? um die Weiterentwicklung der bankinternen Client Applikation zu ermöglichen. Der bisherige Client war in Visual Basic 6 entwickelt worden, welches stark veraltet und in der Bank auch nicht mehr verfügbar ist. Dadurch lag die Weiterentwicklung lange auf Eis. Alle Funktionalitäten des bisherigen Clients wurden in einen neuen Java Server Faces Dienst adaptiert und optimiert und sind nun durch den Webbrowser verfügbar.
Der neue Dienst eliminiert eine Reihe von Fehler des veralteten Clients und stellt die Möglichkeit zum Hinzufügen und Weiterentwickeln von Kerngeschäftsfunktionen wieder her.
Der Dienst erfüllt alle Standards und Richtlinien der Bank für moderne Softwarearchitektur und trennt zusätzlich alle Benutzer durch die Schnittstelleneigenschaft des Web-Frontend vom direkten Zugriff auf die Datenbankebene.
Scheduler Re-Design und Referenzimplementierung eines Prototyps
Architektur, Design und Referenzimplementierung eines UC4-gesteuerten Scheduler-Prototyps, sowie Implementierung von beispielhaften (Name auf Anfrage) Prozessen.
Derzeit erfolgt die Steuerung aller ETL-Prozesse in (Name auf Anfrage) durch eine stark angepasste ?Activity BPMN Engine?-Applikation. Diese ist nicht nur äußerst fehleranfällig, sondern gibt generell auch nur sehr wenig Rückmeldung. Sie verstößt auch gegen die bankinterne Scheduler-Richtlinie. Darüber hinaus erfordert sie ein solch beträchtliches Maß an Wissen um ihre Eigentümlichkeiten, dass zwei Entwickler nahezu komplett an die Entwicklung und Fehlerbehebung von absoluten Basisfunktionalitäten gebunden sind.
Die Implementierung einer neuen Scheduling-Plattform auf der Basis von UC4 wird zu einer wesentlich saubereren und leichter zu verstehenden Architektur führen und somit zwei Entwicklerressourcen freisetzen.
Zusätzlich wird die Scheduler-Richtlinie eingehalten da die gemanagte UC4 Plattform verwendet wird. Das neue Design kann leicht von der ?SPManager?-Referenzimplementierung für weitere Prozesse adaptiert werden.
SPManager
Architektur, Design und Implementierung einer Applikation zur Verwaltung von Stored SQL Procedures. (Name auf Anfrage) beinhaltet mehr als 2500 Stored Procedures welche direkt durch die Fachabteilung auf dem produktiven System geändert werden.
Bisher war es aufgrund von Zugriffsbeschränkungen und mangelnder Kommunikation sehr schwierig die produktiven Stored Procedures synchron zu denen in der Entwicklungsumgebung zu halten. Das führte bei Liefereinsätzen in der Produktionsumgebung oft zu Fehlern wenn solche geänderten Stored Procedures durch neue Softwarepakete adressiert wurden. Darüber hinaus gab es keine Revisionskontrolle oder Änderungsverfolgung der Stored Procedures.
Der SPManager findet auf täglicher Basis neue und geänderte Stored Procedures in der Produktionsumgebung und meldet diese samt Quellcode an die Entwicklungsabteilung zur Einpflege in die Revisionskontrolle. Dadurch sind alle Stored Procedures in TFS versioniert, was zu wesentlich unaufgeregteren Liefereinsätzen führt. Zusätzlich werden auf wöchentlicher Basis Nutzungsstatistiken gemeldet um unbenutzte Stored Procedures aufzuspüren.
Der SPManager ist die Prototyp- und Referenzimplementierung der neuen UC4-basierten Scheduling-Plattform.
Generelle Aktivitäten:
silver9 ist ein Unternehmen und eine Plattform zum Handeln und Verwalten von elektronischen Waren. Zur Plattform gehört auch ein Onlineshop.
Verantwortlichkeiten:
Aktivitäten:
Photon
Architektur, Design und Implementierung der Mehrbenutzerapplikation ?Photon?.
Photon ermöglicht es Händlern international mit Waren zu handeln.
Es verfügt über verschiedene Module wie Kunden- und Geschäftspartnerverwaltung,- internationaler Versand, internationale Steuer- und Gebührenverwaltung und mehr.
Die Applikation erlaubt die Handhabung eines kompletten Geschäftslebenszyklus von Angebot, Auftrag, Ausführung über Rechnungsstellung und mehr.
(Name auf Anfrage) beinhaltet automatisierte Schnittstellen-ETL-Prozesse um Lagerbestände und Preise von Waren von verschiedenen Geschäftspartnerunternehmen zu beziehen um daraus Verkaufspreise und Warenbestände zu ermitteln. Es verfügt zudem über ein Modul zur Verwaltung der Inhalte auf den Webseiten des Onlineshops und eine Modul zur Verwaltung von Dokumenten. Darüber hinaus beinhaltet (Name auf Anfrage) ein Modul um Waren über einen Onlineshop zu verkaufen.
Das (Name auf Anfrage)-System sowie der Onlineshop nutzen beide Responsive Design um den Zugriff gleichermaßen über mobile Endgeräte und Desktopgeräte mit einer einzigen Implementierung zu gewährleisten.
Beschreibung
Das Projekt hatte keinen konkreten Namen. Es war ein übergreifendes Projekt und umfasste mehrere Handelsabteilungen und beinhaltete verschiedene Applikationen um Synergieeffekte zu erzeugen.
Die hauptsächlichen Interessensgruppen waren:
Ich begleitete das Projekt in verschiedenen Rollen:
Verantwortlichkeiten:
Abteilung:
Das Projekt umfasste 3 bis 8 Entwickler. Inklusive Fachabteilunskoordinatoren, Management, Administration und Referenzkunden umfasste das Projekt bis zu 30 Personen. Die Handelsabteilungen, das Management und die Entwickler waren über Frankfurt, London, New York und Indien verteilt.
Aktivitäten
Austausch der Handelsplattform der ETF Borrowing & Lending-Abteilung
Beratung, Leitung und mehrphasiges Architekturdesign über den Austausch der kompletten Handelsplattform der New York ETF Borrowing & Lending-Abteilung von Pirate und FlexTrade hin zu Bloomberg SSEOMS, BasketTrader, CGI und MUREX.
Die übergeordneten Ziele waren die komplette Handelsplattform auszutauschen um Lizenzkosten durch die Benutzung von Bloomberg SSEOMS zu sparen, einen transparenteren Fluss von Handelsdaten durch die Nutzung des hauseigenen FIX Message Backbones zu erreichen und die Commerzbank Richtlinie zu erfüllen die vorgibt, dass alle Positionen der Bank in MUREX gehalten werden müssen. Des Weiteren wurde erwartet dass die neue Plattform eine höhere Gesamtgeschwindigkeit aufweisen wird.
Da das Projekt das Sparen von mehreren Millionen Euros garantierte, wurde es als ein COIN Projekt akzeptiert.
In meiner Rolle als Business Analyst arbeitete ich eng mit der Fachabteilung zusammen um optimale Lösungen für konkrete Probleme zu finden und alle potentiellen Probleme und Schwachstellen aufzuzeigen.
In meiner Rolle als Softwareinfrastrukturarchitekt erarbeitete ich optimale Datenflüsse um sicherzustellen, dass alle existierenden Schnittstellen und regulatorischen Berichte weiterhin versorgt werden. Ich beriet die Fachabteilung welche Teile der Plattform durch welche Alternativen ausgetauscht werden können und welche zwingende Erweiterungen benötigen. Ich erstellte Aufwandsschätzungen für verschiedene Architekturvorschläge und mehrphasige Migrationen.
In meiner Rolle als Chef-Entwickler erweiterte oder entwarf ich Applikationen und Prototypen die existierende Teile von Pirate und FlexTrade ersetzten. Ebenso spezifizierte ich die Anforderungen für einen neuen Dienst ?MUREX Position Service? welcher auf Anfrage aktuelle Positionen aus MUREX bereitstellte. Dieser Dienst wurde von der MUREX-Abteilung implementiert und in Betrieb genommen und später auch von verschiedenen anderen Abteilungen genutzt. Zusätzlich plante, verteilte und verfolgte ich alle Aktivitäten der Entwickler und berat diese bei komplexen Problemen.
In meiner Rolle als Onsite Koordinator koordinierte ich alle Kommunikation, Wissenstransfers und Aktivitäten unserer Entwicklerkollegen in Indien.
Seit der Inbetriebnahme der neuen Handelsplattform wurden durch das bessere Lizenzmodell von Bloomberg SSEOSM eine Menge an Kosten eingespart. Als weiteres Ergebnis sind nun alle Positionen in MUREX in Echtzeit vorhanden und damit die Richtlinie erfüllt dass alle Positionen in MUREX verfügbar sein müssen. Auch war es der Bank nun möglich eine Übersicht über alle bankweiten Positionen in einem System zu haben, was täglich vom Management und Direktorium zur Entscheidungsfindung genutzt wird.
Die neuen Handelsdatenflüsse durch den bankeigenen FIX Message Backbone befolgten alle Standards und Regeln was einerseits zu einem leichter verständlichen Routing und andererseits zu einer wesentlich transparenteren Nachverfolgung von Handelsaufträgen führte. Administratoren konnten nun durch die Benutzung von Standard-Tools einen besseren Support für problematische Aufträge bieten.
Durch die Nutzung von neu entwickelter oder existierender Hochgeschwindigkeitsapplikationen konnte die Gesamtgeschwindigkeit stark gesteigert werden. Täglich wiederkehrende Prozesse wie zum Beispiel das Rebalancing des Hauptkontos konnten so stark optimiert werden dass sie nun nur Minuten anstelle von Stunden benötigen.
Mit dem Einführen von Expertensystemen (Rule Engines) im Handelsdatenfluss konnten das Management, die Händler, Administratoren und Entwickler eine Menge an Zeit sparen da die Kommunikation zwischen den Personen nun auf einer standardisierten Regelsprache basiert.
BasketTrader
Architektur, Design und Weiterentwicklung der existierenden Applikation ?BasketTrader? zum Etablieren einer abteilungsübergreifenden Lösung für Investment-Banking und Handel. BasketTrader ist eine Frontendapplikation zur Eingabe und Überwachung von Handelsaufträgen in Echtzeit.
Die Applikation bezieht in Echtzeit Preise von verschiedenen Anbietern und zeigt diese dem Benutzer zur Finden einer Handelsentscheidung an. Des Weiteren können Handelsaufträge mit den Marktpreisen generiert werden. Für den Bezug dieser Preisdaten wurden verschiedene steckbare Module (Plug-Ins) für die Preislieferanten Bloomberg und Reuters realisiert
Es wurde auch ein Modul hinzugefügt dass die Benutzerkonfiguration aus einer Datenbank lädt.
BasketTrader wurde für die New Yorker ETF Borrowing & Lending-Handelsabteilung dahingehend erweitert, dass auch ETFs, Swaps, Cash-Amounts und andere Typen von Instrumenten gehandelt und verwaltet werden konnten. Um geliehene und verliehene Positionen der Handelsabteilung in Balance zu halten wurde ein präziser Algorithmus implementiert der das Rebalancing eines Kontos mit mehreren Unterkonten und einer Vielzahl von Instrumententypen im Wert von mehr als 4 Milliarden US Dollar auf Abruf vornahm.
Als Ergebnis dieses Algorithmus wurde dem Rebalancing-Händler ein fertig zu handelndes Portfolio mit Kauf- und Verkaufsaufträgen angeboten um das Konto täglich ein- oder mehrmals in Balance zu bringen. Um die Balance des Kontos zu ermitteln wurden alle Positionen der Abteilung von dem bankinternen WebService MUREX Position Service abgerufen.
Ebenso wurden alle Geschäftsprozesse wie das Erzeugen oder die Rückgabe von ETFs, außerbörslicher Handel oder der Kontotransfer von Positionen implementiert
BasketTrader wurde von bis zu 3 Entwicklern parallel entwickelt und von bis zu 30 Händlern genutzt. Weitere Informationen über den BasketTrader und seine Geschichte sind in diesem Dokument in der Zeitspanne von 09.2008 bis 03.2011 verfügbar.
CGI
Architektur, Design und Implementierung des Kerns und Prototyps des regelbasierten Expertensystems (Rules Engine) ?CGI? als handelsabteilungsübergreifende Lösung zum Buchen von ausgeführten Handelsaufträgen in MUREX für die Verwaltung von Positionen und spätere Rechnungsstellung. CGI ist eine ETL-Prozessapplikation für Handelsnachrichten. Es extrahiert und transformiert eingehende FIX Protocol-Nachrichten über Handelsausführungen in MUREX-spezifische Stored SQL Procedure Aufrufe und führt diese aus.
Bisher nutzte die Cash Equities Handelsabteilung die hauseigene Applikation ?SSEOMS-MF?. Diese war sehr intransparent und verkompliziert entwickelt worden und hatte einige ernsthafte Geschwindigkeitsprobleme bei Buchungen von hochvolumigen Transaktionen in MUREX.
Hinzu kam eine Anforderung für die New York ETF Borrowing & Lending Handelsabteilung alle Transaktionen ebenfalls in MUREX zu buchen, da die Applikation Pirate durch ihre interne Positionsverwaltung gegen eine bankinterne Richtlinie verstieß.
Eine weiterte Anforderung der Administration und des Supports war es die Regeln, zu Beispiel Mappings, die während der Transformation zur Anwendung kamen im laufenden Betrieb ändern zu können ohne auf einen neuen Liefereinsatz angewiesen sein zu müssen.
CGI wurde als hochflexible, multi-threaded und Regelsätze-basierte Pipeline entworfen mit multiplen und steckbaren Handlern für maßgeschneiderte Nachrichtenverarbeitung in jeder der Input-, Transformations-, und Output-Stufen.
Der Kern wurde um das Business-Rules-Managementsystem Drools konzipiert. CGI konnte mit generellen Transformationsregeln gefüttert werden welche allen Handelsabteilungen gemein waren. Diese konnten für jede Abteilung mit spezifischen Regelsätzen überschrieben oder mit Neuen erweitert werden. Auf diese Weise konnten verschiedene Nachrichten von multiplen Abteilungen mit gemeinsamen und spezifischen Regelsätzen in einer einzigen Instanz verarbeitet werden. Die Regeln wurden in einer Java-basierten domänenspezifischen Sprache (DSL) verfasst.
Die Applikation wurde an die New Yorker ETF Borrowing & Lending Handelsabteilung ausgeliefert während die Handelsplattform Pirate ausgetauscht wurde. Zur Anwendung kamen allgemeine Nachrichtenhandler, sowie allgemeine und abteilungsspezifische Regeln.
Später wurde CGI an die Cash Equities Handelsabteilung mit allgemeinem und abteilungsspezifischen Regelsätzen und einigen spezifischen Nachrichtenhandlern ausgeliefert.
Die Diskussionen um CGI auch an die Flow Trading Handelsabteilung auszuliefern dauern aktuell noch an. Aktuell gibt es auch eine Diskussion ob CGI für den Londoner Index Arbitrage-Handel eingesetzt werden kann.
Des Weiteren wird diskutiert ob CGI künftig als System für das Routing von Handelsaufträgen fungieren kann, da die Natur des Systems dies zulässt. Somit kann der existierende ESA-Router ersetzt werden und eine gemeinsame Codebasis und DSL geschaffen werden wodurch Kosten eingespart werden können.
Durch die Verwendung von CGI als geschäftsregelbasierte Transformations-Engine zum Generieren von MUREX Positionen aus FIX Protocol-Nachrichten heraus erhielt die Bank eine abteilungsübergreifende Lösung, die auf alle Eigenheiten der jeweiligen Abteilung eingehen kann, Die Lösung kann auch für komplett andere, ebenfalls in der regelbasierten Domäne angesiedelten Probleme, wie zum Beispiel Routing wiederverwendet werden.
Im Ergebnis konnte die ETF Borrowing & Lending Handelsabteilung durch den Einsatz vn CGI erfolgreich von Pirate weg migriert werden und die bankinterne Richtlinie zum Halten von Positionen in MUREX implementieren.
Die Cash Equities Abteilung konnte erfolgreich von der undurchsichtigen SSEOMS-MF Schnittstellenapplikation weg migriert werden. Administratoren und Supporter konnten nun Regeln im laufen Betrieb in einer einfachen Sprache anpassen. Zusätzlich wurden alle Geschwindigkeitsprobleme gelöst. Eine Messung ergab dass eine Stunde Verarbeitung in SSEOMS-MF auf eine Minute Verarbeitung in CGI beschleunigt werden konnte. Hochvolumige Transaktionen sind nun nahezu in Echtzeit in MUREX verfügbar.
Neben den technischen Vorteilen profitierten beide Handelsabteilungen von der strikten Trennung der Geschäftsregeln von der technischen Implementierung. Die Kommunikation der Entwickler, Administratoren, Supporter, Händler und des Management konnte stark verbessert werden, da alle Regeln in einer gemeinsam verständlichen Sprache formuliert waren. Dadurch wurden das Hinzufügen oder Ändern von Regeln, sowie das Finden von Problemen für alle involvierten Personen wesentlich einfacher.
CGI wurde von bis zu 2 Entwicklern parallel entwickelt. Meine Aufgabe war es eine Lösung für die ursprünglichen Probleme und Anforderungen zu erarbeiten, den Kern und Prototyp zu implementieren, der allgemeine und abteilungsspezifische Regelsätze verarbeiten kann.
Sobald CGI ein startklares System war, dass die Erfüllung aller funktionalen Anforderungen beweisen konnte, übergab ich die weitere Evolution an einen Mitarbeiter der die konkreten Geschäftsregeln und spezifischen Nachrichtenhandler in Zusammenarbeit mit den Fachabteilungen und Händlern implementierte.
Ich entwickelte CGI parallel zum BasketTrader und konzentrierte mich wieder auf die Entwicklung des BasketTrader nachdem die Entwicklung von CGI von meiner Seite soweit fortgeschritten war dass ich es übergeben konnte.
Weitere Aktivitäten
FastBase ist ein System das eine Vielzahl an Diensten und Benutzeroberflächen zur Verfügung stellt um Marktanalysten, sowie internen und externen Kunden verschiedene Arten von Daten für den täglichen Gebrauch bereitzustellen. Dabei handelt es sich hauptsächlich um Instrument- und Marktdaten, Zinskurven und Prognosen,
Das System bedient mehr als 250 Kunden und Abnehmersysteme.
Verantwortlichkeiten:
Aktivitäten:
Reverse Engineering, Migration, DownloadService
Reverse-Engineering des gesamten
FastBase Systems in Zusammenarbeit mit der Fachabteilung und einem Software Architekten nachdem alle FastBase Entwickler im Zuge der Übernahme der Dresdner Bank diese über Nacht verließen.
Migration und Integration des gesamten Systems aus der alten Welt der Dresdner Bank in die neue Welt der Commerzbank.
Architektur, Design, Implementierung und Integration eines neuen DownloadService für die
FastBase ETL-Prozesse mit Unterstützung für HTTP, HTTPS, FTP, SFTP, LOCAL und SMB Protokolle und optionaler Proxy Authentifizierung.
Ich wechselte als Interim-Entwickler und Reverse-Ingenieur in das
FastBase Projekt als sich dieses in einer kritischen Phase befand um dem Projekt zu helfen am Leben zu bleiben bis ein neuer langfristiger Entwickler gefunden wurde.
Nach dem Reverse-Engineering des Kerns wurden alle Ergebnisse und Diagramme der Fachabteilung und dem neuen Entwickler übergeben.
Als Ergebnis der Migration überlebte das
FastBase System in der neuen Welt der Commerzbank und existiert dort auch heute noch.
Die Benutzung des neuen DownloadService erlaubt es der Fachabteilung und den Entwicklern neue Download-Prozesse als Teil von ETL-Prozessen durch einfache Konfiguration aufzusetzen.
Die gemeinsame Codebasis spart Kosten indem Codeduplikate vermieden werden und reduziert das Risiko neue Fehler zu implementieren.
Das Projekt hatte keinen konkreten Namen. Es war ein übergreifendes Projekt und umfasste mehrere Handelsabteilungen und beinhaltete verschiedene Applikationen um Synergieeffekte zu erzeugen.
Die hauptsächlichen Interessensgruppen waren:
Verantwortlichkeiten:
Abteilung:
Das Projekt umfasste bis zu 3 Entwickler.
BasketTrader
Architektur, Design und Implementierung einer abteilungsübergreifenden Lösung für Investment-Banking und Handel. BasketTrader ist eine Frontendapplikation zur Eingabe und Überwachung von Handelsaufträgen in Echtzeit.
BasketTrader is eine FIX Protocol-konforme, modulare, hochperformante Java Swing GUI, die von Händlern für hochvolumige Transaktionen von Einzelinstrumenten oder Instrumentenlisten mit einer niedrigen Latenz eingesetzt wird.
Er unterstützt alle Arten von Instrumenten aus multiplen Instrumentenuniversen. Das Instrumentenuniversum ist als modulare Implementierung realisiert (Plug-In). Dadurch können abteilungsspezifische Instrumentendatenbank, Instrumente von anderen Anbietern oder andere bankinterne Instrumentenuniversen kaskadiert genutzt werden. Die Applikation verwaltet und visualisiert komplette Lebenszyklen wie Eingabe, Ausführung und Überwachung von Handelsaktivitäten.
Während einer Handelsaktivität wird eine Reihe von Informationen angezeigt wie zum Beispiel der Zustand des Geschäfts und entsprechende Fehler, der Fortschritt des Geschäfts, die Anzahl der ausgeführten Einheiten, durchschnittliche Ausführungspreise und mehr.
Für jedes Instrument in einem Warenkorb sind Echtzeitpreise (BID und ASK) sichtbar. Die Preislieferung ist eine Implementierung eines Reuters RFA Clients. Sie unterstützt verschiedene Markttiefen die optional auch angezeigt werden können.
BasketTrader bietet ein frei konfigurierbares Modul um Handelsnachrichten mit spezifischen Informationen anzureichern, die von Händlern im Frontend eingegeben werden können oder fix sind.
Die Flow Trading Abteilung nutzt dieses Modul um den Händlern die Eingabeparameter einer algorithmischen Handels-Engine zu offerieren. Dadurch können die Händler die Handels-Engine instruieren wie ein Handel getätigt werden soll. Beispiele sind das defensive Handeln entsprechend des volumen- oder zeitgewichteten Durchschnittspreises (VWAP / TWAP).
Die Cash Equities Abteilung nutzt dieses Modul um den Nachrichtenrouter ESA Router zu instruieren wohin ein Handelsauftrag geleitet werden soll.
BasketTrader wurde von bis zu 3 Entwicklern parallel entwickelt und von bis zu 15 Händlern im Flow Trading und 2 Händlern in Cash Equities genutzt. Aufgrund seiner Möglichkeiten FIX Protocol-Nachrichtenkommunikationen sehr tief inspizieren zu können wird es auch von einer unbekannten Anzahl an Entwicklern in der Bank als Diagnosetool genutzt.
Weitere Aktivitäten
Object+ ist ein in Amsterdam ansässiges Softwarehaus dass die Applikation
Universal Fix Gateway entwickelt und vertreibt.
Universal Fix Gateway ist ein komponentenbasiertes FIX Protocol Nachrichtenverarbeitungssystem dass FIX Nachrichten enkodieren, dekodieren, routen und auf verschiedene Arten verarbeiten kann.
Das Ziel war es einen
Universal Fix Gateway für die Fortis Bank zu entwickeln um Aktienangebote (Quotes) von der schwedischen OMX Börse zu empfangen und in einer Datenbank zu speichern.
Verantwortlichkeiten:
Universal Fix Gateway
Design und Implementierung eines Fix Message Translator und eines Fix Quotation Datenbankmoduls für den Universal Fix Gateway, sowie Inbetriebnahme der Lösung in der Umgebung des Kunden.
Als Ergebnis der Installation des kundenspezifischen Universal Fix Gateway konnte die Fortis Bank neue Prozesse für OMX-Handelsgeschäfte in ihrer Clearance- und Settlement Abteilung aufsetzen,
(Name auf Anfrage) ist ein System, dass alle Handelsgeschäfte der Commerzbank auf Legalität und Marktkonformität prüft.
Verantwortlichkeiten:
Aktivitäten:
UC4 Migration
Design, Implementierung und Migration aller existierenden Crontab- und manuellen Prozesse auf die UC4 Scheduling-Plattform.
Bisher wurden alle Prozesse entweder manuell oder durch Crontab gestartet. Crontab verletzte die Scheduling-Richtlinie.
Als Lösung wurden alle Prozesse auf die UC4 Scheduling-Plattform migriert und im Ergebnis die Aufwände der Administration durch automatisierte anstelle von manuellen Prozessen
minimiert. Zusätzlich wurde die Scheduling-Richtlinie durch den Wegfall von Crontab implementiert
MDDS ist das zentrale System in der Bank um statische und Marktdaten von verschiedenen Lieferanden zu sammeln und intern anzubieten.
Die Daten werden normalisiert und in einer SQL Datenbank, sowie einem Flatfile-System gespeichert. MDDS verteilt die Daten an mehr als 200 Kunden und Abnehmersysteme. Kern des MDDS Systems ist eine riesige Erweiterung des Assetmanagementsystems Asset Control.
Verantwortlichkeiten:
Aktivitäten
MDDS
Design und Implementierung verschiedener Modules und ETL-Prozesse für MDDS unter Beachtung der gegebenen Architektur.
Periodische Migrationen von MDDS auf neue Versionen des Kernsystems Asset Control.
MDDS ist das zentrale System in der Bank um statische und Marktdaten von verschiedenen Lieferanden zu sammeln und intern anzubieten.
Das Einsammeln der Data ist in mehr als 350 ETL-Prozessen implementiert, die alle innerhalb eines komplexen Scheduling-Plans getriggert werden.
Das Ziel des Projektes war die Migration des kompletten Scheduling-Plans von der vorherigen Scheduling-Plattform Autosys auf die neue UC4 Plattform.
MDDS wurde als erstes Pilotprojekt ausgewählt um die Migration auf UC4 durchzuführen und UC4 als eine stabile Plattform zu evaluieren.
UC4 was war im Begriff die neue bankweite Standardplattform für das Scheduling zu werden.
Verantwortlichkeiten:
Aktivitäten:
UC4 Migration
Design, Implementierung, Migration und Inbetriebnahme aller Prozesse auf die neue UC4 Plattform und Entwicklung einer API für die programmatische Kontrolle von UC4 aus MDDS Prozessen heraus.
Im Ergebnis der Pilotmigration erwies sich UC4 als robuste und stabile, flexible und komfortable Scheduling-Plattform. Später wurde UC4 der neue Standard in der Bank und andere Abteilungen nutzten die entwickelte API um UC4 von ihren Applikationen heraus zu steuern.
Für MDDS war die Migration ein voller Erfolg, da die Flexibilität und Visualisierungsmöglichkeiten jene von Autosys bei weitem übertrafen.
Freiberufliche Tätigkeit als Webentwickler
Verantwortlichkeiten:
Aktivitäten
Website Development
Design und Entwicklung verschiedener Webseiten für verschiedene Kunden.
Consultec AG war ein Unternehmen dass die Applikation Infotainment entwickelte und verkaufte.
Infotainment, als verteiltes Multimedia-, Präsentations- und Content-Managementsystem, konnte multiple zeitgesteuerte Werbespots verschiedener Formate auf einem einzigen Bildschirm anzeigen. Es war zusammen mit einer Content-Managementapplikation paketiert.
Das Ziel war ein Reverse-Engineering der Infotainment Software und das Training künftiger Entwickler und Content-Schöpfer.
Verantwortlichkeiten:
Aktivitäten:
Infotainment
Reverse-Engineering der Infotainment Software, Erweiterung kleinerer Features und Behebung von Fehlern.
Entwicklung einer Webapplikation für ein Partnerunternehmen die Händlerprovisionen anzeigt.
Rolle: Chef-Entwickler, Architekt, Business Analyst, Netzwerkadministrator
Beschreibung:
FBP Business Consulting GmbH und Südwest AG waren eng verbundene Unternehmen in der Geschäftsberatungsindustrie. Sie boten eine Reihe von industriespezifischen Diensten für Kunden an.
Verantwortlichkeiten:
Aktivitäten:
Generelle Aktivitäten
Entwicklung von Schnittstellen und ETL-Prozessen für verschiedene Datenlieferanten und Kundensysteme.
Entwicklung von kundenspezifischen Softwarelösungen.
Administration eines Netzwerkes mit bis zu 150 PCs und Servern.