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
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