Die Versicherung speichert seit Jahrzehnten eingescannte Dokumente als Images in einem OAM Service zu Vorgängen ab. Abgeschlossene Vorgänge werden nach der Aufbewahrungsfrist durch die jeweiligen Bestandssysteme gelöscht.

Da Dokumente teilweise mehreren Vorgängen in verschiedenen Bestandssystemen zugeordnet sind, ist eine Löschung eines gescannten Dokuments bei der Löschung eines Vorgangs in einem Bestandssystem nicht möglich.

Mit internen Kollegen entwickelte ich ein Konzept zur DSGVO gemäßen Löschung und setzte ich auf dem Grossrechner um.

Zur Unterstützung des Aussendienst nutzt die Versicherung seit vielen Jahren einen Lebensversicherungs-Tarifrechner unter Windows. Die Software ist in MicroFocus COBOL geschrieben. Im Rahmen der neuen Internet-Lösung ist der Rechenkern des Tarif-Rechners auf den Mainframe portiert worden.

MicroFocus bietet gegenüber dem ANSI COBOL einige nützliche Erweiterungen, die kräftig genutzt wurden.

Besonders betrifft dieses indirekte Array-Zugriffe wie

"move a( b( c( d))) to feld".

Ich unterstützte das Team mit meinen Erfahrungen, insbesondere bei den Unterschieden MicroFocus / IBM, die mich seit meinem Studium begleiten, bei der Portierung.

Ich war ab Anfang 2017 bis Juni 2020 bei diesem Kunden Vollzeit tätig und habe verschiedenste Aufgaben wahrgenommen, anbei einige Highlights.

Mein Kunde stellte eine seit Jahrzehnten gewachsene z/OS Anwendungslandschaft um. Das bisherige Kernbank System wurde durch eine SAP Lösung ersetzt.

Diverse Umsystem, zum Beispiel zur Vertriebssteuerung, Provision-Berechnung, Datenaufbereitung für das Meldewesen, wurden um die Kosten für den IBM Mainframe zu vermeiden, auf eine LINUX Plattform umgestellt. Statt bisher z/OS, MQS, DB2, CICS, IBM COBOL, JCL werden nun LINUX, Web-Services, Oracle, MF-Enterprise-Server, Microfocus COBOL, Linux Shell Script genutzt.

Krankheitsbedingt fiel der Key-Player im Bereich Programmierung Aussendienst Organisation im Herbst 2018 sowie ab Herbst 2019 für jedes mehrere Monate aus. Seine Aufgaben wurden mir übertragen.

Da nicht klar war, wie lange noch eine Wartung vom Anbieter der Fremdsoftware Strassenverzeichnis geleistet werden kann, wurde eine Vorstudien durchgeführt. Hier konnte ich meine Erfahrungen von anderen Kunden in den Bereichen Adress-Prüfung, Dubletten, Gebietszuordnungen einbringen.

Ein Teil der Vertriebsanwendungen ist die "Wohnsitz Organisation", ein Verzeichnis aller Strassen in Deutschland mit der Zuordnung der Gemeindekennziffer (GKZ), auch Kreis-Gemeinde-Schlüssel genannt. Alle erfassten Adressen werden gegen das Strassenverzeichnis geprüft und jeder Adresse wird über ihr GKZ ein Vertriebsgebiet (Handelsvertreter mit Gebietsschutz) zugeordnet. Die Software wurde vor wohl 40 Jahren durch ein Softwarehaus als Standard-Lösung entwickelt und bei meinem Kunden im Rahmen der Postleitzahl-Umstellung (kurz nach der Deutschen Einheit) eingeführt. Die Software wurde auch nach LINUX portiert. Da der Software-Anbieter deutlich geschrumpft ist, habe ich bei der Portierung technisch unterstützt. Die Software läuft jetzt auch unter LINUX.

Danach wurde ich wieder im Bereich Vertriebsanwendungen benötigt. Ich ermittelte die circa 1.200 umzustellenden Sourcen, übergab diese an den Dienstleister, kontrollierte die Rücklieferung und führte die ersten Entwicklertests durch.

Leider gab es bei der Bereitstellung des Systems für den Fachtest, da auch etliche andere Anwendungen hier einen Bedarf hatten, eine kurze Verzögerung, so dass ein ausreichender Test vor dem geplanten Release-Termin nicht durchführbar war. Deshalb wurden die Vertriebsanwendungen auf das nächste Release verschoben. Um die Programme andere Umsysteme, die schon nach X86 gegangen waren, auch dort versorgen zu können, ermittelte ich die benötigten Unterprogramme sowie die Datenbank-Tabellen. Die Unterprogramme wurden Teil des ursprünglich geplanten Releases, wobei der Fachtest im Rahmen der anderen Umsysteme erfolgte. Weiterhin waren Datenbank-Spiegelungen der benötigten DB2 Tabellen auf die Oracle Datenbank notwendig.

Da bis zum Release-Termin einige fachliche Änderungen notwendig waren, unterstützte ich auf dem Mainframe und führte die zeitgleiche Portierung nach LINUX durch.

Nach der produktiven Einführen des Replatforming erhielt ich die Aufgabe, etwa ein Dutzend neue Datenbank Tabellen aus neuen Datenquellen für das Datenbank Reporting zu füllen. Die Ziel-Tabellen sind mit Zeitscheiben "Daten der Erkenntnis" zu bestücken, die Datenquellen liefern nur die neuen, geänderten oder gelöschten Daten für den Verarbeitungstag. Es sind mehrere Datenbank-Tabellen aus dem Quellsystem zu einer zu füllenden Tabelle zu kombinieren, wobei nicht alle Quell-Datenfelder relevant sind. Die Datenquellen werden auf dem gleichen Oracle Datenbank Server wie die zu füllenden Bestands-Tabellen bereitgestellt. Zusammen mit zwei Kollegen entwickelte ich ein Vorgehen auf Basis meiner Erfahrungen in früheren Projekten bei anderen Kunden. Die Datenquellen werden durch teilweise recht komplexen Select Befehle mit Common Table Expressions in eine Tabelle TEMP-1 geschrieben (INSERT ON SELECT), die schon das Zielformat repräsentiert. Danach wird diese Tabelle mit der Bestands-Tabelle verglichen und das Delta in eine Tabelle TEMP-2 geschrieben, auch ein INSERT ON SELECT. Bei einigen Tabellen sind "Auslöser-Dateien" für nachgelagerte Programme zu erstellen, dieses geschieht auf Basis der TEMP-2 Tabelle. Über den Inhalt der TEMP-2 Tabelle werden in der Bestands-Tabelle die zu ersetzenden Datensätze abgegrenzt, also per UPDATE das "Gültig-Bis" Datum gesetzt. Zum Schluss wird die TEMP2 Tabelle in die Bestandstabelle per INSERT eingefügt. Pro Tabelle wurde ein Steuer-Programm und ein Zugriffs-Modul erstellt. Jedes Steuer-Programm und jedes Zugriffs-Modul besteht primär aus einem "Code-Copy", also den gleichen Befehlen. Dieses "Code-Copy" ist mit einer Abstrakten Klasse bei der Objekt Orientierten Programmierung zu vergleichen. Pro Programm sind "nur" die Namen der Tabellen, die Feldnamen sowie der SQL SELECT zum Lesen der Quell-Tabellen zu implementieren. Die anderen SQL-Befehle werden zur Laufzeit generiert. Die Vorgänger Programme, die fachlich etwas vergleichbaren tun, jedoch auf Basis von sequentiellen Dateien und mit anderen Ziel-Tabellen, liefen auf z/OS zwischen 30 Minuten und 2 Stunden, auf LINUX nach dem Replatforming eher 1 bis 5 Stunden. Die neuen Programmen laufen in Minuten, das Programm mit dem größten Datenvolumen circa 10 Minuten.

