PaedNet (Teil des Schulportal Hessen)
PaedNet kommt innerhalb des lokalen Schulnetzwerkes zum Einsatz. Es dient der Administration der Computer im Computerraum und der Steuerung unterrichtlicher Szenarien mit schuleigenen Geräten. Die Software ermöglicht unter anderem die zentrale Steuerung von Rechnern im Fachraum (Monitorsperre, Internetsperre), die automatisierte Verteilung und das Einsammeln von Dateien, die Installation und Aktualisierung von Software auf allen Schulrechnern sowie die Generierung standardisierter Code-Abschnitte mit AI.
- Architekturneuentwurf für bestehende Software
- Modernisierung von bestehender Software
- Coderefactoring mit Fokussierung auf Wartbarkeit
- Einführung aktueller Standards (Logging, Dependency Injection)
- Schulung in den Best Practices der Standards
- Etablierung von automatischen Tests
- Vermittlung agiler Konzepte (Anforderungsverfeinerung, regelmäßige Reviews)
- Beratung und Konzeption von pragmatischen Lösungsansätzen zur Reduzierung technischer Komplexität
DIVID, die Einwegkunststofffonds-Plattform
Das Projekt DIVID ist die digitale Plattform des Umweltbundesamtes (UBA) zur Umsetzung des Einwegkunststoff-Fondsgesetzes (EWKFondsG) mit dem Deutschland die erweiterte Herstellerverantwortung gemäß EU-Einwegkunststoffrichtlinie in nationales Recht überführt hat. Die Plattform dient als zentrale Anlaufstelle für Hersteller, Kommunen und andere Anspruchsberechtigte. Hersteller von Einwegkunststoffprodukten werden damit an den Kosten für Reinigung, Sammlung und Entsorgung beteiligt. Die DIVID-Plattform wird auf Basis eines modernen Technologie-Stacks mit den Leitprinzipien Modularität, Microservices und API-First iterativ entwickelt und ermöglicht die benötigte digitale Abwicklung aller Prozesse von der Herstellerregistrierung, deren Mengenmeldung bis hin zur Fondsverwaltung und Auszahlungsabwicklung an anspruchsberechtigte Gruppen.
- Fusion von funktional zusammengehörigen Microservices
- Automatisierte Datenmigration der verteilten Datenbanken in ein gemeinsames Schema
- Anpassung des API Gateways
- Erstellen der CI Pipeline in Azure Devops
- Konfiguration der Messung der Codeabdeckung (Code Coverage)
- Ausrollen von Sonarcube in einer IaC-Pipeline
Monitoring einer Applikation
cover.mesh hatte eine bereits bestehende Applikation in der Versicherungsdaten angelegt wurden. Ziel des Projektes war die Echtzeit-Erfassung von Datenänderungen im dem neuen Backoffice-Service inklusive einer grafischen Aufbereitung als Zeitreihen-Analyse in einem interaktiven Web-Dashboard.
- Implementierung von Event-Sendens innerhalb der Persistierungsschicht
- Konfiguration und Anbindung des Azure Event Hubs
- Entwicklung einer zuverlässigen Nachrichten-Logik (At-least-once delivery)
- Implementierung der Berechnung der Zeitreihen
- Erstellen des Webportal mit Blazor Server Pages
- Entwicklung von dynamischen Balkendiagrammen zur Darstellung von Zeitreihen-Analysen
- Erstellen der CI/CD Pipeline ins Azure Devops
Berechnung von Versicherungen für Altersheime
cover.mesh ist Teil der SCHUNCK GROUP und entwickelt für diese digitale Lösungen. Die SCHUNCK GROUP ist ein Unternehmen der Ecclesia Gruppe und der größte deutsche Versicherungsmakler für Unternehmen und Institutionen. Aufgabe des Projektes war es ein Webplattform bereitzustellen, die Berechnungen anhand fachlicher Regeln durchführt.
- Erstellen des Webportal mit Blazor Server Pages
- Erstellen der CI/CD Pipeline ins Azure Devops
- Implementierung der fachlichen Logik
Re-Submit binärer Deadletter Queue Nachrichten für den Azure ServiceBus
Für den Azure ServiceBus existieren zwei Oberflächen. Die eine Oberfläche ist eine Windowsapplikation namens ServiceBusExplorer, die ursprünglich für den Windows ServiceBus entwickelt wurde. Die andere Oberfläche ist der Azure ServiceBusExplorer, eine Weboberfläche in Azure Devops, die dem ursprünglichen ServiceBusExplorer nachempfunden wurde. Beide der Oberflächen erlauben es einzelne Nachrichten in einer Deadletter Queue neu zu versenden. Ist die Nachricht dabei binär (z.B. durch Protobuf) kodiert, so wird die Nachricht als Text interpretiert und damit unbrauchbar. Aufgabe des Projekts war es, beide Oberflächen so zu erweitern, dass das erneute Senden einzelner Nachrichten möglich war.
- Reproduktion des Problems in einem einfachen Beispiel
- Erstellung des Feature Request für Azure ServiceBusExplorer
- Erstellen und Diskussion des Issues für ServiceBusExplorer
- Implementierung einer Lösung für den ServiceBusExplorer
Self-Service Payment Portal
Lowell hatte bereits eine Onlinezahlungsmöglichkeit über das Konsumentenportal realisiert. Da der Registrierungsprozess für das Portal aber aufwändig ist und den Versand eines Briefes vorsah, wollte das Management unkomplizierte Lösungen Forderungen direkt online zu bezahlen. Im Rahmen des Projektes wurden mehrere Möglichkeiten entwickelt und umgesetzt.
- Konzept der Lösungen mit dem Geschäftsführer
- Umsetzung von drei Konzepten (Self-Service Payment Portal mit Postleitzahl, Zahlungslinkversand in dem Begrüssungsschreiben, Ad-hoc Zahlungslink an Anrufer)
- Monitoring der eingenommenen Zahlungen
- Datenschutzkonforme Gestaltung des Self-Service Payment Portals
Monitoring für Fachapplikationen
Ziel des Projekts war es den regulären Betrieb in der Cloud für Mitarbeiter sichtbar zu machen. In den bisherigen Systemen bekamen Entwickler häufiger den Auftrag zu prüfen, ob das System noch korrekt läuft. Die Aufgabe war es einerseits sichtbar zu machen, dass das System korrekt läuft und andererseits Probleme so schnell zu erkennen, dass sie gelöst wurden bevor es als Fehler gemeldet wurde.
- Evaluierung von OpenTelemetry und OpenTracing
- Konzept und Entwicklung einer Tracing Lösung für asynchrone Kommunikation über Business Events
- Einbau von fachlichen Metriken in C#
- Erstellung von Dashboards in Grafana
- Konfiguration des Alerting und Feinabstimmung der Schwellenwerte
cLean – Inkassosoftware
Lowell verfolgte mit dem Projekt cLean den Aufbau einer einheitlichen Inkassosoftware für alle Unternehmen. Dabei sollten alle Forderungen der DACH-Organisation in einem hochverfügbaren System möglichst automatisiert verarbeitet werden. Ein Hauptaugenmerk war dabei die mögliche Skalierung des Systems zu bestimmen Zeiten, in denen viele Forderungen importiert werden mussten. C# war die primäre Programmiersprache aber einzelne Services wurden mit Kotlin und Go umgesetzt.
- Architektur des Microservices-Systems
- Schneiden der Services nach den Domänen der Fachlichkeit (DDD)
- Schneiden der Daten in Aggregate
- Konzept und Entwurf eines sowohl menschen- als auch computerlesbaren Aktenzeichens
- Konzept einer unveränderbaren Buchhaltung mit Event Sourcing
- Konzept und Implementierung der Buchhaltungskomponente unter Einhaltung der fachlichen Regeln
- Recherche der Verrechnungslogik in Deutschland und Österreich
- Implementierung der Fachlogik
- Realisierung von Suchanfragen über verteilte Systeme (separater Service mittels CQRS)
- Teamübergreifendes Coaching, Schulungen und Hilfestellungen
API-First
Lowell verfolgt eine API-First Strategie. Ziel war es, die API auch außenstehenden Prozessen zur Verfügung zu stellen. Deswegen wurde eine zentrale API vollautomatisch bereitgestellt und von allen Services genutzt. Die API unterliegt strengen Richtlinien an Design und Abwärts- und/oder Aufwärtskompatibilität je nach Anwendungsfall.
- Konzept und Erstellung eines zentralen API-First-Repositories auf Basis von Protobuf
- Automatisierte Erzeugung von Release und Pre-Release Versionen für mehrere Programmiersprachen für die Optimierung der Entwicklungsgeschwindigkeit
- Konzept einer API-Versionierung
- Erstellen von APIs
- Dokumentation der API
- Review von APIs mit primärem Fokus auf Verständlichkeit, Dokumentation und Breaking Changes
Umzug eines On-Premise Kubernetes Clusters in die Azure Cloud
Zunächst wurden die Services in einem On-Premise Kubernetes Cluster betrieben. Ziel des Projekts war, alle Services auf die Azure Cloud umziehen. Außerdem wurden Techniken und Cloudservice evaluiert, Hilfsklassen und Template für die zukünftige Entwicklung und eine CI/CD Pipeline erstellt.
- Auswahl der zu nutzenden Cloud-Services in Absprache mit dem Architekten
- Absprachen über zukünftige Autonomie der Entwicklerteams
- Review bestehenden Code und daraus resultierender Best-Practices
- Dokumentation des Transaction Outbox Pattern und Idempotenz, Aggregaten und anderen nützlichen Microservice Pattern
- Hilfsklassen für die Zustellung und Empfang von Protobuf Business Events
- Erstellung des CI-Teils der CI/CD Pipeline
- Evaluierung und Implementierung von Azure Serverless
- Aufsetzen der Infrastruktur unter Anwendung von InfrastructureAsCode (IaC)
- Liveness-Check / Readiness-Check für Services in Kubernetes
- Erstellung von Cronjobs in Kubernetes
- Erstellung von C# Templates für die Erstellung neuer Services
Verifikation von Anrufern
Konsumenten können bei Lowell anrufen. Die Anzahl der Anrufe liegt in Spitzenzeiten bei einem Anruf alle zwei Sekunden. Es wurde in Zusammenarbeit mit einem Anbieter für IVR-System (Interactive Voice Response) ein System geschaffen, bei dem der Anrufer sich automatisch mit Aktenzeichen und persönlichen Daten verifiziert. Nach erfolgter Verifikation wird er an einen Sachbearbeiter weitergeleitet, bei dem sich automatisch die richtige Akte öffnet. Der Fokus des Projekts lag auf der höchstmöglichen Verfügbarkeit, da Ausfälle erheblichen Mehraufwand beim Sachbearbeiter erzeugt hätten.
- Anbinden neuer Subunternehmen von Lowell
- Anpassungen und Erweiterungen der Schnittstellen
- Definition der API mit Fokus auf Kompatibilität
- Kommunikation der API zu Drittanbietern
- Testen der Schnittstelle lokal, im CI Build als auch in Produktion (teils nur halbautomatisiert)
- Ausrollen der API mit Zero Downtime in einem Kubernetes Cluster
- Analyse und Beheben von Fehlern in der Produktion anhand von Logeinträgen
- Analyse von Verbindungsproblemen im Akka.NET Code
- Monitoring der eingehenden Anrufe
Forderungsdaten für das Konsumentenportal
Das Konsumentenportal von Lowell ist eine zentrale, digitale Service-Plattform für Personen, die offene Forderungen bei dem Inkassodienstleister haben. Lowell besteht aus mehreren Unternehmen, die sowohl organisatorisch als auch technisch voneinander getrennt sind. Dabei mussten mehrere verschiedene Inkassosoftware-Systemen auf eine API abgebildet werden.
- Anbinden neuer Subunternehmen von Lowell
- Anpassungen und Erweiterungen der Schnittstellen
- Definition der API mit Fokus auf Kompatibilität
- Testen der Schnittstelle lokal, im CI Build als auch in Produktion (teils nur halbautomatisiert)
- Ausrollen der API mit Zero Downtime in einem Kubernetes Cluster
- Analyse und Beheben von Fehlern in der Produktion
- Reduzierung der Anzahl der Services, da die Microservices zu klein geschnitten waren
- Behebung von Sicherheitslücken und Härtung der API-Schnittstellen nach Penetrationstests
- Anleitung des Entwicklerteams um erkannte Schwachstellen nachhaltig zu vermeiden
- Verteidigung der Systemarchitektur gegenüber externen Security-Auditoren
Schleupen.CS 3.0 – Architektur und Framework
Die Schleupen.CS-Softwarelösung ist eine verteilte Software mit zahlreichen sowohl fachlichen als auch technischen Bausteinen mit dem Ziel, eine standardisierte sowie konfigurierbare Softwarelösung für die Energie- und Wasserwirtschaft für unterschiedliche Marktrollen bereit zu stellen. Das Team „Architektur und Framework" arbeitet dabei direkt mit dem Enterprise Architekten zusammen und kümmert sich um alle Querschnittsthemen des Backend. Die Aufgaben bestehen darin, für die über 100 Entwickler teamübergreifende Best-Practices, Design Patterns als auch ein Framework zu schaffen, so dass die Architektur möglichst einheitlich umgesetzt wird, trotz der vielen verschiedenen Applikationen.
- Entwicklung sowie Konsolidierung der Anwendungsarchitektur
- Reduzierung der Abhängigkeiten zwischen den Teams durch besseres Schneiden des Frameworks
- Entwicklung von SOAP-Services für Plattform-Komponenten
- Analyse, Entwurf und Programmierung einer neuen Deployment-Lösung auf Basis von Puppet
- Schreiben und Automatisieren von CoffeeScript (Javascript-Dialekt) Unit-Tests
Persistenz-Probleme
Die neu eingeführten Continuous-Delivery Pipelines deckten nicht reproduzierbare Persistenz-Probleme auf. Verteilte Transaktionen konnten unter Last nicht abgeschlossen werden. Da Schleupen.CS 3.0 nur eine Datenbank hat, hätten überhaupt keine verteilten Transaktionen auftreten dürfen. Die Aufgabe des Projekts war es, die Probleme zu analysieren und zu beheben.
- Analyse von Logeinträgen, Fehlermeldungen und Code um den Fehler systematisch einzugrenzen
- Analysieren von NHibernate und dessen internem Umgang mit Transaktionen
- Konzept und Implementierung einer sauberen, aber aufwändigen Lösung für neue Applikationen
- Konzept und Implementierung einer schnellen, aber etwas getricksten Lösung für bestehende Applikationen
- Dokumentation beider Lösungen
- Schulungen in den Lösungen
- Implementierung der sauberen Lösung in den Plattform-Komponenten
Legacy-Pub-Sub-Lösung
Um die gesetzlichen Vorgaben zu Smart Meter (intelligente Stromzähler) einzuhalten, war es notwendig eine Kommunikationslösung zwischen Schleupen.CS 2.0 und 3.0 herzustellen. Diese war in der initialen Architektur eigentlich ausgeschlossen worden, wurde aber fachlich notwendig.
- Konzept einer asynchronen Kommunikation zwischen getrennten Systemen
- Abbildung von Pub/Sub-Queues in einer Datenbank
- Implementierung generischer Empfänger und Senderlösungen
Stabilisierung der asynchronen Kommunikation – Fachkomponenten
Wenn verteilte Systeme asynchron kommunizieren und dabei Nachrichten verloren gehen, ist es sehr schwer herauszufinden wo sie verloren gehen. Da das vorherige Projekt gezeigt hat, dass die Fehler nun nicht mehr in den Plattform-Komponenten lagen, war die Aufgabe des Teams, im Framework Lösungen bereitzustellen, um die Fachentwickler zu unterstützen.
- Konzept und Implementierung des Transaction Outbox Pattern im Framework
- Dokumentation des Transaction Outbox Pattern
- Schulungen zu Idempotenz und Transaction Outbox Pattern
Stabilisierung der asynchronen Kommunikation – Plattform
Wenn verteilte Systeme asynchron kommunizieren und dabei Nachrichten verloren gehen, ist es sehr schwer herauszufinden wo sie verloren gehen. Die Aufgabe des Projekts war es, den bestehenden Code zu analysieren und dabei Schwachstellen in den Plattform-Komponenten zu entdecken und zu beheben. Außerdem wurden Lösungen entwickelt, um das Vertrauen der Tester und Entwickler in die Plattform-Komponenten zu erhöhen.
- Konzept und Implementierung des Test Message Pattern
Akten- und Vorgangsfenster
Neuentwicklung des zentralen Arbeitsbereichs der Inkasso-Software (IKAROS V4). Das Projekt umfasste die Neugestaltung des Akten- und Vorgangsfensters, um komplexe Fallinformationen übersichtlich und performant darzustellen. Durch den Einsatz von Event-Sourcing wurde eine moderne, nachvollziehbare Datenhaltung für die Bearbeitungsschritte realisiert. Das effiziente Laden der Events bedarf dabei einer optimierten Datenladelogik.
- Implementierung der Ansicht des Vorgangsfensters
- Implementierung der Businesslogik für die Anzeige von Vorgängen
- Aufrufen und Anzeigen der Werte von Forderungsberechnung und -aufstellung
- Performance-Optimierung der Datenabfragen durch Implementierung hocheffizienter SQL-Anfragen (unter Umgehung von NHibernate zur Maximierung der Ladegeschwindigkeit)
- Sicherstellung der Funktionalität durch automatisierte Tests (Unit-Tests)
Verantwortung im Bereich automatisierte Tests
Strategisches Projekt zur Verbesserung der Softwarequalität über alle Produktbereiche hinweg. Ziel war die unternehmensweite Standardisierung von Testverfahren, um die Stabilität der Night-Builds zu erhöhen und Regressionen frühzeitig zu erkennen. Dies beinhaltete sowohl technische Anpassungen als auch den Wissenstransfer innerhalb der Entwicklungsabteilung.
- Mit gutem Beispiel vorangehen
- Unternehmensweite Etablierung von Best-Practices bei der Testautomatisierung
- Testabdeckungsabsprachen mit Testern
- Schulungen zur Durchführung von Unit-Tests und Pattern
- Analyse von fehlgeschlagenen Tests im Night Build (z.B. bei Sommer-/Winterzeit-Wechsel)
Forderungsaufstellung
Eine Forderungsaufstellung ist eine detaillierte, tabellarische Auflistung aller offenen Beträge (Forderungen, Zinsen, Gebühren), die ein Gläubiger von einem Schuldner verlangt. Die Daten dazu werden von der Forderungsberechnung bereitgestellt. Der Schuldner hat jederzeit die Möglichkeit eine Forderungsaufstellung zu verlangen und diese muss von IKAROS rechtssicher erzeugt werden.
- Erweiterung der Forderungsberechnung, um die einzelnen Berechnungsschritte zu erhalten
- Implementierung der Forderungsaufstellung
- Ausgabe der Berechnung in einer Word-Datei
- Absprache der konkreten Testfälle mit Fachkollegen
- Erstellung automatisierter Tests für die Forderungsaufstellung
- Erstellen von Tests bei Fehlern und deren anschließende Behebung
Abrechnung
Ferber-Software ist mit seiner Inkassosoftware IKAROS Marktführer in Deutschland. Im Rahmen des IKAROS V4 Projekts wurden verschiedene Module modernisiert. Bei der Abrechnung ging es darum, bestehende Businesslogik aus der Datenbank MsSQL herauszulösen und in eine Businesslogikschicht zu überführen.
- Analyse bestehender T-SQL Stored Procedures und Abbildung der Logik in C#
- Design und Implementierung der neuen Businesslogik-Schicht
- Datenmodellierung und Mapping mittels NHibernate
- Optimierung der Datenbankabfragen für die Performance-Sicherung während der Abrechnungsläufe
Consulting für Inkassounternehmen
Ferber-Software ist mit seiner Inkassosoftware IKAROS Marktführer in Deutschland. IKAROS verfügt über eine eigene Programmiersprache, mit der man die Software anpassen kann. Zudem werden Anpassungen über Import- und Exportschnittstellen gelöst. Consultants übernehmen diese Anpassungen beim Kunden vor Ort.
- Programm zu Import- und Export von Forderungsdaten eines Fluggastrechte-Portals aus einer und in eine andere Inkassosoftware
- Absprache und Konkretisieren der Anforderungen mit dem Kunden
- Schulung der Consultants bei der Softwareentwicklung mit C#
Marktplatz für Inkassoaußendienstleister
Konzeption und Realisierung eines B2B-Webportals als Marktplatz-Lösung für das Forderungsmanagement. Das System ermöglicht es Inkassounternehmen, Forderungen digital einzuspielen, welche automatisiert an freiberufliche Außendienstleister zur Vor-Ort-Kontaktaufnahme vermittelt werden. Die Plattform fungiert als effiziente, privatwirtschaftliche Alternative zum klassischen Gerichtsvollzieherwesen und optimiert die Prozesskette zwischen Innendienst und mobilem Außendienst.
- Full-Stack-Entwicklung des Portals und der zugrunde liegenden Geschäftslogik
- Implementierung der Import-Schnittstellen für die automatisierte Übernahme von Forderungsdaten
- Realisierung einer Export-Funktionalität für Abrechnungsunterlagen (Rechnungen)
- Mehrfaches manuelles Deployment des Web-Portals
- Analyse der Ergebnisse eines Penetrationstests und Beratung zur Ableitung von Handlungsstrategien
- Kontinuierliche Weiterentwicklung und technischer und fachlicher Support des Marktplatzes nach dem initialen Release