Flexibel beheer software loonmotor.
Deel 1: GIT als opslagplaats voor complexe parametrisatie

Bij Teal Partners zijn we gespecialiseerd in complexe softwareprojecten. Graag vertellen we jullie in deze blogreeks in twee afleveringen over de inhoudelijke aanpak van één van onze projecten.

Het developersteam van Teal Partners ging op zoek naar de ideale architectuur voor het ontwikkelen van een internationale loonmotor. Die berekeningsmotor is gebaseerd op wetgeving die veranderlijk is en per land verschilt. Daarom is parametrisatie cruciaal, volgens Guy De Gruyter, software en developer architect bij Teal Partners. De keuze viel op GIT als opslagruimte. In deze blog legt hij uit waarom.

In samenwerking met SD Worx ontwikkelt Teal Partners een applicatie die hr-departementen van kmo’s ondersteunt. Met dit softwarepakket beheren kmo’s alle hr-gerelateerde informatie voor hun medewerkers. De nieuwe loonmotor berekent onderliggend de lonen, de sociale zekerheidsbijdragen en wat er aan belastingen wordt ingehouden.

Het berekenen van de lonen en het uitbetalen ervan zijn gescheiden processen in de loonmotor. Dit laat prognoses en simulaties toe, zowel voor werkgever als werknemer. Het wordt dus mogelijk om de impact van bepaalde loonscenario’s op de loonkost (voor de werkgever) en het nettoresultaat (voor de werknemer) beter in te schatten.

Flexibel beheer van de loonmotor is cruciaal

Wetgeving bepaalt hoe lonen worden berekend. Deze regels zijn complex, wijzigen vaak en verschillen per land, regio en sector. Het beheer en onderhoud van deze regels staat daarom centraal bij het ontwikkelen van een nieuwe loonmotor.

Snel en correct wetswijzigingen kunnen doorvoeren is cruciaal. Neem de coronapandemie. De steunmaatregelen volgden elkaar snel op om bedrijven ademruimte te geven. Payrollsoftware moet deze wijzigende regels vlot kunnen incorporeren.

Scheiden van ontwikkeling en parametrisatie garandeert snelheid en flexibiliteit

De parametrisatie flexibel beheren is dus een ‘key feature’ voor SD Worx. Om die reden hebben we het ontwikkelen van de software gescheiden van het beheer en de publicatie van de parametrisatie. Door deze scheiding kan de regelgeving sneller worden toegepast. Niet-softwareontwikkelaars kunnen namelijk de regelgeving definiëren via deze parametrisatie. In de praktijk zijn dit business experten of functionele analisten. Zij kunnen sneller de vertaalslag maken.

Deze scheiding maakt de software van de loonmotor abstracter. In de applicatie leggen we enkel de mogelijkheden van de loonmotor in programmacode vast. Hiermee bedoelen we o.a. de verschillende entiteiten, de diverse berekeningsniveaus en hun afhankelijkheden en de user interface om het proces voor eindgebruikers te ondersteunen.

In de parametrisatie leggen we drie zaken vast. Ten eerste: het gedrag van de loonmotor, zoals de relevante berekeningsniveaus. Ten tweede: de interpretatie van bepaalde payroll-input, zoals prestaties of afwezigheden. Ten derde: de eigenlijke loonberekening, zoals de vergelijking tussen bruto- en nettoprestaties, patronale bijdragen of de kwartaalafrekening. ”

Config module voor het parametrisatiebeheer in een microservice architectuur

De loonmotor is modulair opgebouwd volgens de principes van een ’microservices architectuur’. In deze architectuur hebben we het beheer van de parametrisatie ondergebracht in een aparte module, de config module. Deze module publiceert de parametrisatie van de loonmotor.

Van bij de start kozen we ervoor om de ‘definition dataset’, de relevante set aan parametrisatiedata, in elke databank van de operationele modules te bewaren. Dit laat ons toe om de referentiële integriteit te garanderen.

Terwijl elke module slechts een deel van de parametrisatie bewaart, beheert de config module het geheel van parametrisatiedata. Specifieke validatieregels garanderen een consistent geheel.

Onderstaande tekening verduidelijkt de positie van de configuratiemodule ten aanzien van de operationele modules.

Waarom kozen we ervoor om onze parametrisatie in GIT te bewaren?

Het omzetten van regelgeving in parametrisatie lijkt in bepaalde aspecten op het ontwikkelen van software. Het confronteert ons met gelijkaardige uitdagingen.

• Beheren en oplossen van conflicterende wijzigingen:
  
  De softwareoplossing zal internationaal ingezet worden. Dit vereist dat verschillende domeinspecialisten (per land, sector of regio) tegelijk aanpassingen en uitbreidingen aan de parametrisatie zullen aanbrengen. Ze zullen gelijktijdig onze configuratiemodule gebruiken. Zo ontstaat het risico op conflicterende wijzigingen. Het ‘mergen’ van conflicten is een uitdaging die we ook kennen in softwareontwikkeling.