Die Batch-Tests waren Vergleichstests zwischen den bisherigen z/OS Abläufen und den neuen LINUX Abläufen. Waren auf dem Mainframe die Batches gelaufen, wurde die Ergebnis-Dateien auf ein LINUX System kopiert. Sobald auf der LINUX Maschine die Batches beendet waren, wurden ein Vergleichs-Script gestartet.

Meine Aufgabe war die Analyse und technische Bewertung der Unterschiede, um die Ergebnisse für die Tester aus dem Fachbereich verständlich zu machen. Hierzu passte ich das Shell-Script bestehend aus sort, sed und diff Befehlen und deren Parametern an. Zum Abschluss wurden die Ergebnisse automatisch in eine EXCEL Sheet geschrieben und dem Fachbereich auf einem Laufwerk zur Verfügung gestellt.

Problemzonen waren natürlich die Sortierung (EBCDIC / ASCII) sowie einige Sonderzeichen. Die Ursprungsdaten stammen teilweise aus SAP Systemen, die den Zeichensatz ISO 8859-1 nutzen, für die Umsetzung nach EBCDIC gibt es eingespielte Regeln. Die Oracle Datenbank läuft mit UNICODE und kann damit alle Zeichen, insbesondere ISO 8859-1, richtig speichern. Die COBOL Programme auf den X86 Anwendungs-Servern werden jedoch mit ISO 8859-15 betrieben, unter anderem, weil dort das Euro-Zeichen vorhanden ist, dafür sind jedoch einige Sonderzeichen, die in Deutschland eigentlich nicht genutzt werden, nicht definiert. Der Datenbank-Client der COBOL Programme meldet sich bei der Datenbank an und nennt "seine" Codepage ISO 8859-15. Deshalb sendet die Datenbank für die UNICODE Zeichen, die nicht in ISO 8859-15 definiert sind, das "Ersatz-Zeichen", ein umgedrehtes Fragezeichen "¿". Die Lösung war, die COBOL Programme, die kritisch sind, mit dem Zeichensatz ISO 8859-1 bei der Datenbank anzumelden. Die Analyse und vor allem den Projektleitern den genauen Sachverhalten für ihre Entscheidungsfindung zu erläutern, war für mich ein gutes Stück Arbeit.

Ein anderes Problem gab es mit einem Umsystem, das Dateien erhält. Auf dem Mainframe sind Dateien mit fester Satzlänge (FB, LRECL) üblich, wobei die Spalten nach dem Ende der Nutzdaten mit Leerzeichen aufgefüllt werden. Auf LINUX System sind sequentielle Dateien mit variabler Länge üblich, hier werden die abschliessenden Leerzeichen nicht in die Datei geschrieben. Das System, welches die Dateien empfängt, läuft zwar auf einem Linux System und erwartet ein CR/LF am Satzende, prüfte aber die Satzlänge. Nach Analyse des Empfangs-Systems habe ich den schreibenden Zugriff von "sequentiell" auf "Record" umgestellt und am Ende des Records CR/LF eingefügt.

Da nicht alle Programme zum gleichen Release nach X86 gingen, waren Datenbank-Spiegelungen notwendig. Ich ermittelte, ob, und wenn ja nach welchen Programm welche Datenbank-Tabelle von Mainframe DB2 nach X86 Oracle, oder auch in der Gegenrichtung, zu spiegeln war. Hieraus wurde eine Steuer-Tabelle für ein Java-Programm erstellt.

Da es im Bereich Datenaufbereitung für das Meldewesen, Datenbank Reporting, einen Engpass an Entwicklern gab, wurde ich in diesen Bereich eingesetzt.

Die Umstellung der bisherigen Sourcen (z/OS. IBM COBOL, DB2, EBCDIC Zeichensatz, Sortierreihenfolge, Timestamp-Format und DB2 Funktionen) af die neue Umgebung (LINUX, Microfocus, Oracle, ASCII / ISO 8859-15, ...) erfolgte auf Basis eines Regelwerkes durch einen Dienstleister.

Meine primäre Aufgabe in der Umstellungsphase war die Analyse der Testläufe auf den Entwicklungssystemen, bei Einzelfällen wurde direkt in der Ziel-Source angepasst, ansonsten wurden Änderungen am Regelwerk veranlasst.

Geändert wurden primär Regeln für die Datenbank Optimierung, zum Beispiel prefetch.

Der Datenbank Präprozessor für MicroFocus COBOL und Oracle Datenbanken ist bei einem sehr alten Stand der Datenbank "stehen geblieben" (Oracle 8?), selbst ANSI SQL wie "left outer join" verstand er nicht. Deshalb wurden solche SQL Statements in Strings ausgelagert und zur Laufzeit als Prepared Statements direkt an die Oracle Datenbank übertragen. Hierbei ergaben sind auch einige Änderungen bei der Verwendung der Host-Variablen.

Typische Einzelfälle war COBOL Code, der nicht ganz dem Standard entsprach oder für den es keinen verbindlichen Standard gibt, aber auf dem Mainframe das gewünschte Ergebnis lieferte. Ein Beispiel war eine Prüfziffern-Berechnung in einem COMPUTE Statement mit Eingabe-Parametern verschiedener nummerischer Datentypen. Auf dem Mainframe wurde intern zuerst alle Parameter in BCD Zahlen (COMP-3) umgewandelt und mit diesen gerechnet, auf X86 / LINUX wird hierfür INTEGER genutzt. War die Prüfziffer "10" wurde auf dem Mainframe nur die "0" betrachtet und in ein Zeichen (x'F0, das EBCDIC Zeichen "0") umgewandelt. Auf X86 wurde die "10" auf das ASCII Zeichen für "0" (x'30) addiert. Das Ergebnis war x'3A, also ein ":". Die Lösung war, nach dem das Problem erkannt wurde, trivial.

Ein nicht triviales Problem waren die Laufzeit-Verschlechterungen bei diversen Batch-Programmen. Entsprechend der für "MVS" vor einigen Jahrzehnten geschaffenen Programmierrichtlinien sind alle Datenbank-Zugriffe in Zugriffsmodulen ausgelagert. Um SQL JOINs zu vermeiden, wird die führende Datenbank-Tabelle in einem Cursor gelesen und abhängige Tabellen per Einzel-SELECT abgefragt. Auf dem Mainframe, wo Anwendungsprogramm und Datenbank auf einer Maschine laufen, kein Problem, auf X86 mit jeweils einen Anwendungs- und einem räumlich getrennten Datenbank-Server ergeben sich durch die Netzwerk-Latenz deutlich längere Laufzeiten. Durch die ständigen Kontext-Wechsel zwischen Hauptprogramm und Zugriffs-Modul sind auch einige Tricks beim Datenbank-Client nicht möglich. Ein Datenbank Administrator meinte zu mir, pro 10 Millionen Einzel-SELECTs eine Stunde mehr an Laufzeit. Die kritischen Programme wurden identifiziert, ein Programm das statt 10 Sekunden nun 10 Minuten in einem "nicht kritischen Pfad" benötigt, wurde nicht angepasst, jedoch ein Programm in kritischen Pfad, dessen Laufzeit von 20 Minuten auf eine Stunde anstiegt, wurde möglichst "schonend" umgestellt, damit weiterhin eine Vergleichbarkeit der z/OS Version gegeben ist. Die "20 Minuten" waren nicht das Ziel, sondern im Rahmen der Batch-Nacht ein Abschluss bis zum Morgen.

