• In diesem Projekt geht es um die Entwicklung eines Bots, der aufgrund von Marktdaten logische Entscheidungen trifft, die in Gewinnen am Kapitalmarkt resultiert. Damit ist das Ziel dieses Programms, automatisierte Handlungen am Kapitalmarkt in Anhängigkeit von Trading-Indikatoren durchzuführen. Dabei soll der Bot validiert werden und anhand von Aktien-Strategien ein Sicherheitsnetz gebildet werden
• Dieser Bot wird zusammen mit einem hochkarätigen C# Senior DevOps entwickelt. Dabei bauen wir den Bot in Microservices mit einem Kafka Event-Bus auf

• In diesem Projekt war es das Ziel, einerseits die Zollanbindung zu erweitern und andererseits das Team auf einen hohen Wissensstand bezüglich der Arbeit mit React zu bringen
• Dabei ist es uns gelungen, zusammen das Wissen im React Typescript und Java Backend-Bereich auf einem sehr hohen Niveau zu erweitern. Dazu haben wir ein Backend mit Clean Code aufgebaut, welches einen Fokus auf möglichst wenig Abhängigkeiten gelegt hat
• Wir haben in sechs Monaten eine Transformation des Backend mit Kapselung zu Altcode erreicht, was einen spürbaren Mehrwert im Team dargestellt hat
• Dazu kommt, dass das Format des Codes so verbessert wurde, dass die Arbeit mit dem Code laut eigenen Angaben nicht mehr zeitintensiver Einarbeitung bedarf, sodass der Code selbst von den Azubis verstanden und erklärt werden konnte
• Weiterhin hatten die Teammitglieder eigenen Berichten zufolge ihre Arbeitsweise optimieren können: Sie wurden produktiver und halten sich nun an gängige Standards
• Ich habe in einem sehr pragmatischen Team gearbeitet, welches sich im SCRUM-Umfeld viele gute Dinge angeeignet und mich mit ihren Methoden inspiriert hat. Ich mochte besonders ihren Fokus auf Wertschätzung und Motivation im Arbeitsumfeld
• Ich wurde übergangsweise als Architekt und Teamlead für das Team beschäftigt und habe mich im Umgang mit den Teammitgliedern stehts auf Augenhöhe gefühlt. Ich konnte mich hier mit sehr erfahrenen Entwicklern über unternehmensübergreifende Entscheidungen im Restful-Umfeld austauschen und meine bisherigen, softwaretechnischen Erfahrungen und Kenntnisse sehr gut einbringen

In diesem Projekt ging es um die Anbindung von ELANK2. Ich habe als Externer mit sechs weiteren in einem SCRUM-Team gearbeitet.

Das Projektziel war es, ELANK2 anzubinden. Es gab eine monolithische Architektur. Ich habe die sogenannte erweitert und dafür das interne Framework genutzt. Des Weiteren habe ich die Entwickler, die für einen Nachbau einzelner Komponenten auf zuständig waren, beraten und bei ihrer Arbeit unterstützt. 

• Als teilselbständiger Software-Entwickler arbeitete ich an einer Webanwendung
• Das Backend wurde mit Java 17, Spring Boot implementiert
• Im Backend ging es darum, eine Urlaubsbuchung-API zu bedienen, die mit SOAP zur Verfügung gestellt wurde
• Dafür wurde aus der WSDL Source-Code generiert, der die API ansprechen soll
• Das Backend wurde an eine Datenbank per JPA angebunden und stellte dem Frontend per REST den Zugriff zur Verfügung
• Diese Applikation setzte für mich den Fokus darauf, dass ich die Applikation problemlos übergeben konnte
• Die Prozesse wurden den zwei Geschäftsführerinnen erläutert und deren Kenntnisse in den Prozessen wurden aufgebaut und fachlich gestärkt
• Das Frontend wurde mit Flutter realisiert und sollte sowohl per App als auch im Browser verfügbar sein
• Die Software-Entwicklung wurde von mir allein abgearbeitet

• In diesem Projekt ging es um die Anbindung von ELANK2. Ich habe als Externer mit sechs weiteren in einem SCRUM-Team gearbeitet
• Das Projektziel war es, ELANK2 anzubinden. Es gab eine monolithische Architektur. Ich habe die sogenannte Swing-GUI erweitert und dafür das interne Framework genutzt. Des Weiteren habe ich die Entwickler, die für einen Nachbau einzelner Komponenten auf React zuständig waren, beraten und bei ihrer Arbeit unterstützt

In diesem Projekt ging es um das hausinterne Colibri-System. Mit dem System der Bundesagentur für Arbeit wurde das Arbeitslosengeld ermittelt und angeordnet. Ich habe als Externer mit sieben weiteren in einem SCRUM-Team gearbeitet

