• Lexoffice bietet seinen Kunden eine Buchhaltungssoftware als Webapplikation an. Diese wird auf Amazon AWS betrieben und basiert auf einer Microservice-Architektur. 
• Die einzelnen Microservices verwenden Spring-Boot und werden in Produktion via Ansible und Terraform deployt. Für die lokale Entwicklung und auf Testinstanzen werden Docker-Container verwendet. 
• Im Rahmen des Projekts habe ich Features im Bereich der Belegerkennung und -verarbeitung umgesetzt und Bugs behoben. Hierbei habe ich sowohl im Backend als auch im Frontend alle Aufgaben übernommen. Unter anderem habe ich die Belegerfassung von Angular auf React migriert. 
• Nach diesen Aufgaben im Bereich der Belegerfassung wechselte ich in einen anderen Bereich und bin die Neuimplementierung und die architekturelle Konzeption des Buchhaltungskerns angegangen. In diesem Zusammenhang wurde auch eine Strategie zur Migration des Legacy Codes während des Betriebs erarbeitet werden.
• Weiterhin habe das Team zu wichtigen Architekturfragen beraten, um die automatisierte Testbarkeit (Unit-Testbarkeit) zu erhöhen. In diesem Zusammenhang habe ich neue Features auf Basis der Clean Architecture und der hexagonalen Architektur unter Anwendung der SOLID-Prinzipien umgesetzt. 
• Außerdem habe ich mich um die Ausbildung neuer Kollegen durch Coaching und Par-Programming gekümmert. 

• Für meinen Kunden aus der Automotive Branche habe ich die Weiterentwicklung eines Systems für die Verwaltung von Daten-schutzerklärungen durchgeführt. Das System ist für alle europäischen Märkte zuständig und muss deshalb mandantenfähig sein soll.
• Die Komplexität des Systems entsteht hauptsächlich durch die rechtliche Komplexität die Datenschutzerklärungen enthalten. D.h. wenn ein Kunde in unterschiedlichen Ländern unterschiedliche Datenschutzerklärungen abgegeben hat, muss aus der Sicht eines jeweiligen Marktes bzw. Landes eine konsolidierte Sicht nach den juristischen Regeln des Zielmarktes erfolgen. Hierzu ist eine Kommunikation zwischen den Systemen notwendig. Gleichzeitig sollen die Systeme so wenig wie möglich gekoppelt sein.
• Ich war hauptsächlich für die Implementierung der sogenannten Routing-Komponente eingesetzt, welche zwischen den Systemen vermittelt und die konsolidierte Sicht auf die Datenschutzerklärungen erstellt.

• Im Dezember 2019 hatte ich mich nach erfolgreichem Projekt zuvor dazu entschlossen eine kurze Auszeit von ca. 2 Monaten zu nehmen und in dieser Zeit die Entwicklung meines Datenbank-Analyse Tools Datanect voranzutreiben. Ziel diese Tools ist es mich und andere bei der Analyse von Daten auf einem Datenbanksystem zu unterstützen. 
•  Datanect basiert auf Ecipse RCP und ist nach den SOLID Prinzipien und der Clean Architecture von Robert C. Martin aufgebaut. Die Eclipse-RCP Anwendung wird mittels Maven-Tycho gebaut und selbstverständlich Unit getestet. 
•  Leider kam dann im Februar 2020 die Corona-Pandemie, weshalb Projektzusagen wieder zurückgezogen wurden. Dadurch war ich gezwungen noch ein paar Monate mehr zu überbrücken. Ich habe diese Zeit als Trainingszeit genutzt und mich weitergebildet in den Bereichen Kafka, Docker, Gitlab und CI Pipelines. 
• Außerdem habe ich zur Weiterbildung noch die Bücher ?Java Application Architecture?, ?Clean Agile?, ?Langlebige Software Architekturen? und ?Object-oriented Software Construction? gelesen, sowie Youtube Videos zum Thema SOLID Prinzipien und Clean Architecture erstellt und veröffentlicht.  