Nach den Entwicklertests erfolgte der fachliche Test der Batch-Verarbeitung. Der Kunde nutzt UC4, die Abläufe werden über Templates generiert. Durch den Austausch der "z/OS Templates" durch "LINUX Shell-Script Templates" konnten die meisten Batch-Abläufe schnell umgestellt werden.

Mein Start in das Projekt war die Analyse der Vertriebssteuerung sowie der Provisionssysteme, hier ging es um die Frage, welche Probleme in der seit Jahrzehnten gewachsenen Software bei einer Umstellung auftreten könnten.

Im Rahmen der Umstellungen des Systems für das Adressenrisiko an die neue Vorschriften BCBS 239 ist das bisherige System zu überarbeiten.

Im Rahmen der Umstellung wird die Technik vom Mainframe, also COBOL, JCL, DB2 z/OS auf Linux Systeme mit OSPE-Batch (Spring-Batch) und der Datenbank DB2 BLU Acceleration, also einer In-Memory Datenbank, umgestellt.

Im Vorfeld habe ich das Konzept für die technische Umsetzung erstellt und beispielhaft in einem POC umgesetzt und geprüft.

Im Bereich Spring-Batch habe ich Steps, Tasklets, Chunks auf Basis der Standard-Komponenten erstellt und für spezielle Aufgaben eigene Komponenten erstellt.

Als Beispiele:

Da sehr spezielle Formate für den CSV Export benötigt werden, habe ich einen parametrierbaren RowMapper erstellt, da nur an dieser Stelle die Metadaten der Datenbank zur Verfügung stehen.

Beim JdbcCursorItemReader ist die Verarbeitung von Host-Variablen nicht vorgesehen, eine Text-Ersetzung im SQL Property ist unsicher und kann das Optimieren von SQL Abfragen verhindern. Die Platzhalter ("?") und das manuelle Bereitstellen eines Arrays mit den Variablen in der richtigen Reihenfolge ist bei den geplanten mehrstufigen Common Table Expressions schwer handhabbar. Deshalb habe ich von der Klasse eine eigene Komponente abgeleitet, die wie der JdbcBatchItemWriter Host-Variablen verarbeiten kann.

Der In-Memory Bereich von DB2, also die Column Based Tabellen, ist mit kleinen Ausnahmen (z.B. keine Indizies) syntax-kompatible zu den klassischen Row Based Tabellen, ihre Stärken spielt sie aber erst aus, wenn das Vorgehen beim Datenbank Design und der Abfolge der Statements auf die neue Technik abgestimmt ist.

Hier erarbeitete ich einige Konzept, z.B. SHADOW Tabellen, andere Kombinationen von ROW und COLUMN Based Tabellen, Optimierung des INSERT (HUFFMAN Kompression).

Das Portfolio Management System erhält von vielen Systemen Stammdaten sowie Informationen zu Transaktionen.

Diese Informationen werden aufbereitet dem Kunden-Betreuer für die optimale Beratung seines Kunden sowie den Kunden für eine genaue Auskunft über die Entwicklung ihres Portofolios bereitgestellt.

Das Portfolio Management System besteht neben dem GUI (Windows, Java) und einem Server (AIX, C++) aus einer umfangreichen Host-Anwendungslandschaft, die die Daten der Um-Systeme entgegen nimmt, aufbereitet, verbucht und dem Server bereitstellt.

Um den Anpassungsbedarf gering zu halten, sind die notwendigen Anpassungen in den Eingangsschnittstellen auf dem Host durchzuführen.

Meine Aufgabe ist es, sowohl in dem Team, das die WebServices in Java auf dem Unix System, also auch in dem Team, das die Host Anwendungen betreut, mit zu arbeiten.

Aus diesem Grund sind im Folgenden sehr unterschiedliche Teilprojekte aufgeführt, auch wenn ich Vollzeit bei diesen Kunden für einen Projektleiter tätig war.

Neben den hier aufgeführten Projekten werde ich für Bugfixes eingesetzt.

Für MiFID II sind für die Beratung der Kunden erweiterte gesetzliche Regeln zu beachten. Hierfür sind weitere Informationen über den Kunden sowie die angebotenen Wertpapiere bereitzustellen.

Die Daten sollen in den Abteilungs-Daten-Layer, der für die SAP Anbindung konzipiert wurde, vorgehalten werden. Da mittlerweile viele der damaligen Entwickler die Abteilung verlassen hatte, war meine erste Aufgabe die Zusammenarbeit mit den neu hinzu gekommenen Kollegen.

Die meisten der anlieferten Systeme liefern Notifications und sind per Web Service erreichbar. Somit entspricht die Technik der in 2014 entwickelten Lösung.

Die Wertpapier-Stammdaten werden durch eine zentrale Mainframe Anwendung von WM Daten empfangen, aufbereitet und den verschiedenen Abnehmern bereitgestellt.

Die aufbereiteten Wertpapierdaten sind auch in den Abteilungs-Daten-Layer zu übernehmen.

Die seit mehreren Jahrzehnten laufende Anwendung stellt, wie bei COBOL Anwendungen üblich, Flat-Files mit verschiedenen Satzarten bereit. Einzelne Datensätze können auch per IBM MQ-Series übertragen werden.

Ich konzipierte ein für englischsprachige Java Entwickler verständliches Design zum Einlesen der Daten. Dazu entwickelte ich eine XML Anwendung zur Beschreibung der Host Datenstruktur zum Einlesen in die entsprechenden Java Objekte. Diese werden dann per Hibernate in die Oracle Datenbank geschrieben.

Die Umsetzung des Programms erfolgte Off-Shore.

Die Programme zur Datenversorgung des Abteilungs-Daten-Layer laufen auf verschiedenen Linux Server in einer Tomcat Umgebung. Die Server sind gemanagt, es besteht keine Möglichkeit ausser den WAR Files eigene Software zu installieren. Sie verfügen auch über keinen eigenen Speicherplatz oder Verzeichnisse. In der Regel nutzen sie Datenbanken und dienen als WebServer für Benutzerinteraktionen oder stellend WebServices zur Verfügung.

Um auf in einem Verzeichnis (Inbound) eintreffende Datei reagieren zu können, konzipierte ich eine Batch Steuerung, einschliesslich der notwendigen Anwendung für Administratoren und einem Housekeeping.

Da die Inbound Verzeichnisse können auf verschiedenen File-Servern mit unterschiedlichen File-Systemen liegen können, verwendet das Framework eine Abstraktionsschicht.

Die Umsetzung des Programms erfolgte Off-Shore.

Für die MiFID II Anforderungen liefert WM Daten neue Attribute, insbesondere für PRIIP und KID. Diese Attribute werden untertägig als XML Dateien per SFTP zur Verfügung gestellt.

Die Größe der Daten pro WKN ist übersichtlich, jedoch ist es denkbar, dass eine Datei den Gesamtbestand enthält. Eine XML Datei mit mehreren hundert Megabytes komplett in den Hauptspeicher einzulesen, um das "normale" XML Unmarchalling durchzuführen, kann zu Problemen führen. Aus diesem Grund konzipierte ich ein Design, dass die Datei mittels StAX für jede WKN aufteilt, nur jeweils diesen Bereich mit JAXB in die Java Objekt einliest und per Hibernate in die Oracle Datenbank schreibt.