• Projektziel war von C++ auf Java EE 7 zu migrieren. Die bestehende monolithische Architektur wurde auf eine dezentrale, serviceorientierte Architektur umgebaut
• Unsere Microservices waren wie folgt strukturiert: WAR-Deployments auf Weblogic mit Rest basierten Endpoints
• Es ging oft darum, bei Schnittstellenaufrufen an neue Komponenten diese in die Konfiguration einzubinden, damit diese bei der CI/CD Pipeline berücksichtigt werden konnten. Das hat es erlaubt, während der Jenkins Builds Teil-Deployments durchzuführen, damit die API-Tests Komponenten übergreifend durchlaufen können. Es wurde ein sehr strenges Testkonzept genutzt und es sollte eine 100 %ige Testabdeckung erfolgen. Die Tests waren in Unit, Komponenten und API-Tests aufgeteilt
• Es wurden verschiedenste Anforderungen zu REST-Endpoints bearbeitet
• In der Anforderungsanalyse wurde der PO von uns Softwareentwicklern unterstützt. In diesem Projekt war es eine große Herausforderung für das Team vor allem die fachlichen Anforderungen zu ermitteln
• Da das Team keinen Tester hatte, lag es an uns Softwareentwicklern das strenge Testkonzept einzuhalten und die fachliche Dokumentation zu übernehmen
• Der DevOps des Teams hat einen gesucht, der ihn bei der Tätigkeit vertreten konnte. Seitdem war ich dann regelmäßig bei den DevOps-Meetings dabei und habe mich mit ihm ausgetauscht
• Für regelmäßige Releases wurden Liquibase-Skripte und eine hausinterne, eigene Lösung zur Datenpflege erstellt
• Einmal die Woche mussten lokale Deployments mit Docker-Compose durchgeführt werden. Die wurden auf eine lokale WebLogic-Umgebung durchgeführt. Da es bei der Softwareversorgung vom UHD zu Problemen für das lokale Deployment kommen konnte, musste das lokale Deployment ab und an repariert werden

• Die Rhenus Freight Network ist der hauseigene IT-Dienstleister für ihre eigene Logistik-Infrastruktur
• Als Software-Entwickler habe ich hier in einem SCRUM-Umfeld gearbeitet, welches ein Team von neun Personen umfasste. Dazu hatten wir sehr engen Kontakt zu einem externen Team von drei Leuten, mit denen wir Hand in Hand an unserer Komponente gearbeitet haben. Des Weiteren waren wir nur ein Team (Team ROAD) von vielen, die zusammen an dem gesamten TMS gearbeitet haben. Dabei hat jeder an seinen Komponenten gearbeitet, mit gelegentlicher Unterstützung der anderen Teams
• Diese TMS-Software wurde in ganz Europa auf selbst gehosteten Servern und in Asien sowie Amerika in der Amazon Cloud hinter einem Okta-Zugang betrieben. Ich habe die Software mitbetreut, gewartet, deployt und an den CI/CD Pipelines mitgearbeitet. Zu dem TMS gab es auch eine große Zahl an Schnittstellen und Verbindungsstücken zwischen den Schnittstellen. Das Altsystem, ursprünglich auf PL/ SQL basierende Software als Monolithen, wurde auf neue Software-Standards migriert mit Verbindungsstück zum restlichen alten System in Microservices.  Durch die sehr hohe Nutzerzahl wurde in diesem Projekt viel Wert auf Performance, Skalierbarkeit und Qualität gelegt. Das TMS wurde zu Eclipse Scout 7 (als Web-Anwendung), Java Spring und Spring Boot migriert. Dabei war der Fokus auf Spring Boot. Ich bereicherte das Projekt durch die Einführung von JUnit-Tests. Auch bei der Evaluierung neuer Technologien und der Planung von Services unterstützte ich den Product Owner im Tagesgeschäft
• Besonders spannend empfand ich hier die Architektur, die Entwicklungsprozesse und die Qualitätssicherungsmaßnahmen des Projekts. Letztere betrafen vor allem die strengen Coding Guidelines & Review-Prozesse im Rahmen von SCRUM
• Es wurde mir über einen längeren Zeitraum ein Student anvertraut, dem ich als Mentor zur effizienten Mitarbeit im Projekt verholfen habe
• Ich unterstützte den Software-Architekten bei der Erarbeitung von Dokumentationen nach ARC42. Ich habe Dokumentationen zu Prozessen und Schnittstellen angefertigt, um eine Analyse im Fehlerfall zu garantieren und mit aufbereiteten Informationen das Problem zu lösen oder an das zuständige Fachteam weiterzuleiten. Regelmäßig wurde ich von den DevOps-Teams um Unterstützung gebeten und habe teamübergreifend fachliche Kenntnisse eingebracht und mir angeeignet. Die Tätigkeiten der DevOps habe ich immer als sehr spannend und vielseitig empfunden und deswegen sehr gerne gemacht
• Bei der Abtrennung der Datenbank zu den externen Dienstleistern haben wir auf RDBCs (ROCS Database Connectoren) gesetzt. RDBCs waren mit Apache Camel und Spring Boot implementiert
• Wir haben sowohl TMS als auch RDBCs per CI/CD deployet und Qualitätsmaßnahmen wie Sonar genutzt
• Dabei war es eine besondere Herausforderung, Prozesse zu schreiben, die weltweit nutzbar sind und sich an die gesetzlichen Regelungen des Landes anpassen lassen, ohne die Code-Komplexität zu erhöhen
• Für den laufenden Betrieb haben wir unsere Komponenten gemonitort und die Logs ausgewertet. Um unsere Komponenten stetig zu verbessern, haben wir nach einer Analyse der Ursache, der Dringlichkeit und des Nutzens Ausschläge vom Monitoring oder Fehlermeldungen von Logs in Tickets bearbeitet