• Nood aan change tracking:
  
  Regelgeving wijzigt continu en elke wijziging heeft potentieel een grote impact op de loonberekening en dus op de benodigde payroll-input. Daarom is het belangrijk om elke aanpassing in de parametrisatie transparant weer te geven. Een versiecontrolesysteem zoals GIT laat toe om elke wijziging (automatisch) te tracken
• Isoleren van wijzigingen:
  
  Bij het beheren van regelgeving is het belangrijk om wijzigingen te kunnen isoleren zodat elke wijziging apart gepubliceerd kan worden. Dit laat toe om eenvoudige wijzigingen sneller te publiceren dan complexere zaken. Dit komt overeen met aparte feature releases in softwareontwikkeling.

Bovenstaande uitdagingen brachten ons op het idee om de parametrisatie niet te bewaren in een klassieke SQL-omgeving of in een document database, maar wel in een GIT repository. De technologie in een GIT repository komt tegemoet aan onze net beschreven noden.

JSON als bijhorende data-formaat

De parametrisatie wordt in de GIT repo opgeslagen in JSON-documenten. Deze bestandsstructuur is eenvoudig lees- en bewerkbaar. Het opslaan van parametrisatie in documenten in plaats van in gedenormaliseerde SQL-tabellen heeft dus een bijkomend voordeel. Zelfs zonder user interface zijn deze bestanden, omwille van de structuur en de inhoud, geschikt om te overlopen met inhoudelijke experten.

Dit is een voorbeeld van een configuratiebestand in JSON:

{
  "Code": "CompanyCar",
  "ConfigSource": "General",
  "ValidFrom": "1900-01-01",
  "ValidUntil": null,
  "AssetType": "LeaseCar",
  "BenefitCalculationClass": "GrossUpContract",
  "Icon": "car",
  "Labels": [{
    "Language": "Dutch",
    "Hash": null,
    "Lb1": "Leasewagen"
  }, {
    "Language": "English",
    "Hash": null,
    "Lb1": "Lease car"
  }, {
    "Language": "French",
    "Hash": null,
    "Lb1": "Voiture de leasing"
  }, {
    "Language": "German",
    "Hash": "29f5932",
    "Lb1": "Leasing-Fahrzeug"
  }]
}

Branching en release strategie in zes stappen

Elke wijziging aan de parametrisatie doorloopt dezelfde releasecyclus als een feature release in de software. Zo’n wijziging aan de parametrisatie wordt geïsoleerd op een feature-branch. Daar wordt zij goedgekeurd via een pull request vooraleer zij gemerged wordt naar onze DEV-branch. Uiteindelijk komt zij na het nodige testen op de MASTER-branch terecht. De wijziging op de MASTER-branch wordt vervolgens gevalideerd in de business-acceptatie-omgeving alvorens ze naar de productieomgeving gaat.

Er zijn zes stappen om een wetswijziging in productie te brengen.

• Een domeinspecialist voert een wijziging door in de parametrisatie op een feature-branch van de MASTER-branch.
• De wijziging wordt gepubliceerd via een pull request waarna deze gereviewd en toegevoegd wordt aan de DEV-branch.
• De wijziging wordt gedeployed naar de development-omgeving. Hier testen we de wijziging geautomatiseerd. Zo vermijden we regressie van bestaande implementaties. Dit is wat we continuous integration noemen.
• De wijziging wordt gereleased naar de quality assurance testomgeving, waar de domeinspecialist de wetswijziging kan valideren.
• Nadien wordt de aanpassing gemerged en vanuit de DEV-branch naar de MASTER-branch gebracht en vervolgens gereleased in de ACCEPTANCE-omgeving. Hier gebeurt een finale check.
• Na de acceptatie door de klant wordt de wijziging gedeployed naar de productie-omgeving.

GitHub garandeert beste integratie

De volgende uitdaging was het integreren van GIT in de configuratiemodule. Vanuit de configuratiemodule moeten we zowel info over branches, commits en data kunnen bevragen als o.a. datawijzigingen en merges kunnen uitvoeren.

Deze integratie is belangrijk om functionele profielen niet rechtstreeks te hoeven confronteren met GIT-commando’s als ‘squashen’, ‘rebasen’ of ‘mergen’.

We hebben verschillende mogelijkheden bekeken. Uiteindelijk kozen we voor GitHub. Die garandeert de beste API-ondersteuning voor de integratie met de software. Naast een traditionele REST API publiceert GitHub ook een GraphQL API.

Deze technologie biedt een preciezere en flexibelere manier om queries uit te voeren dan de klassieke REST API. Dit bleek belangrijk om de performantie te garanderen bij een intensiever gebruik van de parametrisatie.

Conclusie

Samenvattend hebben we (1) de configuratie van software gescheiden van de softwareontwikkeling, (2) de configuratie opgeslagen als JSON-bestanden in een GIT repository, (3) voor de release van de configuratie een pipeline gebruikt die overeenstemt met de pipeline van een softwarerelease, en (4) een integratie met GitHub gebouwd dat toelaat een begeleidend proces rond de parametrisatie uit te werken.

Volgende week gaan we in deel 2 dieper in op het gebruik van microservices architectuur binnen deze structuur. Kom zeker eens kijken als je meer wil weten over onze aanpak.