Das Programm wird auch durch das Batch Framework gesteuert.

Die Umsetzung des Programms erfolgte Off-Shore.

Die Programme für die Kursversorgung wurden Anfang 1990ziger Jahre noch in COBOL ANSI-74 erstellt und seit dem bei Bedarf von verschiedenen Entwicklern schnell erweitert.

Die Auswahl des gewünschten Börsenplatzes und damit des Kurses erfolgt über ein komplexes Regelwert. Hierbei werden die Wertpapier-Stammdaten (WM Daten), verschiedene DB2 Tabellen mit Regeln und weiteren Informationen ausgewertet.

Die Programme waren für geplante fachliche Anpassungen und Erweiterungen zu restruktuieren und hierbei zu dokumentieren.

Die Analyse und Umstellung der Programme geschah noch in 2015, da die Kursversorgung bei der Berechnung der Portfolios entscheidend ist, fand über einen Zeitraum von mehreren Monaten ein Paralleltest statt.

Die Kontokorrent Anwendung lief historisch in verschiedenen Gebiets-Rechenzentren. Im Rahmen der Konsolidierung auf das zentrale Rechenzentrum waren die Schnittstellen zum Portfolio Management System von den bisherigen Rechenzentren auf ein Rechenzentrum zu verlagern.

Hierzu waren OPC (Job Steuerung) Änderungen sowie die Zusammenführung verschiedener Steuerungsinformationen notwendig.

Im Rahmen der Umstellung wurden umfangreiche Tests durchgeführt.

Die auf einer Oracle Datenbank in dem neuen Daten Layer der Abteilung eingespielten SAP Partner Stammdaten sind per SOAP (WebService), REST (JSON und XML im Browser) sowie als Datei zeitgesteuert per SFTP an die Zielsysteme auszuliefern.

Es sind regelmäßige Änderungen der Datenstrukturen zu erwarten, deshalb soll der Programmieraufwand für die Wartung minimiert werden.

Die Lösung besteht aus "Contract-Last" WebServices sowie "Contract-First" Flat-Files für SFTP.

Basis ist eine XSD Datei, generiert aus den Strukturen der Views in der Oracle Datenbank. Die Realisierbarkeit der Lösung ist zu prüfen.

Über ein Tool werden die Strukturen von zehn Oracle Views in einer XSD Datei geschrieben. Beim Build des Projektes mit MAVEN wurde mit dem maven-hyperjaxb3-plugin die entsprechenden Hibernate JAVA Klassen generiert.

Das Interface und die Klasse für die Hibernate-Abfragen mit den Zugriffsbedingungen wurden erstellt. Diese sind nicht von Strukturänderungen in den Views (neue Felder) betroffen.

Ebenso sind das Interface und die Klasse für SOAP sowie der CustomerController, der Request Mapper für REST, nicht von Strukturänderungen betroffen und wurde deshalb erstellt.

Auf die Generierung der Klassen auf Basis einer Business-Anforderungen wurde im PoC verzichtet.

Für die Contract-First Erstellung der Dateien für SFTP wurden Klassen auf Basis der generierten Hibernate Klassen erstellt und mit fixedformat4j Annotationen angereicht.

Als Klebstoff zwischen den Klassen setzte ich Spring ein, ebenso für verschiedenen Dependency Injections um z.B. die Parameter für den Datenbank Connection oder den JSCH SFTP Client an den Service zu übergeben.

Für den MAVEN Build erstellte ich verschiedene JUNIT Testklassen, über die auch in Eclipse ausführbar sind.

Ich testete den Service mit SOAPUI, im Browser und per FTP auf meiner lokalen Tomcat Installation und deployte dann das WAR File auf einem UAT Web-Server.

Die Eingangsschnittstelle von Kontokorrent, also den Gegenkonto für die Wertpapier-Transaktionen im Portfolio, wurde vor vielen Jahren entwickelt und durch verschiedene Entwickler immer wieder an die geänderten Erfordernisse, Jahr 2000, Euro, Abgeltungssteuer, ... angepasst.

Damit die Bewertung eines Portfolios nicht durch eventuell unterschiedliche Buchungstage der Wertpapier-Handelssysteme und des Kontokorrent Systems beeinträchtigt wird, werden schon bei der Verbuchung von Wertpapier-Transaktionen die zu erwartenden Kontokorrent Transaktion vermerkt. Diese müssen beim Verbuchen der Transaktionen aus Kontokorrent gematcht werden.

Enthaltende Steuern und Gebühren müssen aufgeteilt werden, um später den Wert des Portfolios darstellen zu können.

Da Kontokorrent eines der ersten Systeme war, das auf SAP DM umgestellt werden sollte, war die Dokumentation durch eine genaue Analyse der vorhandenen Programme zu prüfen.

Die Bank wird zentral mit WM-Stammdaten sowie mit Daten für "Futures and Options" versorgt. Das Portfolio Management bereitet auf der Produktions-Instanz diese Daten für sich und andere Systeme auf und speichert sie in eigenen DB2 Tabellen.

Um die identischen Daten auch in den Test- und Entwicklungs-Systemen zur Verfügung zu haben, habe ich zwei COBOL Programme entwickelt.

Das eine Programm liest in Produktion für eine WKN / ISIN und eine Zeitspanne die Daten aus den DB2 Tabellen und speichert sie in einer sequentiellen Daten. Diese Datei wird dann vom Operating auf das Test System kopiert und mittels des zweiten von mir entwickelten COBOL Programms in die dortigen DB2 Tabellen geschrieben.

Die Stammdaten für Partner, also Portfolio Inhaber, Bevollmächtigte und auch Kundenbetreuer wurden von einer Host-Anwendung bereit gestellt. Im Rahmen der Vorbereitung einer Migration werden diese Daten in ein SAP System gespiegelt.

Die gespiegelten Daten werden via WebServices bereitgestellt und in einer Oracle Datenbank auf einem Unix System gespeichert.

Der Inhalt der Oracle Datenbank ist mit dem Datenbestand in der z/OS DB2 Datenbank, die über die bisherige Schnittstelle versorgt wird, zu vergleichen.

Ich entwickelte eine Java-Anwendung, die beiden Datenbanken liest, Feldinhalt bei Bedarf nach Regeln des Fachbereichs aufbereitet, Differenzen ermittelt und entweder als Excel-Sheet oder in einer eigenen Datenbank dem Fachbereich zur Kontrolle zur Verfügung stellt.

Sehr viele Banken setzen neben den bankfachlichen Lösungen meines Kunden, die dem Anwender über ein Portal zur Verfügung gestellt werden, auch ein angepasstes SAP HR (PARISplus) für die Mitarbeiterbetreuung ein.

Um den Mitarbeitern einen direkten Zugriff auf die Daten des HR Systems in dem ihnen vertrauten Portal zu ermöglichen, wurde eine Anbindung entwickelt.

Ein direkter Zugriff aus dem Portal auf die SAP Systeme schied aus Performance-Gründen aus, so dass in der bankfachlichen Anwendungslandschaft ein Daten-Cache eingerichtet wurde, auf den das Portal zugreifen kann.

Die Anlieferung der Daten aus dem SAP HR steuert das SAP System und verwendet hierzu WebServices, die von OSPlus bereitgestellt werden.