• Der Kunde verfügte bereits über ein Text-Outputmanagement-System (TOM), dass seit Jahren im Konzern entwickelt wurde.
• Das System beinhaltet leider massive technische Schulden. Diese waren auch der Hauptgrund warum ich hinzugezogen wurde.
• Meine Aufgabe bestand anfangs darin eine vom Kunden vorgefertigte technische Schuldenliste abzuarbeiten um den Legacy Code Schritt für Schritt zu verbessern.
• Diese Schuldenliste war aber nur eine Ansammlung von Code-Findings. Eine klare Strategie bzw. einen roter Faden war nicht zu erkennen.
• Deshalb erarbeitete ich selbst eine Roadmap, welche notwendigen Schritte aufzeigt und auch die Begründungen liefert warum diese Schritte in dieser Reihenfolge wichtig und sinnvoll sind. Diese neue Roadamp habe ich mit dem Projektmanagement und Product-Owner abgestimmt und konnte sowohl den Projektmanager als auch den Product-Owner davon überzeugen, dass der von mir aufgezeigte Weg zu einer besseren Architektur führen wird.
• Nachdem ich die ersten Schritte eingeleitet hatte, wurden die Auswirkungen nach und nach sichtbar, wodurch das Vertrauen in mich weitergewachsen ist.
• Deshalb wurde mir auch die Weiterentwicklung des Entwickler-teams beim Kunden durch Pair-Programming, Trainings, Coaching, etc. übertragen.
• Zum Ende des Projekts arbeitete ich an der Architekturumstellung, um zum einen die Technologieabhängigkeiten aus dem Business-Code zu entfernen und dien Business-Code dadurch testbarer zu machen. Meine Empfehlung war das System auf eine hexagonale Architektur umzustellen, da es sich durch eine große Anzahl an Schnittstellen zu Umsystemen auszeichnete. Nach der Rücksprache mit dem firmeninternen Architekten wurde letztendlich das BCE (boundary controller entity) Muster aus-gewählt.

• Die Abrechnung von Krankentransporten musste in ein bereits bestehendes Softwaresystem migriert werden. Bei dem Zielsoftwaresystem handelt es sich um ein generisches Abrechnungssystem das von der Krankenkasse selbst entwickelt wurde um verschiedenste Abrechnungsarten zu unterstützen. 
• Ich war im Backend Bereich für die Verarbeitungen der Rechnungslieferungen zuständig. Die Eingangsrechnungsdateien beinhalteten auch Rechnungen die vorerst nicht in das Zielsystem eingespielt werden sollten. Hierzu musste ein geeigneter Parser und Router implementiert werden. 
• Das Abrechnungssystem arbeitet eng mit dem Archivierungssystem für Rechnungsdaten zusammen, dass von mir bereits 2 Jahre zuvor für die Krankenkasse entwickelt wurde. 
• Aus diesem Grund habe ich auch das Team bzgl. der Schnittstellen und Architektur des Archivierungssystems beraten und auch selbst Integrationen implementiert. 
• Weiterhin war ich Coach für die Themen Java, JEE, Git, Test-Driven-Development und Build-Prozesse tätig.

• Für die Mitarbeiter der Telefonzentrale einer Krankenkasse wurde ein veraltetes Beauskunftungssystem neu implementiert. Der Hauptgrund für die Neuimplementierung war die schlechte Performance des Altsystems und die verminderte Wartbarkeit des Legacy Codes. Die Performance war für die Mitarbeiter der Telefonzentrale besonders wichtig, da diese enge Zeitvorgaben für das bearbeiten eines Kundenkontakts haben. Aufgrund der Wartbarkeitsdefizite konnten die Performance Probleme nur schwer gelöst werden. 
• Obwohl die Use-Cases prinzipiell die gleichen blieben, gab es deshalb dennoch eine große Herausforderung im Performance-Bereich. Die Vorgabe war, dass jede Abfrage schneller sein musste als die des Altsystems. 
• Mit einer geeigneten Architektur, an der ich maßgeblich beteiligt war, konnten wir die Wartbarkeit erheblich verbessern. Dies ermöglichte uns die Performance-Erwartungen um ein Vielfaches übertreffen, weil wir leicht verschiedene Teile der Anwendung austauschen konnten und so verschiedene Ansätze ausprobieren. Als Basis haben wir die hexagonale Architektur genommen und nur sehr leicht modifiziert. Suchanfragen im Altsystem die zwischen 30 und 60 Sekunden dauerten konnten wir auf 3 bis unter 1 Sekunde reduzieren. 
• Weiterhin musste im Gegensatz zum Altsystem auch die geografische Suche unterstützt werden D.h. es mussten Leistungserbringer für Hilfsmittel in einer Region ermittelt werden können. Diese mussten nach Entfernung zu einer beliebigen Adresse sortierbar sein. 
• Außerdem haben wir noch Features wie z.B. die Autovervollständigung der Suchleiste eingebaut, welche die Mitarbeiter der Telefonzentrale deutlich unterstützten. 

