DIVID, die Einwegkunststofffonds-Plattform
The DIVID project is the digital platform of the Federal Environment Agency (UBA) for implementing the Single-Use Plastics Fund Act (EWKFondsG), through which Germany has transposed the extended producer responsibility under the EU Single-Use Plastics Directive into national law. The platform serves as the central point of contact for manufacturers, municipalities, and other eligible parties. Manufacturers of single-use plastic products are thereby involved in the costs of cleaning, collection, and disposal. The DIVID platform is developed iteratively on the basis of a modern technology stack with the guiding principles of modularity, microservices, and API-First, and enables the required digital processing of all processes from manufacturer registration and quantity reporting through to fund management and payment settlement for eligible groups.
- Merging functionally related microservices
- Automated data migration of distributed databases into a common schema
- Adaptation of the API Gateway
- Creating the CI pipeline in Azure DevOps
- Configuring code coverage measurement
- Rolling out SonarQube in an IaC pipeline
Application Monitoring
cover.mesh had an existing application in which insurance data was stored. The goal of the project was the real-time capture of data changes in the new back-office service, including a graphical presentation as time-series analysis in an interactive web dashboard.
- Implementation of event sending within the persistence layer
- Configuration and integration of Azure Event Hub
- Development of a reliable messaging logic (at-least-once delivery)
- Implementation of the time-series calculation
- Building the web portal with Blazor Server Pages
- Development of dynamic bar charts for displaying time-series analyses
- Creating the CI/CD pipeline in Azure DevOps
Insurance Calculation for Nursing Homes
cover.mesh is part of the SCHUNCK GROUP and develops digital solutions for it. The SCHUNCK GROUP is a company of the Ecclesia Group and the largest German insurance broker for businesses and institutions. The task of the project was to provide a web platform that performs calculations based on domain-specific rules.
- Building the web portal with Blazor Server Pages
- Creating the CI/CD pipeline in Azure DevOps
- Implementation of the business logic
Caller Verification
Consumers can call Lowell. At peak times, call volumes reach one call every two seconds. In collaboration with a provider of IVR systems (Interactive Voice Response), a system was created in which callers automatically verify themselves using their case reference number and personal data. After successful verification, they are transferred to a case worker, whose system automatically opens the correct file. The project focus was on the highest possible availability, as outages would have caused significant additional workload for case workers.
- Onboarding new Lowell subsidiaries
- Adaptations and extensions of the interfaces
- Definition of the API with a focus on compatibility
- Communication of the API to third-party providers
- Testing the interface locally, in the CI build, and in production (partially semi-automated)
- Rolling out the API with zero downtime in a Kubernetes cluster
- Analysis and resolution of production errors based on log entries
- Analysis of connection issues in the Akka.NET code
- Monitoring of incoming calls
Claim Data for the Consumer Portal
Lowell's consumer portal is a central digital service platform for individuals with outstanding claims at the debt collection agency. Lowell consists of multiple companies that are separated both organizationally and technically. Several different debt collection software systems had to be mapped onto a single API.
- Onboarding new Lowell subsidiaries
- Adaptations and extensions of the interfaces
- Definition of the API with a focus on compatibility
- Testing the interface locally, in the CI build, and in production (partially semi-automated)
- Rolling out the API with zero downtime in a Kubernetes cluster
- Analysis and resolution of production errors
- Reduction of the number of services, as the microservices had been cut too small
- Fixing security vulnerabilities and hardening API interfaces after penetration tests
- Guiding the development team to sustainably avoid identified weaknesses
- Defending the system architecture against external security auditors