Ich konzipierte den Daten-Cache (DB2) sowie der Anbindung der WebServices an das SAP System.

Zu meinen Aufgaben gehörte auch die Konzeption, Realisierung und das Testen der OSPlus Prozesse in COBOL zur Datenlieferung aus dem Daten-Cache an das Portal.

Mein Kunde entwickelte Host-Anwendungen über 20 Jahren mit IBM VAGen und den Vorgänger-Sprachen. Im Laufe der Jahren sind so über 18.000 produktive Programme und etwa 100.000 Module entstanden.

IBM hat VAGen aus der Wartung genommen.

Deshalb beschloss die Versicherung, künftig die Weiterentwicklung in der Standard Programmiersprache COBOL durchzuführen.

Die bestehenden Programme und Module wurden mittels eines am Markt erhältlichen Konverters von VAGen nach COBOL umzustellen. Der Konverter war an die Notwendigkeit der vorhandenen Softwarelandschaft anzupassen. Hierzu bildete in der IT-Tochter der Versicherung ein Projektteam aus erfahrenen COBOL und VAGen Entwicklern, das die Vorgaben erstellt und die Umsetzung validiert. Ein Teil meiner Aufgaben in dem Projektteam war die Unterstützung bei der Validierung.

Primär wurde ich jedoch für die Konzeption und Entwicklung von Tools in Java eingesetzt.

Der Konverter-Prozess benötigt neben den VAGen Sourcen viele weitere Informationen, die ich mit Tools aus der bisherigen Softwarelandschaft zu gewinnen hatte.

Bedingt durch die hohe Anzahl an Modulen bedurfte es eines automatischen Konvertierungsprozess, der auch den Import in die neue Entwicklungsumgebung IBM RDZ (Eclipse basierende Entwicklungsumgebung für Host-Programme) beinhaltet. Im Rahmen dieses Prozesses sind verschiedene formale und auch inhaltliche Prüfungen am COBOL Code notwendig.

Wenn mehrere hundert Anwendungsentwicklern über 20 Jahre eine Anwendungslandschaft erstellen, ist diese sehr heterogen. Die produktiven Programme beinhalten den Stand der Module zur Zeit der Generierung. Die Module im Laufe der Jahren weiterentwickelt, wobei nicht immer eine Generierung aller betroffener Programme erfolgt ist. Um hier Fallstricke zu erkennen wurden mit von mir entwickelten Tools die vorhandenen Modul Sourcen geparst und verschiedene Reports zur Qualitätssicherung erstellt.

Eine Umstellung aller Sparten in einem "Big-Bang" ist nicht möglich, somit hatte ich Sperr-Mechanismen, insbesondere in der bisherigen VAGen Entwicklungsumgebung (basiert auf "IBM VisualAge for Java"), zu implementieren.

Für einen neuen Veranstalter in der Schweiz ist die Schweizer Umsatzsteuer auszuweisen. Für die Veranstalter in anderen Länder war im SAP FI eine Differenzbesteuerung (Margen-Besteuerung) vorhanden. Für die Schweiz musste eine Umsatz- und Vorsteuerberechnung inkl. Schnittstelle an SAP in das Online-Buchungssystem des Konzerns eingebaut werden.

Zusammen mit dem Fachbereich in den Niederlanden und Belgien erstellte ich das Fachkonzept. Hieraus leitete ich das DV-Konzept in Abstimmung mit den IT-Kollegen in Deutschland ab und realisierte die notwendigen Änderungen im Online-Buchungssystem. In Abstimmung mit den Kollegen aus dem SAP Bereich führte ich die Tests durch.

Ich war Vollzeit bei dem IT Dienstleister unter Vertrag und wurde in verschiedenen Bereichen eingesetzt. Die Projekt in diesem Zeitraum fanden ausschließlich bei diesem Kunden statt.

Das Rechenzentrum, für das ich tätig war, übernahm die Dienstleistung für eine weitere Bank.

Da diese Bank schon WP2 nutzte, waren die Schnittstellen und Dialogprogramme für deren Parametrisierung in WP2 anzupassen.

Weiterhin unterstützte ich die Migration der Daten.

Ich übernahm geplant von Aufgaben von aus dem Projekt ausgeschiedenen Kollegen.

Während der Einführungsphase schied der bisherigen "Teamleader Entwickler" krankheitsbedingt sehr kurzfristig aus. Ich wurde mit seinen Aufgaben betraut und war in der Stabilisierungsphase der technischer Ansprechpartner.

Aus Basis der Erfahrungen aus der Stabilisierungphase entwickelte ich die Schnittstelle von Bank21 an WP2 weiter.

Nach dem eigentlichen Projektende war ich als Coach der internen Kollegen tätig.

Modellierung und Realisierung einer Swing Anwendung auf Basis Bank21 im Rahmen des Bereiches Kunden-Verwaltung.

Im Rahmen der Umstellung des Wertpapierverfahren von WVS auf WP2 waren diverse Schnittstellen und Dialog-Anwendungen anzupassen.

Hierbei wurde auch die Systemumgebung von einer klassischen Mainframe Umgebung auf eine Umgebung bestehend aus klassischen Mainframe für die Backend Systeme sowie Java für die Frontends umgestellt.

Die Anwendung wurde im RSA designed, mittels Generatoren Java Klassen sowie Cobol Sourcen für die Frameworks erzeugt. Die generierten Programme rief handcodierte Unterprogramme mit den fachlichen Funktionen auf.

Das Team bestand aus Java- oder Host-Spezialisten. Die Modellierung für die Backend Systeme erfolgt durch die Java Spezialisten im RSA, die Umsetzung dann durch die Mainframe Spezialisten in COBOL.

Ich startete als Objekt-Modellierer, übernahm dann immer stärker Aufgaben im Bereich Host-Entwicklung. Weiterhin war ich für die JUnit-Tests zuständig, da ich auf der Java Seite die Tests anpassen und bei Bedarf die Bugfixes auf dem Host durchführen konnte.

Die verschiedenen Produktlinie eines Softwareherstellers verwenden, schon bedingt durch verschiedenen Plattformen, auf denen sie entwickelt wurden, verschiedene Methoden zum Ausdruck. In Zukunft soll eine Plattform zum Drucken genutzt werden.

Meine erste Aufgabe war es, verschiedene Report- und Druck-Generatoren auf ihre Einsatzfähigkeit, insbesondere während der Übergangsphase, zu untersuchen.

Nach dem Entscheidung für BIRT gefallen war, hatte ich ein Print-Framework (Querschnittsfunktion), Style-Sheets und die Entwickler- sowie Benutzer-Dokumentation zu erstellen

Das Print-Framework besteht aus verschiedenen von mir entwickleten Eclipse Plug-ins zur Datenbeschaffung (ODA mit dynamischer Übernahme von Änderungen in Eclipse), für den BIRT Report-Designer, einer iText Anwendung zur Nachbearbeitung und dem Einfügen von statischen Content sowie verschiedenen Laufzeitumgebungen für Applictions (Fat-Client) sowie J2EE Server.

Im Rahmen der Umstellung des Dialog Systems von einer 3270 Anwendung auf eine regelbasierende Java Client / Server Anwendung waren auch mehrere über Jahrzehnte gewachsene Druckprogramm, erstellt in DELTA, an die neue Umgebung anzupassen. Meine Aufgabe war die Analyse dieser Programme und das Erarbeiten eines Vorschlages, ob die Programme oder die Datenanlieferung umzustellen ist.

