Eine Plattform, die seit 2016 durchgehend im Betrieb ist und in dieser Zeit zweimal die Architektur gewechselt hat, ohne Ausfall. Sie begann als Desktopanwendung auf .NET Framework. In der zweiten Generation kam ein eigenes Backend auf ASP.NET Core dazu, gegen das zunächst der Desktop-Client und später ein React-Frontend liefen ? beide gleichzeitig, damit der Betrieb während der Ablösung weiterlaufen konnte. Heute ist es eine Serverless-Plattform auf AWS mit reinem React-Frontend, die Fachlogik in Lambda-Funktionen, die im Leerlauf auf null skalieren. Der Altbestand läuft weiter, bis die Ablösung abgenommen ist; der Betrieb der Schwimmschule stand in zehn Jahren keinen Tag still.
Fachlich deckt sie den ganzen Betrieb ab: Kursplanung, Teilnehmer, Anwesenheit und Abrechnung. Geschnitten ist sie auf die Arbeitssituation am Becken ? das Eincheckpersonal arbeitet am Tablet, die Trainer haken die Anwesenheit am Handy ab und geben ihr Feedback direkt dort, statt es später von Zetteln abzutippen. Das Feedback lässt sich auch einsprechen: Ein Dienst nimmt die Rückmeldung per Spracherkennung auf und wertet sie über ein Sprachmodell aus.
Stack: .NET Framework/WPF ? .NET 8 ? TypeScript, React 19 · AWS CDK, Lambda · Payload CMS, Astro · Progressive Web App · Whisper, OpenAI
Die PC-Software des In-vitro-Diagnostiksystems EntericBio in einem Schritt von .NET Framework 4.8 auf .NET 10 gehoben, ohne Zwischenstufe ? eine Software, die ich 2018 beim selben Hersteller als Projektleiter und Architekt aufgesetzt habe.
Maßgabe war, dass der laufende Laborbetrieb nicht gestört wird: Die neue Fassung musste abwärtskompatibel zur freigegebenen Vorversion bleiben, damit alles, was mit der Altversion erzeugt wurde, weiter läuft. Der Funktionsumfang blieb deshalb bewusst unverändert; die Änderungen betrafen ausschließlich die technische Grundlage.
Neu aufgesetzt wurden dagegen die Strecken drumherum: Build- und CI/CD-Pipelines, die den Windows-Desktop-Build in Docker-Containern unter Windows reproduzierbar machen, sowie der Signaturprozess. Die Inhalte der Delta-Dokumentation ? alle Abweichungen von der freigegebenen Basisversion ? habe ich erstellt und dem Zulassungsinhaber zur Abnahme übergeben, der sie führt. Migration abgeschlossen 06/2026. Beauftragt als Werkleistung zum Festpreis mit drei Zahlungsmeilensteinen ? Projektstart, Abschluss der Migration, erfolgreicher Test und Auslieferung.
Stack: .NET 10, WPF, DevExpress, SQLite · Windows-Docker-Build, Code-Signing, PDF-Signaturen · CI/CD
Bestimmend war die Migration des Fertigungsframeworks von .NET Framework 4.8 auf .NET 10 ? der Software, mit der sämtliche Geräte des Herstellers in der Fertigung montiert und geprüft werden. Den Dependency-Injection-Container neu aufgesetzt, den Code nach Clean-Code-Prinzipien in Domäne, Anwendung und Infrastruktur neu geschnitten, Unit- und Integrationstests ergänzt.
Daneben die Windows-Steuersoftware epBlue der epMotion-Pipettierroboter auf .NET 10 angehoben ? eine seit 2012 gewachsene C#-Codebasis, aus der mehrere Produktvarianten entstehen ? und die UI-Testautomatisierung wieder in Gang gebracht: die gewachsene Testsuite auf TestStack.White instand gesetzt und erweitert, sodass die Oberfläche automatisiert gegen die Anwendung geprüft wird. Dazu der Wissenstransfer an das Team des Kunden ? Firmware wie Steuersoftware ? als eigenes, beauftragtes Arbeitspaket.
Stack: .NET 10, WPF · ASP.NET Core, GraphQL (HotChocolate), EF Core 10 · TestStack.White, MSTest/SpecFlow · GitLab CI, SonarQube
Der Kunde hatte Vorstellungen, aber kein Lastenheft. Ich habe daraus funktionale Anforderungen geschnitten, sie mit ihm priorisiert und umgesetzt ? bis zum Produktivbetrieb vergingen drei Monate.
Es ist eine Quiz-Plattform für Lizenznehmer an 17 Standorten: Ein zentrales Team gestaltet Bilder- und Audio-Quizze, die Lizenznehmer nutzen sie ? Mandantenfähigkeit steckt deshalb im Datenmodell. Ausgegeben wird gedruckt, als A4-Quizbuch mit einem QR-Code pro Frage. Daraus folgt die tragende Bedingung: Ein gedruckter QR-Code muss für immer auflösen. Ein Heft, das seit einem Jahr im Umlauf ist, darf nicht ins Leere zeigen, weil die Vorlage inzwischen überarbeitet wurde. Eine Layout-Änderung erzeugt deshalb eine neue Version unter neuer Kennung, während Textkorrekturen und Übersetzungen die bestehende ändern. Das prägt die gesamte Architektur.
Gebaut auf AWS mit Scale-to-zero und ohne Datenbank-Grundgebühr: im Leerlauf kostet die Plattform wenige Euro im Monat, unter Last ist der Betrieb auf einen kleinen zweistelligen Betrag ausgelegt. Die Domänenlogik liegt als eigenes Paket ohne Cloud-Abhängigkeit vor und ist mit Property-based Tests abgesichert.
Stack: TypeScript durchgängig · AWS CDK, Lambda, DynamoDB, Cognito, SQS, CloudFront · fast-check, Playwright
Ein Projektmanagement-Tool für das Dienstleistungsgeschäft des Kunden. Erfasste Zeiten werden zu Rechnungen und Gutschriften ? mit allem, was daran fachlich hängt: Steuerberechnung, Skonto und Storno, XRechnung als elektronisches Rechnungsformat, Stundenzettel als PDF mit dynamischem Seitenumbruch, Preise und Rabattprofile je Kunde. Dazu die Projekt- und Zeiterfassung selbst, mehrsprachig und zeitzonenfest.
Angebot, Aufwandsschätzung und Zeitplan habe ich verantwortet, den Entwurf des Systems gemacht und dafür ein verteiltes Team aus sechs Personen aufgebaut und fachlich geführt ? Projektsprache durchgehend Englisch. Mit dem Kunden arbeitete ich nach Scrum mit wöchentlichen Reviews, im Team liefen Dailys und Wochensprints, jeder Merge Request ging über ein Review.
Technisch entstand eine Landschaft aus zehn Backend-Services mit GraphQL-Federation über ein Fusion-Gateway, ereignisgetriebener Kommunikation über einen Message Broker und Single Sign-on über Keycloak. Wo die Änderungshistorie fachlich gebraucht wird, liegt Event Sourcing darunter ? im Rechnungswesen und in der Benutzerverwaltung, damit jede Korrektur nachvollziehbar bleibt. Backend und DevOps habe ich selbst umgesetzt, das Frontend entstand in React. Version 1 läuft seit 12/2025 im Produktivbetrieb.
Stack: .NET 10, HotChocolate Fusion, EF Core, PostgreSQL, RabbitMQ, Keycloak-SSO · React 19, TypeScript · Docker, Dagger, Playwright
Aufgabe war eine Geräte-API, über die Drittsysteme die Pipettierroboter fernsteuern: Bestückung verwalten, Operationen ausführen, Gerätezustand abfragen. Dafür musste alles, was bis dahin als Prozesssteuerung in der Firmware lag, in die API wandern ? der Kunde wollte die Logik aus dem Gerät herausholen und die Firmware nur noch ausführen lassen. Viele Logikbausteine wurden aus C++ herausgenommen und in C# neu implementiert. Der eigentliche Aufwand steckte dabei im Lesen und Verstehen des gewachsenen Firmware-Codes und im Nachweis, dass sich die neue Umsetzung exakt wie die alte Prozesssteuerung verhält.
Der fachliche Kern war die Kollisionsvermeidung: Der Roboterarm bewegt sich im dreidimensionalen Arbeitsraum, ohne die Proben zu berühren ? gelöst über eine A-Suche im Raum. Weil die Wegfindung im Takt der Maschine antworten muss, ist sie auf Laufzeit optimiert: Heap-Allokationen im heißen Pfad konsequent vermieden, Laufzeitverhalten mit BenchmarkDotNet gemessen. Auch in C# lässt sich speichernah arbeiten, wenn man es von Anfang an so anlegt. Entwickelt und geprüft an einem eigens gebauten Simulator mit 3D-Visualisierung.
Stack: .NET 8, ASP.NET Core, MediatR/CQRS · C++ auf der Firmware-Seite · xUnit, BenchmarkDotNet · OpenGL/Avalonia · GitHub Actions
Zwei Stränge in dieser Phase.
Auf der Firmware-Seite lief die Verbindung zwischen Gerät und Außenwelt bis dahin als offene Remote-Procedure-Verbindung; dafür habe ich einen abgesicherten Kommunikationskanal über TLS entworfen und als lauffähigen C++-Prototyp umgesetzt, mit Token- und Session-Verwaltung ? eingebettet in eine Cyber-Security-Risikoanalyse der Gerätesoftware, erstellt gemeinsam mit einem Qualitätsingenieur. Dazu die Modernisierung des CMake-Projekts und der Schnitt des monolithischen Teils in eigenständige Module, über Interfaces voneinander getrennt ? seither lässt sich modulweise testen statt nur im Ganzen.
Parallel begann der Neubau des Fertigungsframeworks, mit dem die Geräte montiert und geprüft werden: eine .NET-Anwendung mit plugin-basierten Montagesequenzen, geschnitten in Domäne, Anwendung und Infrastruktur, mit GraphQL-Schnittstelle und WPF-Oberfläche. Abgeschlossen wurde sie 2026 auf .NET 10.
Stack: C++20, CMake, Yocto, Drogon, OpenSSL/TLS · Catch2, Trompeloeil · .NET 8, HotChocolate, WPF
Die Gerätegeneration bekam ein neues Vier-Kanal-Pipettierwerkzeug ? bis dahin gab es nur Ein- und Acht-Kanal-Werkzeuge. Zu integrieren war es auf beiden Seiten der Geräteschnittstelle: in der Firmware, damit die Maschine das Werkzeug richtig positioniert und die Probenverfolgung stimmt, und in der Steuersoftware, damit der Editor beim Entwurf eines Laborablaufs mit vier Spitzen umgehen kann. Ein Werkzeug mit vier statt acht Spitzen passt in andere Gefäße ? entsprechend mussten die Kollisionsprüfung im Editor und die Ablaufsteuerung auf beiden Seiten erweitert werden.
Dazu kam die automatische Werkzeugwahl: Welches Werkzeug welchen Schritt eines Ablaufs ausführt, entscheidet ein Algorithmus ? er optimiert auf Geschwindigkeit, während die geforderte Genauigkeit als Randbedingung eingehalten wird.
Daneben habe ich die Anwendung auf .NET 8 gehoben und den Installer erneuert ? Python-Build-System, zentrales Paketmanagement, Code-Signing ? und die Unit- und End-to-End-Tests ausgebaut.
Stack: C#, .NET 8, WPF, WiX Toolset · C++ · Python · Code-Signing
Das Vorhaben begann bei null: die Idee eines Cloud-Editors für Laborprotokolle, aber weder Konzept noch Plan. Meine Aufgabe war, daraus ein planbares Produkt zu machen und das Team dorthin zu führen.
In Workshops mit Product Ownern und Stakeholdern habe ich die Produktvision erarbeitet ? was der Editor können soll, für wen, in welchen Ausbaustufen. Daraus entstanden Konzept und UX-Entwürfe mit klickbarem Prototyp; die Anforderungen habe ich systematisch erhoben und verfeinert und daraus eine Roadmap aus Epics und Features abgeleitet, an der sich die Planung ausrichten konnte.
Fachlicher Kern war das Protokollmodell ? die Datenstruktur, die ein Laborprotokoll maschinenlesbar beschreibt. Sie entstand in drei Fassungen, jede in Workshops und Reviews gemeinsam mit dem Team erarbeitet. Die Umsetzung lief in Iterationen, geplant im Agile Release Train nach SAFe.
Technisch habe ich Azure, Kubernetes und AWS gegeneinander bewertet und die Cloud-Anbindung danach aufgebaut; für die Gerätekommunikation entstand ein MQTT-Prototyp. React habe ich im Team eingeführt, samt Workshop, und die CI-Pipelines für Backend und Frontend mit SonarQube und ESLint als Qualitätsschwellen aufgesetzt.
Stack: .NET 8 · Azure, Kubernetes, AWS · React, TypeScript · MQTT · SonarQube, ESLint · Requirements Engineering, SAFe
Zwei Vorhaben, auf denen die Mandate der folgenden vier Jahre aufsetzen.
Die größte Migration der Steuersoftware: von .NET Framework 4.8 auf .NET 6. Der Aufwand steckte dabei nicht im eigenen Code, sondern in dem, woran er hing ? jede Abhängigkeit musste mitziehen, und wo das nicht ging, wurde sie ersetzt: Entity Framework wich Entity Framework Core, das UI-Framework Prism und der Dependency-Injection-Container mussten auf neue Fassungen gehoben werden. Dazu der Umbau der kompletten Build-Pipeline und neue Windows-Docker-Container dafür.
Das zweite ist die Entwicklungsstrecke, die es bis dahin nicht gab: GitLab-CI mit SonarQube, Merge-Gates und Unit-Tests in der Pipeline. Damit Tests nicht von einem physischen Gerät abhängen, habe ich den Gerätesimulator dockerisiert und automatisierte Simulator-Tests aufgesetzt ? aufgezeichnete Service-Aufrufe mit Soll-Ergebnissen und ein Diff-Werkzeug für Abweichungen.
Ich war ins Scrum-Team eingebettet, Reviews liefen über Merge Requests.
Stack: C#, .NET Framework 4.8 ? .NET 6, WPF, Prism, EF ? EF Core · C++, CMake · GitLab CI, Windows-Docker, SonarQube
Zu Beginn verwaltete der Verein seine Anlagen auf Papier und in Tabellenblättern. In drei Monaten Alleinentwicklung entstand daraus eine produktive Anwendung: Vereine buchen Bahnen und Räume als Termine und Terminserien in einem Kalender ? samt Ferien- und Feiertagsverwaltung, damit Serien um Schließzeiten herum geplant werden. Aus den Belegungen entstehen die Abrechnungspositionen, die das System samt Kundendaten direkt in das Buchhaltungssystem lexoffice synchronisiert ? von der Buchung bis zur Rechnung ohne Medienbruch.
Das Backend ist eine Clean Architecture auf .NET 6 mit eigenem JWT-Issuer für die Anmeldung und MongoDB als Datenbank, ausgeliefert als Docker-Container. Läuft produktiv beim Kunden.
Stack: .NET 6, Clean Architecture, MongoDB, eigener JWT-Issuer · Vue 2 · lexoffice-API · Docker, nginx
Die Wissenschaftler des Kunden werteten ihre massenspektrometrischen Messdaten mit einem gewachsenen Python-Skript aus, das nur sein Autor bedienen konnte. Daraus wurde eine Anwendung: Messdateien laden, die Tabellen inspizieren, Massen-Ladungs-Verhältnis und Achsen wählen, den Graphen als Bild speichern oder die Daten nach Excel exportieren. Ausgeliefert als kompiliertes Programm ohne Installationsaufwand ? das schützt zugleich das Auswerteverfahren des Kunden, weil es für Anwender nicht einsehbar ist, während der Quellcode Python bleibt und die Wissenschaftler selbst weiterbauen können.
Stack: Python 3, Streamlit, pandas
Software Architekt
Lead Developer
Eine Plattform, die seit 2016 durchgehend im Betrieb ist und in dieser Zeit zweimal die Architektur gewechselt hat, ohne Ausfall. Sie begann als Desktopanwendung auf .NET Framework. In der zweiten Generation kam ein eigenes Backend auf ASP.NET Core dazu, gegen das zunächst der Desktop-Client und später ein React-Frontend liefen ? beide gleichzeitig, damit der Betrieb während der Ablösung weiterlaufen konnte. Heute ist es eine Serverless-Plattform auf AWS mit reinem React-Frontend, die Fachlogik in Lambda-Funktionen, die im Leerlauf auf null skalieren. Der Altbestand läuft weiter, bis die Ablösung abgenommen ist; der Betrieb der Schwimmschule stand in zehn Jahren keinen Tag still.
Fachlich deckt sie den ganzen Betrieb ab: Kursplanung, Teilnehmer, Anwesenheit und Abrechnung. Geschnitten ist sie auf die Arbeitssituation am Becken ? das Eincheckpersonal arbeitet am Tablet, die Trainer haken die Anwesenheit am Handy ab und geben ihr Feedback direkt dort, statt es später von Zetteln abzutippen. Das Feedback lässt sich auch einsprechen: Ein Dienst nimmt die Rückmeldung per Spracherkennung auf und wertet sie über ein Sprachmodell aus.
Stack: .NET Framework/WPF ? .NET 8 ? TypeScript, React 19 · AWS CDK, Lambda · Payload CMS, Astro · Progressive Web App · Whisper, OpenAI
Die PC-Software des In-vitro-Diagnostiksystems EntericBio in einem Schritt von .NET Framework 4.8 auf .NET 10 gehoben, ohne Zwischenstufe ? eine Software, die ich 2018 beim selben Hersteller als Projektleiter und Architekt aufgesetzt habe.
Maßgabe war, dass der laufende Laborbetrieb nicht gestört wird: Die neue Fassung musste abwärtskompatibel zur freigegebenen Vorversion bleiben, damit alles, was mit der Altversion erzeugt wurde, weiter läuft. Der Funktionsumfang blieb deshalb bewusst unverändert; die Änderungen betrafen ausschließlich die technische Grundlage.
Neu aufgesetzt wurden dagegen die Strecken drumherum: Build- und CI/CD-Pipelines, die den Windows-Desktop-Build in Docker-Containern unter Windows reproduzierbar machen, sowie der Signaturprozess. Die Inhalte der Delta-Dokumentation ? alle Abweichungen von der freigegebenen Basisversion ? habe ich erstellt und dem Zulassungsinhaber zur Abnahme übergeben, der sie führt. Migration abgeschlossen 06/2026. Beauftragt als Werkleistung zum Festpreis mit drei Zahlungsmeilensteinen ? Projektstart, Abschluss der Migration, erfolgreicher Test und Auslieferung.
Stack: .NET 10, WPF, DevExpress, SQLite · Windows-Docker-Build, Code-Signing, PDF-Signaturen · CI/CD
Bestimmend war die Migration des Fertigungsframeworks von .NET Framework 4.8 auf .NET 10 ? der Software, mit der sämtliche Geräte des Herstellers in der Fertigung montiert und geprüft werden. Den Dependency-Injection-Container neu aufgesetzt, den Code nach Clean-Code-Prinzipien in Domäne, Anwendung und Infrastruktur neu geschnitten, Unit- und Integrationstests ergänzt.
Daneben die Windows-Steuersoftware epBlue der epMotion-Pipettierroboter auf .NET 10 angehoben ? eine seit 2012 gewachsene C#-Codebasis, aus der mehrere Produktvarianten entstehen ? und die UI-Testautomatisierung wieder in Gang gebracht: die gewachsene Testsuite auf TestStack.White instand gesetzt und erweitert, sodass die Oberfläche automatisiert gegen die Anwendung geprüft wird. Dazu der Wissenstransfer an das Team des Kunden ? Firmware wie Steuersoftware ? als eigenes, beauftragtes Arbeitspaket.
Stack: .NET 10, WPF · ASP.NET Core, GraphQL (HotChocolate), EF Core 10 · TestStack.White, MSTest/SpecFlow · GitLab CI, SonarQube
Der Kunde hatte Vorstellungen, aber kein Lastenheft. Ich habe daraus funktionale Anforderungen geschnitten, sie mit ihm priorisiert und umgesetzt ? bis zum Produktivbetrieb vergingen drei Monate.
Es ist eine Quiz-Plattform für Lizenznehmer an 17 Standorten: Ein zentrales Team gestaltet Bilder- und Audio-Quizze, die Lizenznehmer nutzen sie ? Mandantenfähigkeit steckt deshalb im Datenmodell. Ausgegeben wird gedruckt, als A4-Quizbuch mit einem QR-Code pro Frage. Daraus folgt die tragende Bedingung: Ein gedruckter QR-Code muss für immer auflösen. Ein Heft, das seit einem Jahr im Umlauf ist, darf nicht ins Leere zeigen, weil die Vorlage inzwischen überarbeitet wurde. Eine Layout-Änderung erzeugt deshalb eine neue Version unter neuer Kennung, während Textkorrekturen und Übersetzungen die bestehende ändern. Das prägt die gesamte Architektur.
Gebaut auf AWS mit Scale-to-zero und ohne Datenbank-Grundgebühr: im Leerlauf kostet die Plattform wenige Euro im Monat, unter Last ist der Betrieb auf einen kleinen zweistelligen Betrag ausgelegt. Die Domänenlogik liegt als eigenes Paket ohne Cloud-Abhängigkeit vor und ist mit Property-based Tests abgesichert.
Stack: TypeScript durchgängig · AWS CDK, Lambda, DynamoDB, Cognito, SQS, CloudFront · fast-check, Playwright
Ein Projektmanagement-Tool für das Dienstleistungsgeschäft des Kunden. Erfasste Zeiten werden zu Rechnungen und Gutschriften ? mit allem, was daran fachlich hängt: Steuerberechnung, Skonto und Storno, XRechnung als elektronisches Rechnungsformat, Stundenzettel als PDF mit dynamischem Seitenumbruch, Preise und Rabattprofile je Kunde. Dazu die Projekt- und Zeiterfassung selbst, mehrsprachig und zeitzonenfest.
Angebot, Aufwandsschätzung und Zeitplan habe ich verantwortet, den Entwurf des Systems gemacht und dafür ein verteiltes Team aus sechs Personen aufgebaut und fachlich geführt ? Projektsprache durchgehend Englisch. Mit dem Kunden arbeitete ich nach Scrum mit wöchentlichen Reviews, im Team liefen Dailys und Wochensprints, jeder Merge Request ging über ein Review.
Technisch entstand eine Landschaft aus zehn Backend-Services mit GraphQL-Federation über ein Fusion-Gateway, ereignisgetriebener Kommunikation über einen Message Broker und Single Sign-on über Keycloak. Wo die Änderungshistorie fachlich gebraucht wird, liegt Event Sourcing darunter ? im Rechnungswesen und in der Benutzerverwaltung, damit jede Korrektur nachvollziehbar bleibt. Backend und DevOps habe ich selbst umgesetzt, das Frontend entstand in React. Version 1 läuft seit 12/2025 im Produktivbetrieb.
Stack: .NET 10, HotChocolate Fusion, EF Core, PostgreSQL, RabbitMQ, Keycloak-SSO · React 19, TypeScript · Docker, Dagger, Playwright
Aufgabe war eine Geräte-API, über die Drittsysteme die Pipettierroboter fernsteuern: Bestückung verwalten, Operationen ausführen, Gerätezustand abfragen. Dafür musste alles, was bis dahin als Prozesssteuerung in der Firmware lag, in die API wandern ? der Kunde wollte die Logik aus dem Gerät herausholen und die Firmware nur noch ausführen lassen. Viele Logikbausteine wurden aus C++ herausgenommen und in C# neu implementiert. Der eigentliche Aufwand steckte dabei im Lesen und Verstehen des gewachsenen Firmware-Codes und im Nachweis, dass sich die neue Umsetzung exakt wie die alte Prozesssteuerung verhält.
Der fachliche Kern war die Kollisionsvermeidung: Der Roboterarm bewegt sich im dreidimensionalen Arbeitsraum, ohne die Proben zu berühren ? gelöst über eine A-Suche im Raum. Weil die Wegfindung im Takt der Maschine antworten muss, ist sie auf Laufzeit optimiert: Heap-Allokationen im heißen Pfad konsequent vermieden, Laufzeitverhalten mit BenchmarkDotNet gemessen. Auch in C# lässt sich speichernah arbeiten, wenn man es von Anfang an so anlegt. Entwickelt und geprüft an einem eigens gebauten Simulator mit 3D-Visualisierung.
Stack: .NET 8, ASP.NET Core, MediatR/CQRS · C++ auf der Firmware-Seite · xUnit, BenchmarkDotNet · OpenGL/Avalonia · GitHub Actions
Zwei Stränge in dieser Phase.
Auf der Firmware-Seite lief die Verbindung zwischen Gerät und Außenwelt bis dahin als offene Remote-Procedure-Verbindung; dafür habe ich einen abgesicherten Kommunikationskanal über TLS entworfen und als lauffähigen C++-Prototyp umgesetzt, mit Token- und Session-Verwaltung ? eingebettet in eine Cyber-Security-Risikoanalyse der Gerätesoftware, erstellt gemeinsam mit einem Qualitätsingenieur. Dazu die Modernisierung des CMake-Projekts und der Schnitt des monolithischen Teils in eigenständige Module, über Interfaces voneinander getrennt ? seither lässt sich modulweise testen statt nur im Ganzen.
Parallel begann der Neubau des Fertigungsframeworks, mit dem die Geräte montiert und geprüft werden: eine .NET-Anwendung mit plugin-basierten Montagesequenzen, geschnitten in Domäne, Anwendung und Infrastruktur, mit GraphQL-Schnittstelle und WPF-Oberfläche. Abgeschlossen wurde sie 2026 auf .NET 10.
Stack: C++20, CMake, Yocto, Drogon, OpenSSL/TLS · Catch2, Trompeloeil · .NET 8, HotChocolate, WPF
Die Gerätegeneration bekam ein neues Vier-Kanal-Pipettierwerkzeug ? bis dahin gab es nur Ein- und Acht-Kanal-Werkzeuge. Zu integrieren war es auf beiden Seiten der Geräteschnittstelle: in der Firmware, damit die Maschine das Werkzeug richtig positioniert und die Probenverfolgung stimmt, und in der Steuersoftware, damit der Editor beim Entwurf eines Laborablaufs mit vier Spitzen umgehen kann. Ein Werkzeug mit vier statt acht Spitzen passt in andere Gefäße ? entsprechend mussten die Kollisionsprüfung im Editor und die Ablaufsteuerung auf beiden Seiten erweitert werden.
Dazu kam die automatische Werkzeugwahl: Welches Werkzeug welchen Schritt eines Ablaufs ausführt, entscheidet ein Algorithmus ? er optimiert auf Geschwindigkeit, während die geforderte Genauigkeit als Randbedingung eingehalten wird.
Daneben habe ich die Anwendung auf .NET 8 gehoben und den Installer erneuert ? Python-Build-System, zentrales Paketmanagement, Code-Signing ? und die Unit- und End-to-End-Tests ausgebaut.
Stack: C#, .NET 8, WPF, WiX Toolset · C++ · Python · Code-Signing
Das Vorhaben begann bei null: die Idee eines Cloud-Editors für Laborprotokolle, aber weder Konzept noch Plan. Meine Aufgabe war, daraus ein planbares Produkt zu machen und das Team dorthin zu führen.
In Workshops mit Product Ownern und Stakeholdern habe ich die Produktvision erarbeitet ? was der Editor können soll, für wen, in welchen Ausbaustufen. Daraus entstanden Konzept und UX-Entwürfe mit klickbarem Prototyp; die Anforderungen habe ich systematisch erhoben und verfeinert und daraus eine Roadmap aus Epics und Features abgeleitet, an der sich die Planung ausrichten konnte.
Fachlicher Kern war das Protokollmodell ? die Datenstruktur, die ein Laborprotokoll maschinenlesbar beschreibt. Sie entstand in drei Fassungen, jede in Workshops und Reviews gemeinsam mit dem Team erarbeitet. Die Umsetzung lief in Iterationen, geplant im Agile Release Train nach SAFe.
Technisch habe ich Azure, Kubernetes und AWS gegeneinander bewertet und die Cloud-Anbindung danach aufgebaut; für die Gerätekommunikation entstand ein MQTT-Prototyp. React habe ich im Team eingeführt, samt Workshop, und die CI-Pipelines für Backend und Frontend mit SonarQube und ESLint als Qualitätsschwellen aufgesetzt.
Stack: .NET 8 · Azure, Kubernetes, AWS · React, TypeScript · MQTT · SonarQube, ESLint · Requirements Engineering, SAFe
Zwei Vorhaben, auf denen die Mandate der folgenden vier Jahre aufsetzen.
Die größte Migration der Steuersoftware: von .NET Framework 4.8 auf .NET 6. Der Aufwand steckte dabei nicht im eigenen Code, sondern in dem, woran er hing ? jede Abhängigkeit musste mitziehen, und wo das nicht ging, wurde sie ersetzt: Entity Framework wich Entity Framework Core, das UI-Framework Prism und der Dependency-Injection-Container mussten auf neue Fassungen gehoben werden. Dazu der Umbau der kompletten Build-Pipeline und neue Windows-Docker-Container dafür.
Das zweite ist die Entwicklungsstrecke, die es bis dahin nicht gab: GitLab-CI mit SonarQube, Merge-Gates und Unit-Tests in der Pipeline. Damit Tests nicht von einem physischen Gerät abhängen, habe ich den Gerätesimulator dockerisiert und automatisierte Simulator-Tests aufgesetzt ? aufgezeichnete Service-Aufrufe mit Soll-Ergebnissen und ein Diff-Werkzeug für Abweichungen.
Ich war ins Scrum-Team eingebettet, Reviews liefen über Merge Requests.
Stack: C#, .NET Framework 4.8 ? .NET 6, WPF, Prism, EF ? EF Core · C++, CMake · GitLab CI, Windows-Docker, SonarQube
Zu Beginn verwaltete der Verein seine Anlagen auf Papier und in Tabellenblättern. In drei Monaten Alleinentwicklung entstand daraus eine produktive Anwendung: Vereine buchen Bahnen und Räume als Termine und Terminserien in einem Kalender ? samt Ferien- und Feiertagsverwaltung, damit Serien um Schließzeiten herum geplant werden. Aus den Belegungen entstehen die Abrechnungspositionen, die das System samt Kundendaten direkt in das Buchhaltungssystem lexoffice synchronisiert ? von der Buchung bis zur Rechnung ohne Medienbruch.
Das Backend ist eine Clean Architecture auf .NET 6 mit eigenem JWT-Issuer für die Anmeldung und MongoDB als Datenbank, ausgeliefert als Docker-Container. Läuft produktiv beim Kunden.
Stack: .NET 6, Clean Architecture, MongoDB, eigener JWT-Issuer · Vue 2 · lexoffice-API · Docker, nginx
Die Wissenschaftler des Kunden werteten ihre massenspektrometrischen Messdaten mit einem gewachsenen Python-Skript aus, das nur sein Autor bedienen konnte. Daraus wurde eine Anwendung: Messdateien laden, die Tabellen inspizieren, Massen-Ladungs-Verhältnis und Achsen wählen, den Graphen als Bild speichern oder die Daten nach Excel exportieren. Ausgeliefert als kompiliertes Programm ohne Installationsaufwand ? das schützt zugleich das Auswerteverfahren des Kunden, weil es für Anwender nicht einsehbar ist, während der Quellcode Python bleibt und die Wissenschaftler selbst weiterbauen können.
Stack: Python 3, Streamlit, pandas
Software Architekt
Lead Developer