• Die PSI Logistics GmbH war ein IT-Dienstleister für Logistik Kunden von BHS (Baggage Handling System), BRS (Baggage Reconciliation System) und TMS. Ich war im Bereich Airport tätig
• Ich war sowohl an einem Netzwerkproxy (und anderen Projekten) als auch an dem Support der Endnutzer beteiligt
• Beim Netzwerkproxy habe ich allein für einen technischen Projektleiter gearbeitet. Für den Support der Nutzer des BRS habe ich in einem Team von fünf Leuten zuzüglich der Softwareentwickler anderer Teams gearbeitet
• Im Rahmen dieser Tätigkeit habe ich an einen intelligenten Netzwerkproxy gearbeitet. Nach Anforderung eines technischen Projektleiters entwickelte ich diesen Proxy vom Prototyp zum vollwertigen Netzwerkproxy mit Caching. Der Netzwerkproxy wurde mit Java passgenau als Adapter für das System für den Airport von mir geschrieben und fungierte als Hilfsmittel zur Verarbeitung von IATA-Nachrichten. IATA-Nachrichten sind sicherheitsrelevante Daten, die eine hohe Performance erfordern, da diese Nachrichten in Echtzeit ausgewertet werden und das Ziel der Gepäckstücke bestimmen
• Der Verwaltung und Betreuung des Linux- und Windows-Servers habe ich mich ebenso angenommen
• Neben der Anfragenbearbeitung und Kundenkommunikation gehörten dabei auch die Erarbeitung von Lösungen für die unterschiedlichsten Problemfälle im BRS- und BHS-Bereich zu meinen Aufgaben. Dazu kommt, dass ich in der Kommunikation mit externen Dienstleistern stehts Lösungen für aufkommende Probleme gefunden habe, mit der sie immer sehr zufrieden waren
• Ich habe zahlreiche Prozesse dokumentiert und Anleitungen für Prozesse geschrieben, die dann von weniger IT versierten Mitarbeitern verstanden und umgesetzt wurden
• Sämtliche Problemfälle, die in Nachtschichten vorkommen können, habe ich mit Hilfe von proaktiven Interviews mit Teams so dokumentiert, dass es sogar mit geringen Vorkenntnissen möglich war, einen Systemausfall des BHS und BRS schnell zu beheben. So konnte mittels der Dokumentation eine Analyse von externen Schnittstellen bewerkstelligt werden und die externen Dienstleister mit aufbereiteten Daten informiert werden
• Im Support war es stets wichtig sich ein genaues Bild über die Lage zu machen, wenn es richtig zeitkritisch war. So mussten Logs zuverlässig und präzise analysiert werden und es musste ein Überblick über die externen Abhängigkeiten geschaffen werden
• Wir haben alle unsere Systeme gemonitort, ausgewertet und Wert-Entwicklungen der Last analysiert. So konnten wir präventiv Speicherprobleme und Schnittstellenprobleme lösen

• GFH Datensystem GmbH war zuständig für Schnittstellen Softwareentwicklung und war ein IT-Dienstleister
• In dieser Firma war es meine Hauptaufgabe an der hauseigenen Buchungssoftware der Autovermietung (Buchbinder später Europcar) zu arbeiten
• Ich habe zunächst in einem Team von neun Softwareentwicklern, zwei davon Teamleads, gearbeitet
• Dort wurden Aufgaben verteilt, wie sie gerade anfielen
• Später bekam ich die Chance, als Technischer Leiter eine neue Software für das Unternehmen zu entwickeln, die das Kassensystem für einen neuen Kunden darstellte
• Ich habe als Mentor mit einem neuen Mitarbeiter gearbeitet
• In der Struktur habe ich tägliche Absprachen über die Aufgabenverteilung und den Fortschritt dieser Aufgaben mit ihm geführt
• Zu meinen Kerntätigkeiten gehörte es, mir Wissen zu spezifischen Themengebieten anzueignen, dieses Wissen aufzuarbeiten und mit den Mitarbeitern zu teilen
• Ich dokumentierte sowohl Entscheidungen für die Software und die Art und Weise der Wartung, des Deployments und die Schnittstellen für das Produkt