From Complex Subsidy Rules to a Custom Enterprise Application

Project Overview

Client: A "Centre d'Aide" (Aid Center) in Liège, Belgium.
Domain: Social Services & Healthcare Administration
My Role: Full-Stack Software Engineer (at Sysmedit). With only two years of professional experience at the time, I was the sole developer responsible for the end-to-end design, architecture, and implementation of the entire application.
Technology Stack: Java, EJB3, JPA/Hibernate, JBoss, Eclipse RCP, SWT/JFace, PostgreSQL, JasperReports.

The Challenge: A Unique, Non-Commercial Workflow

The client was a social service organization, not a typical commercial business. Their core funding depended on securing government subsidies from the Walloon Region based on services provided by their staff (family and domestic helpers).

This created a unique and complex business challenge:

Complex Rules: The subsidy process was governed by strict and specific administrative rules, not standard commercial invoicing.
Manual Processes: The client was struggling with manual data entry and report generation, which was time-consuming and prone to errors that could jeopardize their funding.
No Off-the-Shelf Solution: Standard accounting or ERP software was unusable. It was all built for sales-based invoicing, not for generating official PDF subsidy requests based on "prestations" (logged services).

They needed a custom, robust, and secure multi-user application that could manage their entire administrative workflow, from staff scheduling to the final, government-compliant PDF.

The Solution: "Opis" — A Custom Enterprise Application

I single-handedly designed and built the "Opis" application, a 50+ KLoC, two-tier, client-server system tailored perfectly to the client's needs.

The application was built on a modular architecture, providing a complete solution for the center's administrators and accountants.

Key Functional Modules:

Directory (Répertoire): A central CRM module for managing all personnel, clients, and related contacts.
Service Tracking (Prestations): The system's core. This module allowed accountants to meticulously log all services, meetings, and employee leave, forming the data backbone for all subsidy requests.
Subsidy Generation (Facturation): The "billing" module. This was the client's "money button" — an engine that processed the logged services and generated the official, pixel-perfect PDF documents required by the Walloon Region's government.
Reporting & Data Export: The system integrated JasperReports for powerful internal reporting (e.g., personnel contracts) and included a custom data exporter to bridge with their external "BOB" accounting software.

Architectural Deep Dive: A Robust Stack for a Complex Task

Given the need for a secure, data-intensive, multi-user desktop application, I architected the solution using what was the bleeding-edge, enterprise-grade technology of the time.

Backend Server: A JBoss Application Server hosted the core business logic.
Business Logic: The backend was built using Enterprise JavaBeans (EJB3), providing a robust, transactional, and secure environment for the application's logic.
Database & Persistence: We used PostgreSQL 8.0 as the database, with JPA (Java Persistence API) / Hibernate managing all data persistence. This provided a powerful and maintainable object-relational mapping (ORM) layer.
Frontend Client: The UI was a modular, "thick client" desktop application built on the Eclipse Rich Client Platform (RCP). This framework, combined with SWT and JFace, allowed for the creation of a high-performance, responsive, and feature-rich user experience for the accountants, who were the system's power users.
Communication: The RCP client communicated with the JBoss backend via JNDI and remote EJB calls, a classic, robust client-server model.

This architecture ensured the application was secure, reliable, and capable of handling the client's complex data and reporting requirements.

Project Status & Engineering Achievement

This was an ambitious, large-scale project for the startup that employed me. The development of such a complex, 50+ KLoC application was a massive undertaking. Ultimately, the development timeline extended beyond the startup's initial projections, and the project was halted after the test-environment delivery, before a full production deployment.

However, from an engineering and personal standpoint, this project was a formative achievement.

Sole Junior Developer: As a junior developer with only two years of experience, I had single-handedly designed, architected, and built this entire enterprise-grade application from scratch.
Proven Technical Delivery: A fully functional, two-tier system was delivered and proven in a test environment, successfully demonstrating its capability to solve the client's complex administrative and subsidy-generation workflow.
A Foundation for Today: This project serves as a powerful early testament to my ability to tackle immense technical complexity, manage an entire software lifecycle, and deliver a robust solution—skills that I have spent the last 20 years refining.

Retrospective & Modernization Path (The CTO View)

The Opis project is a perfect example of a robust, state-of-the-art application for its time. Reflecting on this project with over 20 years of experience, here is how I would architect the same solution today to meet modern needs.

The goal would shift from a desktop-bound client to a flexible, scalable, and maintainable platform.

Backend Architecture: I would migrate the monolithic EJB backend to a Spring Boot microservices architecture (leveraging my deep Java expertise). This would break down the logic (e.g., "Directory Service," "Prestation Service," "PDF Generation Service") into independent, scalable units.
Admin Frontend: The Eclipse RCP client would be replaced with a modern, responsive web application built with Next.js and React. This would be the "power-user" interface for accountants and administrators.
Field-Staff Mobile App: I would introduce a new Progressive Web App (PWA) or mobile app for the field staff (the helpers). This app would connect to the backend and empower staff to:
- Manage their schedules and report sick leave directly.
- Semi-automatically encode their "prestations" on-site, perhaps using geo-location and timers as confirmation, drastically reducing manual data entry for accountants.
- Automatic Re-scheduling: A sick leave entry would automatically trigger the re-scheduling engine.
Scheduling & Planning Engine: To address the original, unfinished "Planning" module, I would introduce a dedicated constraint-solving engine. A tool like OptaPlanner (now part of Timefold) would be ideal, integrating as a Spring Boot module. It would handle the immense complexity of scheduling and automatically re-calculating schedules when triggered by a sick leave report from the mobile app.
API Layer: The EJB communication would be replaced by a clean RESTful API layer, secured by Spring Security, serving both the admin web app and the staff mobile app.
Database: I would upgrade to a modern, managed PostgreSQL database (such as Neon, which I use for my own projects) to ensure scalability and reduce maintenance overhead.
Build & Deployment: The legacy Ant/Maven/Eclipse build system would be replaced with a modern CI/CD pipeline (e.g., using GitHub Actions) that builds and deploys containerized (Docker) applications, allowing for automated testing and seamless updates.

This modern web stack would provide greater flexibility, scalability, and long-term maintainability, solving the same business problem with the best tools available today. This is precisely the strategic, forward-looking approach I bring to my clients.