Das bestehende Bilanz-Rating System einer grossen deutschen Bank wurde um die Komponente zur Vorhersage der Unternehmensentwicklung erweitert.

Hierbei werden auch Unternehmenszusammenschlüsse berücksichtigt.

Meine Aufgabe war die Entwicklung des Rechenkerns sowie die Erweiterung der Datenbanken.

Übernahme der Wartung eines in Java unter WebSphere laufenden Anwendungssystem von einem Team in Indien.

Neben den Java Klassen war es insbesondere meine Aufgabe, die Funktion von COBOL CICS und Batch Host-Modulen zur Anbindung an auf dem Host laufende Anwendungen (Partner, Berechtigungen, ...) sowie der DB2 auf dem Host sicherzustellen.

Das bestehende und seit Jahren bei einer Grossbank im Einsatz befindliche System wurde grundsätzlich umstrukturiert. Hierzu war eine Migration der DB2 Tabellen auf dem Host notwendig.

Um einen Rollout der Clients über einen Zeitraum von mehreren Wochen zu ermöglichen, wurde die Migration als "Delta-Migration" ausgelegt.

Anpassung verschiedener Swing Dialoge.

Die bestehende Anwendung für die Bilanz-Analyse, die bei mehreren Grossbanken im Einsatz ist, war um eine WebService Schnittstelle zu erweitern. Über diese Schnittstelle greifen andere Systeme lesend und schreibend auf den Datenbestand der Software zu.

Das Frontend für Reisebüros bündelt die verschiedenen IT-Verfahren der Reiseveranstalter, Fluggesellschaften, KFZ-Vermieter, etc. unter einer Bediener-Oberfläche.

Die Einbindung der Host-Anwendungen in das GUI wurde in Java erstellt, dessen Weiterentwicklung ich nach dem Ausscheiden eines Mitarbeiters kurzfristig übernahm. Das GUI besteht primär aus DHTML, JavaScript, CSS.

Meine Erfahrungen beider Welten (Mainframe und browser basierendes GUI) kamen mir als "Vermittler" zwischen den Welten sehr zugute.

Die Baufinanzierungs-Software des Marktführers Elaxy ist um einen Workflow zu erweitern, der eine Fall-abschließende Bearbeitung für einen Kredit durch den Außendienst ermöglicht.

Ich war Vollzeit bei der Bank unter Vertrag und wurde in verschiedenen Bereichen eingesetzt. Die Projekt in diesem Zeitraum fanden ausschließlich bei diesem Kunden statt.

Auf den Gesamtbestand an Kundendaten, der im Data-Warehouse vorhanden ist, müssen verschiedene Alt-Systeme unter BS2000 zugreifen.

Da kein direkter Zugriff von BS2000 auf eine DB2 unter Unix möglich ist, werden die Daten aus dem DB2 entladen, per File Transfer auf den BS2000 Host geschickt und dort mittels eines COBOL Programms eingelesen.

Um die Datenbankzugriffe auf BS2000 zu minimieren, wurde ein Delta-Verfahren eingesetzt. Die Daten sind, entsprechend der Vorgaben aus dem Projekt near Realtime Anbindung, zu transformieren.

Im Vorfeld untersuchte ich einige Alternativen, die einen direkten Zugriff von BS2000 auf die Unix DB2 ermöglichten, u.a.

Diese Alternativen wurden aus Kostengründen verworfen.

Zwei interne Kollegen, erfahrene BS2000 Host-Entwickler, wurden von mir in den verwendeten Techniken der "Near Realtime" Anbindung, also Java, XML, WebSphere eingearbeitet und die Betreuung der unternehmenskritischen Anwendung schrittweise übertragen.

Obwohl ich mittlerweile in einem unternehmenskritischen EAI Projekt eingebunden war, wurde ich gebeten, die Kollegen aus "meinem alten" Team Bilanzierung des Wertpapier-Eigenhandels (Nostro und Nostro-D) sowie Eigen-Emissionen zu unterstützen. Mit den Kollegen, die aus ihrer täglichen Praxis sehr vertraut mit der Bilanzierung nach HGB und dem sehr ähnlichen Steuerrecht sind, habe ich die grundsätzlichen Unterschiede zwischen einer HGB-Bilanzierung (Gläubigerschutz) und einer US-GAAP, IAS bzw. IFRS Bilanzierung (Information der Anleger) diskutiert und hierbei auf die Unterschiede der Bewertung (Gleitender Durchschnitt gegen Fair Value), Latente Steuern, Wegfall des "Maßgeblichkeit Prinzip" und weiteren Punkten. Wichtig war das Ausarbeiten der unterschiedlichen Bedeutungen sehr ähnlich klingender deutscher und englischer Begriffe. Ziel war es, die Kollegen mit ausreichend Hintergrundwissen für fachliche Diskussionen zur die Belieferung des SAP-Systems, das die IFRS-Bewertung durchführen wird, durch die von ihnen betreuten Systeme, die die HGB-Bewertung durchführen, auszustatten.

Mittels einer browser basierenden HTML Anwendung ist der Druck der Jahresbescheinigungen für Kunden anzustoßen. Hierzu wurde ein Servlet entwickelt, das per JDBC auf die vorhandene SESAM-Datenbank zugreift. Den internen Kollegen, einen erfahrenden Host-Entwickler, unterstützte ich bei der Konzeption, Realisierung und Bereitstellung der erforderlichen Infrastruktur.

Coaching eines internen Mitarbeiter bezüglich Portal-Architektur und Anbindung von Legacy-Anwendungen (BS2000) an das Portal. Gemeinsam wurden die Vorteile eines Portals nach JSR-168 sowie Szenarien zur Anbindung der bestehenden BS2000 Anwendungen erarbeitet.

Im Rahmen des Outsourcing auf einen IT-Dienstleisters wird auch der juristische Bestand des Kundeninformationssystems (KIS) ausgelagert. Da wichtige Anwendungen erst mittelfristig ausgelagert werden, diese einen Zugriff auf das KIS benötigen, eine Umstellung der Zugriffe auf das KIS des IT-Dienstleisters sehr aufwendig wäre, wurde die Anbindung des vorhandenen KIS an den juristischen KIS Bestand beschlossen.

Der IT-Dienstleister nutzt für das KIS eine IMS-Umgebung unter z/OS und stellt eine XML-Schnittstelle als MQ-Series Stream zur Verfügung. Das KIS der Bank läuft auf SESAM unter BS2000.

Die Lösung wurde in JAVA auf dem z/OS Rechner der Bank implementiert. Als Entwicklungsumgebung führte ich Eclipse ein. Ein MQ-Event triggert die Verarbeitung an, der XML-Stream wird geparst, die zugehörigen Objekte per JDBC aus der SESAM Datenbank unter BS2000 gelesen, die Daten des XML-Streams eingefügt und per JDBC in die SESAM Datenbank zurückgeschrieben.

Hierbei sind diverse Datenfelder zu transformieren oder abzuleiten, so dass ich in der Designphase eine genaue Analyse der unter BS2000 vorhandenen COBOL, Columbus-COBOL und Assembler Programme durchführte.

Die abnehmenden Systeme (Kredit, Wertpapiergeschäft sowie Termingeld) sind unternehmenskritisch und auf eine aktuellen Datenbestand angewiesen. Aus diesem Grund sind Stabilität, Robustheit sowie die Möglichkeit, schnell und sicher Anpassungen an neue Anforderungen zu implementieren, wichtige Anforderungen an die Lösung.