• In diesem Projekt habe ich für eine Krankenversicherung ein Ablagesystem für Arzt-Rechnungen entwickelt. 
• Dieses System verarbeitet EDIFACT ähnliche Dateien um die darin enthaltenen Rechnungen von Ärzten zu verarbeiten. Die Arzt-Rechnungen werden in einer DB2 Datenbank abgelegt, für die Suche indiziert und an andere Systeme zur weiteren Verarbeitung weitergeleitet. 
• Eine Krankenversicherung erhält Rechnungen zu verschiedenen fachlichen Verfahren, z.B. Zahnärzte, allgemein Ärzte, alternative Behandlungsmethoden, etc. 
• Eine Anforderung an das System war, dass unterschiedliche Fachverfahren unterstützt werden müssen und weitere Fachverfahren später angebunden werden können. 
• Hierzu habe ich ein Plug-In Framework in Form von SPIs (Service Provider Interfaces) entwickelt (ähnlich der Adapter einer hexagonalen Architektur) um den Legacy Code wartbarer zu machen. Die Plugin Architektur erlaubt das Erweitern der Ablage um folgende Module: 
  • Parsen von EDIFACT (auch verschiedene Versionen) 
  • Erkennung und Behandlung von Korrektur-Nachrichten 
  • Indizierung für die Suche 
  • Weiterverarbeitung bzw. Integration in anderen Systemen 
• Eine weitere Herausforderung in diesem Projekt war die große Datenmenge. Jede zu verarbeitende Datei kann mehrere GB groß sein und Millionen Rechnungen enthalten. Da es bei der Verarbeitung von Rechnungen auch enge Zeitgrenzen gibt wurde auch das Thema Performance in besonderem Maße beachtet. 

• Das Flottenmanagementsystem xFleet bietet Unternehmen eine Verwaltungsplattform für Dienstwagen. 
• Kern des Projekteinsatzes war die Erstellung eines Konzepts wie das System, welches bis dato nur den deutschen Markt bedienen konnte, für den internationalen Markt fähig zu machen. Hierzu wurde ein Code- und Architektur-Review durchgeführt. 
• Das finale Konzept zeigt einen Weg auf wie der Legacy Code des Systems in ein Modulares System überführt werden kann, ohne Weiterentwicklungen und Wartungsarbeiten am bestehenden System zu behindern und gleichzeitig die Softwarequalität während der Umbauphase gewahrt bleibt. 
• Weiterhin musste die komplette Entwicklungsumgebung vom Kunden zum Dienstleister, für den ich arbeitete, umgezogen und auf den aktuellen Stand der Technik gebracht werden. 
• Dies beinhaltete im Wesentlichen: 
  • SVN Migration nach GIT
  • Aufsetzen von Gerrit Code-Review
  • Build-Server Jenkins aufsetzen und in Code-Review Prozess einbinden.
  • Umzug der Datenbanken
  • Schulung der anderen Teamkollegen (GIT, Gerrit)
• Darüber hinaus habe ich DevOps Aufgaben ausgeführt um den Betrieb und die Wartung der Entwicklungsumgebung zu gewährleisten.
  

• In diesem Projekt unterstützte ich das Architektenteam des Kunden bei der Softwarearchitektur von Teilsystemen und führ-te Performanceanalysen und -auswertungen durch. 

• Im Rahmen eines Projekts wurde eine Software für das Lead-Management und zur Finanzierung von Fahrzeugen eines Au-tomobileherstellers entwickelt.
• Ziel der Entwicklung war unter anderem einen modularen Work-flow zu schaffen an den unterschiedliche Endsysteme angedockt werden können um die Rollout-Geschwindigkeit in neue Märkte zu steigern. 