Als "Reißleine", falls die benötigte Infrastruktur nicht zur Verfügung steht, habe ich eine reine BS2000 Lösung konzipiert. Der XML Stream wird von MQ gespeichert und per File Transfer auf den BS2000 Host gebracht. Dort wird das XML Format mittels eines in COBOL geschrieben Parser (entsprechende Tools, die unter z/OS zur Verfügung stehen, standen unter BS2000 nicht zur Verfügung) in eine Datei mit festen Satzstrukturen umgeformt. Dieses Datei dient dem im COBOL mit ESQL entwickelten Update-Programm als Eingabe.

Wartung einer seit über 20 Jahren gewachsenen Anwendungslandschaft für das Wertpapier-Geschäft einer großen Bank mit den Schwerpunkten Eigenhandel und Privatkunden.

Hierbei betreute ich folgende Bereiche:

Neben der Wartung wurde in folgenden Bereichen weiterentwickelt:

Das vom Hersteller nicht mehr weiter entwickelte DB2 Tool CA-ProEdit war bei einer Versicherungsgruppe zu ersetzen. Das Tool wurde über einen Zeitraum von zumindest 10 Jahren durch Endanwendern in den Fachabteilungen, den Anwendungsentwicklern sowie den Datenbank-Administratoren eingesetzt, so dass bei der Auswahl die unterschiedlichen Anforderungen und Gewohnheiten zu berücksichtigt waren.

Für einige durch Systemprogrammierer und Datendank-Administratoren betreute Funktionsbereiche ist das Tool CA-Platinum im Einsatz, für andere Aufgaben war ein Nachfolge-Produkt zu finden.

In von mir vorbereiteten und durchgeführten Workshops wurden folgende Produkte betrachtet:

Auf Basis der in den Workshops gewonnenen Erkenntnisse wurde gemeinsam eine Investitionsempfehlung ausgesprochen.

Ich untersuchte die Auswirkungen des kommenden Ratings nach Basel II für einen mittelständischen konkreten Industriebetrieb, und spielte verschiedene Modelle, u.a. Bilanzerstellung nach US-GAAP, durch, wie die steuerlich motivierte Externe Darstellung modifiziert werden kann. Die Ergebnisse stellte ich der Geschäftsführung in einem Workshop vor.

Mit einigen Kollegen, die größtenteils schon bei der Technologie-Studie von 1996 bis 2000 zu diesem Thema mitwirkten, wurde der Unterschied zwischen dem Java Ansatz von Sun (und IBM) gegenüber dem [Dot] .NET Ansatz von Microsoft untersucht und kritisch diskutiert.

Im Rahmen der Untersuchung wurden gemeinsam verschiedene Testinstallationen von Servern durchgeführt (JBoss, WebSphere, TomCat, MS .NET Server) sowie jeweils eine kleine Anwendung implementiert. Im Rahmen der Untersuchungen der EJB-Container wurde, soweit verfügbar, erstmals auch Message Driven Beans sowie die Local-Interfaces genutzt und ihre Vorteile gegenüber der Nutzung von Entity Beans auf Clients untersucht.

Hierbei wurden auch mit Asynchronen Transaktionsmonitoren, z.B. IBM MQ-Serie gearbeitet, um das Performance Verhalten im Vergleich Entity Bean, Message Driven Bean und der "herkömmlichen" Technik beurteilen zu können.

Im Rahmen der Implementierungen nutzten wir verschiedene Entwicklungsumgebungen (IDE), wobei die Änderungen im Angebot deutlich wurden. Insbesondere bei Eclipse und der kommerziellen Erweiterung IBM WSAD untersuchten wir einige Erweiterungen auch in Richtung WebSphere.

In Zusammenarbeit mit Kollegen, die im Bereich CMS seit Jahren tätig sind, wurde deren Technologie-Träger um Workflow Komponenten und Konnektoren für Bestands- und Verwaltungssysteme erweitert.

Ich war Vollzeit bei der Versicherung unter Vertrag und wurde in verschiedenen Bereichen eingesetzt. Die Projekt in diesem Zeitraum fanden ausschließlich bei diesem Kunden statt.

Vorbereitung der Migration der Partner (*) bezogenen Stammdaten des bisherigen Provision und Vertreter Informationsystems. Hierzu war eine enge Zusammenarbeit mit den Mitarbeitern des bisherigen und des künftigen Provisionssystems notwendig. Die neue Provisionsanwendung verwendet im Gegensatz zur bisherigen Lösung die von mir betreuten Zentralanwendungen Partner-System und Zentralnachweise für Datenbeschaffung, -haltung sowie das Exkasso. An den notwendigen Funktionalen Erweiterungen wirkte ich mit.

Als der Kunden verstärkt auf eigene Mitarbeiter setzte, wurde ich im Rahmen einer Vertragsverlängerung gebeten, interne Mitarbeiter, die bisher die alte Provisionsanwendung betreuten, einzuarbeiten und sie für die Durchführung der Migration zu schulen.

(*) Partner sind im IAA bzw. GAA Modell Kunden, Vertreter, Banken, Rückversicherer, Geschädigte, ...

Durchführung der Migration von ca. 4,5 Millionen Schadensfällen mit Partnern, Adressen, Fernmelde Adressen, Bankverbindungen, Exkasso-Nachweisen sowie weiterer Daten ohne merkliche Beeinflussung der normalen Online- und Batch-Aktivitäten über einen Zeitraum von mehreren Wochen.

Während des Migrationszeitraumes konnte im Alt-System weiter normal gearbeitet werden. Mittels Tools zur Delta-Bildung konnten die veränderten Daten in mehreren Schüben nachmigriert werden, so dass das Alt-System an einem Freitag Abend abgeschaltet wurde, am Sonnabend morgen die abschließenden Tests des neuen Systems stattfanden und am Montag die Anwender im neuen System ihre am Freitag Abend eingegebenen Daten wiederfanden.

Insbesondere die Bearbeitung laufender Schäden, auch des Exkassos, war während des Migrationszeitraumes sicher zu stellen. Hierzu fertige ich genaue Analysen der Zusammenarbeit der Schaden- und Exkasso-Systeme an.

Erstellung und Umsetzung eines grundsätzlichen Konzeptes zur maschinellen Übernahme von Adress-, Vertrags- und sonstigen Daten aus Fremdsystemen in den vorhandenen Datenbestand unter Wahrung der Datenqualität durch Einsatz von Modulen aus der Online-Umgebung.

In Hinblick auf einen geplanten 24/7 Betrieb ist der Prozess so ausgelegt, dass eine Verarbeitung zeitgleich zum Online-Betrieb möglich ist.

Um das gegenüber einer Migration mittels Lade-Utilities etwas schlechtere Laufzeitverhalten auszugleichen, wurden Tools geschaffen, die eine sanfte Migration ermöglichen, während im Alt-System normal weiter gearbeitet werden kann sowie bei Bedarf schon im Neu-System mit der Bearbeitung begonnen werden kann.

Mitarbeit beim Konzept von Datenübernahmen in nicht produktiven Systemen (Schulung und Test) unter Wahrung der Verknüpfungen auch zu anderen DV-Systemen.

Übernahme der Anwendung nach Ausscheiden des Kollegen, Durchführung der ersten "produktiven" Läufe, Erweiterung um die Kategorie "Schaden-Daten", Übergabe der Anwendung an den Fachbereich, Einarbeitung von internen Kollegen.

Beratung des Fachbereiches bei der Erstellung eines durch die Arbeitsvorbereitung gesteuerten Prozesses sowie die Anbindung anderer Bestandssysteme.

Konsolidierung des Partner-Bestandes, insbesondere die technische Abbildung Partner, Rolle, Vereinbarung sowie Partner, Rolle, Bankverbindung

Feststellen von Daten-Inkonsistenzen in sehr großen Datenbeständen durch SQL, Auswertungen auf Entladebeständen und anderen Hilfsmitteln.

In Abstimmung mit dem Fachbereich ermitteln der Fehlerursachen sowie deren Beseitigung veranlassen.

Beseitigen der vorhandenen Inkonsistenzen mittels SQL oder Korrekturprogrammen.

Weiterentwicklung des Verfahrens zur Umsetzung des Bundesbank-Änderungsdienstes sowie Massenänderungen von Bankverbindungen.

Konzeption einer Migration auf Basis von Ladebeständen

Begleitende Beratung der für dieses Projekt angeforderten Mitarbeitern.

Troubleshooting während der Migrationsdurchführung, z.B. Datenbank Korrekturen

Coaching von Kollegen bei der Umstellung der Dialog-Oberflächen auf JAVA-Applikationen.

Mitarbeit bei der Zusammenfassung von UniServ Komponenten (UniPost, UniMail, UniWagnis).

Verfahren zum Anonymisieren von Adressen unter Beibehaltung der versicherungsrelevanten Informationen.

Mitarbeit bei der Erstellung bzw. Umstellung von Systemkomponenten im Rahmen der Einführung einer mandantenfähigen Lösung.

Analyse, Design und Implementierung der Migration des Datenbestand von mehreren Versicherungsunternehmen im Rahmen der Einführung einer mandantenfähigen Lösung auf mehrere Bestände.

Die Korrektheit und Vollständigkeit der Migration war gegenüber den beteiligten Unternehmen zu beweisen.

Auf Grund des Zeitplanes der Migration am Pfingstwochenende stand für die Migration von über 100.000.000 Datensätzen nur ein Zeitfenster von Freitag Abend 20:00 bis Samstag morgen 07:00 zur Verfügung. Diese Vorgabe wurde mittels hoch optimierter, parallel laufender Prozesse mit einer Sicherheitsreserve von 2 Stunden gehalten.

Definition des Prozesses sowie Umsetzung der Migration der Akquise Daten des selbständigen Außendienstes, ca. 3.000 Vertriebseinheiten, aus zwei Altsystemen (BTX sowie lokalen PCs mit VADIS) in eine zentrale Host-Umgebung.

Bei einer Hypothekenbank Konzeption und Realisierung betriebswirtschaftlicher Auswertungen, primär in den Bereichen Interne Zinsrechnung und Risiko-Bewertung, in der Abfragesprache SIRON.

Ich war Vollzeit bei dem Consulting Konzern unter Vertrag und wurde in verschiedenen Bereichen eingesetzt. Die Projekt in diesem Zeitraum fanden ausschließlich bei diesem Kunden statt.

Für einen großen internationalen Consulting-Konzern Projektarbeit bei einem deutschen Telekommunikations-Konzern im Rahmen der Umstellung auf eine neue EDV Lösung zur Kundenbetreuung.

Konzeption und Design von Werkzeugen zur Qualitätssicherung der Stammdatenübernahme sowie Listen und Dateien für diverse Schreiben an Kunden auf dem Mainframe.

Übergabe der Ergebnisse an MS-Office Front-Ends auf PCs.

Konzeption und Design von Werkzeugen zur Kontrolle von speziellen Migrationsbeständen.

Aufbau des Data Warehouse für die Qualitätssicherung mit Oracle 8 unter Windows NT mit PL/SQL als weitere Schicht zwischen dem Mainframe und den MS-Office Front-Ends im Rahmen der Migration bei einem deutschen Telekommunikations-Konzern.

Im Rahmen der Migration bei einem deutschen Telekommunikations-Konzern war eine konzernweite, tagesaktuelle Information der Mitarbeiter sicherzustellen. Nach der Erstellung des Konzeptes Beratung bei der Realisierung.

Für einen großen internationalen Consulting-Konzern Projektarbeit bei einer deutschen Großbank im Bereich Fehlerberichtigungen und funktionale Erweiterung einer Lösung für Bilanzierung des Wertpapier-Eigenhandels.

Wichtige Punkte in diesem Projekt waren:

Fehlerberichtigungen in den Staffelmodulen (gleitender Durchschnittspreis nach HGB)

Erstellen der Staffelmodule zur Ermittlung der Historischen Anschaffungskosten

Korrekturen beim Abgleich zu MUREX

Implementieren der Schnittstellen Xetra.

Ich war von einem großen internationalen Consulting-Konzern für die Einführungsphase von Xetra eingeplant. Im Vorfeld habe ich mich mittels zur Verfügung stellten Unterlagen mit Xetra vertraut gemacht. Da mein Können in Projekt "Bilanzierung des Wertpapier-Eigenhandels" benötigt wurde, bat man mich kurzfristig, dieses Projekt zu übernehmen.

Redesign zwecks Umstellung auf Multi-User Betrieb einer seit Mitte der achtziger Jahre gewachsenen Softwarelösung für ein Reihenuntersuchungslabor, inklusive der Abrechnung nach GOÄ, Untersuchungsvorbereitung sowie der Befundung.

In Zusammenarbeit mit mehreren Kollegen wurde im Bereich Objektorientierte Analyse und Objektorientiertes Design mit UNIFIED MODELING LANGUAGE (UML) sowie der Entwicklungssprache JAVA mit deren Komponentenmodellen JAVA-BEANS und ENTERPRISE JAVA-BEANS verschiedene Szenarien der künftigen Software-Entwicklung erprobt. Zielrichtung ist, künftig mit objektorientierten, plattformunabhängigen Frameworks zu entwickeln.

Von Dezember 1992 bis Anfang 1997 habe ich (fast) ausschließlich mit einer Unternehmensberatung aus München zusammengearbeitet. Im Auftrag des Unternehmens habe ich bei verschiedenen Kunden mobile CRM-Systeme entwickelt und eingeführt. Ab Anfang 1997 bis Mitte 2001 habe ich dann die Wartung bei den Kunden übernommen.

Das Softwarehaus, für das ich die Aussendienststeuerungen entwickelte, ist primär im Bereich Korboda tätig. Um personelle Engpässe zu beseitigen sowie für mich eine Grundauslastung sicher zu stellen, wurden mir kleinere Projekte bei der Weiterentwicklung und Wartung von Kordoba zugewiesen.

Als Werkstudent habe ich über einen Zeitraum von mehreren Jahren und in Zusammenarbeit mit wechselnden Kollegen (festangestellte Mitarbeiter und Werkstudenten) die Schnittstelle der SILINE-200 Bereiche Einkauf, Produktion und Vertrieb auf die relationale Datenbank SESAM unter BS2000 entwickelt, getestet und bei einem Pilotkunden installiert.

Notwendig waren die Analyse der von SILINE-200 abzuspeichernden Attribute sowie der Zugriffspfade (Primär- und Sekundärschlüssel), Definition des Datenmodells für die relationale Datenbank SESAM, Erstellung der Schnittstellen Software und Test der Schnittstelle durch Definition von Geschäftsprozessen

Planung, Erstellung und Wartung eines Warenwirtschaftssystems für mittelständische Industriebetriebe der Nahrungsmittelindustrie mit Schnittstellen zu vorhandener Standardsoftware.