• Für die Versicherungsbereiche Sach, Kranken und Leben soll ein gemeinsames CRM System geschaffen werden, dass den jeweiligen Maklerbetreuern eine Steuerung ihrer Makler ermöglicht. 
• Hierzu müssen Courtage- und Außenstanddaten der jeweiligen Makler auf Strukturmerkmalen aggregiert und über Dashboards dargestellt werden.
• Weiterhin soll eine technische Unterstützung für Jahresgespräche vorhanden sein, welche die vereinbarten Ziele der Makler mit ihren tatsächlichen Umsätzen vergleicht.

• Um die Arbeit der Versicherungsmakler zu erleichtern und ihnen schnellen Zugang zu den wichtigsten Daten und Systemen zu ermöglichen wurde eine Bestandsmanagement Applikation konzipiert und entwickelt. Kern der Entwicklung ist ein Portlet, dass es Maklern ermöglich ihre Bestände zu verwalten und Reports zu erstellen. 
• Eine Herausforderung bestand darin den sehr großen Datenbestand, von mehr als 20 Millionen Datensätzen, tagesaktuell zu aggregieren. 

Die bestehende Portal-Anwendung basiert auf Java 1.4 und IBM Web Sphere Portal Server 5. Die zugrundeliegende Hard- und Software muss ersetzt werden um die Anwendung zukunftssicher zu machen.

• Koordination von Abteilungen zur Abstimmung von Schnittstellen
• Anforderungsanalyse für neue Portlets
• Architektur, Design und Umsetzung neuer Portlets
• Migration der bestehenden Anwendung auf neuen Technologie Stack.
• Regressionstests & Testautomatisierung
• Technische Dokumentation

Die bestehende Anwendung zeigt deutliche Schwächen im Bezug das Einarbeiten neuer Entwickler und die Implementierung neuer Features. Dadurch wird die Entwicklungsgeschwindigkeit deutlich reduziert. In weiten Teilen ist die Altanwendung prozedural und nicht objektorientiert programmiert. Die komplexe Geschäftslogik ist hauptsächlich nach dem EAA Pattern Transaction Script organisiert. Wir haben das System in ein objekt-orientierteres umgewandelt um so die Komplexität der Geschäftslogik zu beherrschen.

• Aufnahme der Anforderungen an die Architektur
• Erstellung eines Prototypen anhand von einigen ausgewählten Geschäftsprozessen
• Technische Dokumentation

Das Online-Stadtportal dient einerseits als Informationsplattform für das Rathaus, andererseits als umfangreiches Online-Branchenbuch. Das Projekt umfasst sowohl das Internet-Portal mit umfangreichen Suchfunktionen, als auch die redaktionellen Applikationen und Benutzeroberflächen (Redaktionssysteme), über die die Inhalte für das Internet-Portal eingestellt werden. 

• Abstimmung von Anforderungen und Schnittstellen
• Technische Team-Leitung
• Technische Architektur
• Technisches Design
• Software-Entwicklung
• Qualitätssicherung
• Technische Dokumentation

Konzeption und Umsetzung eines Frameworks zum Import von Patentanmeldungen (weltweit) basierend auf OSGI mit Hilfe einer DSL (domain specific language).

Das europäische Patentamt muss Patentanmeldungen von über 150 Patentämtern weltweit für Recherchezwecke importieren.

Die Patentanmeldungen werden von den Patentämtern in unterschiedlichen Formaten (XML, RTF, Plain Text, etc.),  Paketierungen (tar, gz, zip, etc.) und Übertragungsprotokollen (scp, sftp, https, etc.) zur Verfügung gestellt. Für fast jedes Patentamt muss ein eigener Importprozess beschrieben werden. Um diese Importprozesse schneller Implementieren zu können wurde eine DSL entwickelt. Jeder Importprozess kann über die DSL leicht auf Standardfunktionalität (z.B. splitten und mergen von Dateien, entpacken, etc.) zugreifen. Durch die Wiederverwendung auf DSL Ebene kann eine schnelle Implementierung bzw. Anpassung eines Importprozesses gewährleistet werden. Die DSL wurde in Groovy implementiert.

Um die Usability und Produktivität zu erhöhen wurde ein Importprozess-Designer auf Basis von Eclipse RCP aufgebaut. Dieser beinhaltet im wesentlichen Autovervollständigung der DSL, Syntax Highlighting, Testen und Paketierung der Importprozesse.

Die Ausführung der Importprozesse wurde über eine Laufzeitumgebung auf OSGI Basis durchgeführt.