Version en français

(Update 20 november 2024)

In 2019 kondigden we een Proof of Concept aan voor de latere invoering van een generieke ATMS service (Anomalies & Transactions Management System). We halen hier opnieuw de voornaamste redenen aan op het vlak van Data Quality en  ROI, aangetoond met use cases alsook de functionele specificaties. Vervolgens gaan we van daaruit over op de  technische voortgang en bespreken we de verdere ontwikkelperspectieven.

Een preventieve “Data Quality”-aanpak met een mogelijk grote ROI

Zoals Figuur 1 hieronder aantoont moet er een curatieve aanpak gevoerd worden via een Data Quality Tool wanneer kwaliteitsproblemen met data al aanwezig zijn in de databases (bijvoorbeeld: vermoeden van dubbels rechts in de figuur).

Figuur 1. Preventieve en curatieve aanpakken

Dat gezegd zijnde, als we enkel stroomafwaarts actie ondernemen, zullen kwaliteitsproblemen “ad infinitum” blijven toestromen aangezien ze afkomstig zijn van informatieprocessen en -stromen die de databases voeden of als gevolg van de evolutie van

het toepassingsgebied. Bijgevolg is een preventieve aanpak noodzakelijk om de kwaliteitsproblemen structureel bij de bron op te lossen.

Dit is mogelijk met de originele ”backtracking”-techniek: gezien de structurele voordelen ervan op het vlak van verminderde manpower (vermindering tussen 50% en 80% aan manpower nodig voor de verwerking van de anomalieën) en  op het vlak van datakwaliteit. Deze techniek werd opgenomen in de wet als koninklijk besluit in februari 2017 betreffende de kwaliteitsbarometers die toegepast worden op de Belgische erkende sociale secretariaten en de DmfA.

De LATG-database (Loon en ArbeidsTijdsGegevensbank) eind jaren 90 en later zijn vernieuwde erfgenaam, de DmfA (Déclaration Multifonctionelle – Multifunctionele Aangifte), begin jaren 2000 tot nu, waren de bevoorrechte ‘case studies’ van de verwerking gezien de strategische omvang ervan. Inmiddels kunnen met de DmfA jaarlijks immers 65 miljard euro aan sociale bijdragen geïnd en herverdeeld worden over heel België. 

Hierin wordt het ATMS-mechanisme op grote schaal gedeployd via een hiërarchisch DBMS en specifieke externe code die gekoppeld is aan een generiek regelgebaseerd systeem. We tonen hier een aanpak die momenteel wordt ontwikkeld in de vorm van een prototype met als doel het toepassingsgebied te verbreden door de implementatie van een generieke ATMS-service, die toepasbaar is op elk relationeel DBMS (RDBMS), zoals PostgreSQL of Oracle. Dit omvat overigens alle ‘text’-gegevensstructuren (JSON, XML, enz.).

ATMS: een essentiële basis voor “data monitoring” en “backtracking” 

De hierboven genoemde backtrackingoperatie is gebaseerd op statistische monitoring van anomalieën en transacties met behulp van een ATMS (Anomalies and Transactions Management System). Het ATMS wordt opgezet na specificatie van de strategische kwaliteitsindicatoren naargelang het toepassingsgebied.  De operatie maakt het vervolgens mogelijk om binnen de gegevensprocessen en -stromen, in samenwerking met de informatieleverancier en de databasebeheerder, de structurele oorzaken te identificeren van de productie van een groot aantal systematische anomalieën en/of anomalieën die als strategisch worden beschouwd: onjuiste verwerking van bepaalde gegevensbronnen, ontstaan van nieuwe situaties, ontoereikende interpretatie van wetgeving, programmeerfouten, enz. Op basis hiervan kan een diagnose worden gesteld en kunnen duurzame en structurele corrigerende maatregelen worden genomen (correctie van formele code in programma’s, herstructurering van processen, aanpassing van de interpretatie van een wet, verduidelijking van documentatie, enz.)

Een voorbeeld: met de mondialisering kunnen er internationaal nieuwe gevallen opduiken die aanvankelijk niet voorzien werden in referentietabellen en wetgeving. Dit kan op een bepaald moment voorvallen in het energiedomein onder de operationele eenheden van buitenlandse bedrijven, zoals geothermische energie in het geval van hernieuwbare energie, wetende dat dit soort activiteiten sterk varieert al naargelang de plaats (Figuur 2).

Figuur 2. Schending van het definitiedomein of ‘warning’ die een monitoring vergt

In dit geval is het niet altijd mogelijk om na te gaan of de waarden van de database automatisch gecorrigeerd werden. Wanneer er namelijk een inconsistentie opduikt tussen een waarde die is ingevoerd in de database en de referentietabellen die zijn gebruikt om de geldigheid ervan te testen, kan het noodzakelijk zijn om, wanneer het van strategisch belang is, een intellectuele verificatie uit te voeren door bijvoorbeeld contact op te nemen met de betreffende burger of onderneming. Dit is onder andere waar de waarde van een ATMS ligt, met het oog op het registreren en historiseren van anomalieën en transacties, zodat ze voortdurend statistisch kunnen worden gecontroleerd en, indien nodig, het toepassingsgebied kan worden aangepast.

De aanpak is zeer efficiënt omdat ervaring aantoont dat ze berust op het  Pareto-principe (80/20): veel problemen kunnen opgelost worden zodra we een klein aantal elementen geïdentificeerd hebben die aan de oorsprong liggen. 

De administratieve sector kent een overvloed van zulke  fenomenen. Op 4 maart 2020 heeft het Franse Hof van Cassatie de relatie tussen Uber en een zelfstandige ex-chauffeur opnieuw gekwalificeerd als arbeidsovereenkomst. Deze beslissing verspreidde zich al in de VS in Californië waar er een proces gehouden werd in augustus 2020 dat een bedreiging vormde voor de Amerikaanse reus Uber.  In juridische termen zou het binaire systeem van werk in loondienst en werk als zelfstandige dus kunnen worden uitgebreid om flexibiliteit maar ook sociale bescherming voor deze werknemers te garanderen, wat niet mogelijk is met persoonlijk ondernemerschap dat de band van ondergeschiktheid uitsluit. Dat is al het geval in bepaalde landen, zo staat in het Arrest, zoals in “ … Italië (overeenkomsten voor “collaborazione coordinata e continuativa”, “collaborazione a progetto”)”. Naast de wetgevende impact op administratieve databanken, zal de definitie van de status van werknemer waarschijnlijk stilaan beïnvloed worden door deze beweging, vooral door de arbeidsmobiliteit en de globalisering. De kwestie is steeds actueler in de VS en in Europa, in het kader van de tweede lockdown eind 2020 waar deze sector sterk bij betrokken is. 

Twee ‘use cases’

In onze aanpak (het prototype berust op de “open data” van de KBO) zijn de clientdatabase en het ATMS beide toegankelijk voor de (technische en business) agenten die ervoor verantwoordelijk zijn, hoewel ze logischerwijze gescheiden zijn (Figuur 3).

De eerste use case (Figuur 3) laat zien dat gegevens die door een verzender worden ingevoerd, afhankelijk van de keuzes die de business maakt, zowel wat betreft soorten anomalieën als wat betreft scenario’s voor het opsporen en afhandelen ervan (validatie door “business rules”):

• Verworpen kunnen worden;
• Geregistreerd kunnen worden in de clientdatabase;
• Verstuurd kunnen worden naar het ATMS ter correctie, en teruggestuurd naar de clientdatabase.

Al deze handelingen en hun kenmerken wordengeregistreerd en gehistoriseerd met het oog op een monitoring, zoals we later nog zullen terugzien.

In de tweede use case (Figuur 4) en in dezelfde omgeving worden vooraf goedgekeurde registraties in de clientdatabase ongeschikt bevonden door een menselijke interpretatie (een inspectie, bijvoorbeeld). Aangezien er een nieuw geval ontdekt werd, vergt de verwerking ervan een voorafgaande versiewijziging (overgang van versie 1 naar versie 2 van de toepassing en van de database) alvorens deze gewijzigd kan worden via het ATMS en ingevoerd in de database.

 

 

Figuur 4. Use Case B: interpretatie en wijziging van een record, gelinkt aan een nieuwe versie van het schema van de database van de toepassing (definitiedomein).

Het ATMS is op die manier noodzakelijk om de ‘backtracking’-methode in te voeren:

• niet alleen om via een permanente monitoring de anomalieën te identificeren die in overweging genomen moeten worden (naargelang het aantal en de uitdagingen die ze met zich meebrengen);
• maar ook als basis van structurele oplossingen voor bepaalde problemen als het gaat om interpretatie van de gegevens (vanuit het onderzoek van de overeenstemmende validatiegevallen).

Het ATMS zal eveneens ervoor zorgen dat er meerdere permanente maatregelen kunnen ingevoerd worden die nuttig zijn om administratieve bronnen voor statistische doeleinden te gebruiken, bijvoorbeeld:

• De stabilisatietijd van de database bepalen, terwijl gespecificeerde anomalieën worden verwerkt, naargelang de behoeften, en het meest gepaste moment om er een momentopname van te maken voor andere doeleinden.
• De anomalieën identificeren die nooit verwerkt (noch gecorrigeerd, noch gevalideerd) zouden worden.
• De ‘pieken’ identificeren van anomalieën en validaties (die mogelijk een herstructurering van het definitiedomein van de database met zich kunnen meebrengen);
• …

Functionele specificaties

Om deze aanpak te ondersteunen zijn er meerdere vereiste voorwaarden als de uitdagingen en de beschikbare budgetten dit rechtvaardigen (voorbeeld: er is intellectuele mankracht nodig om de anomalieën te verwerken), zoals gezamenlijke identificatie en specificatie met de databaseverantwoordelijken met het oog op een nuttige latere implementatie:

• Strategische anomalieën: op het eerste gezicht richt de aanpak zich op systematische gevallen maar ze kan ook een klein aantal ‘zeldzame’ en opkomende gevallen omvatten die bijzonder gevoelige anomalieën betreft, zoals hierboven vermeld.
• Duidelijke en gedocumenteerde procedures, ondersteund door een bevoegde organisatie die business- en IT-verantwoordelijken betrekt, betreffende de opsporing en de verwerking ervan in de tijd (correctie, validatie, interpretatie van een waarde zonder enige schending van integriteitsbeperkingen, enz.).
• Duidelijke en gedocumenteerde procedures voor het regelmatig produceren van kwaliteitsindicatoren om het beheer van de database te monitoren en te ondersteunen bij voortdurende veranderingen in de gegevens die worden verwerkt en in de omgeving.

We gaan nu bekijken hoe deze elementen technisch vertaald kunnen worden in de praktijk op operationeel niveau via een ATMS-prototype.

Technische elementen van het prototype

De implementatie van het relationele ATMS-prototype stelt een standaardisering voor van het beheer van de anomalieën dat gescheiden wordt van de clientdatabase (Figuur 5).

 

Figuur 5. Scheiding tussen het beheer van anomalieën en het clientgedeelte (businesstoepassing en -database)

De businesstoepassing spoort dan de anomalieën op en de routing ervan naar het ATMS (Figuur 3 en 4) voor verwerking. Deze architectuur biedt een reeks voordelen op korte en lange termijn:

• De modellering van de clientdatabase beperkt zich tot het vertegenwoordigen van louter businessconcepten, zonder tussenkomst van de bijbehorende anomalieën en metadata.
• Eenmaal in productie blijft de clientdatabase voortdurend compliant met het definitiedomein en kan daarmee evolueren.
• Het ATMS kan een herbruikbare tool worden waaraan het beheer van de anomalieën en de verwerkingen ervan systematisch gedelegeerd kunnen worden, waardoor schaalvoordelen mogelijk zijn en zo op natuurlijke wijze good practices verspreid worden in een organisatie.

Daarom vinden we binnen het ATMS een DB die ontworpen is om zich aan te passen aan elke relationele database of afwijkende datastructuur van een klant.

ATMS modelleren

De database van het ATMS bestaat uit twee essentiële delen (figuur 6):

• De beschrijving van het definitiedomein: hier worden metadata opgeslagen die het definitiedomein beschrijven, in de vorm van het schema van de clientdatabase (metadatabase die de tabellen, kolommen, primaire en vreemde sleutels, enz. in de clientdatabase beschrijft) en de toepassingsversie.
• Het beheer van de anomalieën en transacties: hier worden anomalieën opgeslagen die door de applicatie zijn verzonden, samen met de databaseobjecten waarnaar deze anomalieën verwijzen (tabellen, betrokken kolommen) en een grote hoeveelheid gedateerde metadata over de verwerking van anomalieën (type verwerking zoals correctie of validatie, verwerkingsauteur, resultaat, anomalieënstatus, enz.).

Figuur 6. De twee delen waaruit de ATMS-database bestaat

Elke anomalie verwijst dan naar het definitiedomein dat van kracht is op het moment dat ze verstuurd wordt in het ATMS. Indien het definitiedomein gewijzigd wordt, maar de anomalie wacht nog steeds op verwerking door een agent, dan wordt ze naast de oude versie automatisch verbonden aan de nieuwe versie van het definitiedomein.

Deze keuzes bieden een aanzienlijk voordeel voor het wijdverspreide gebruik van ATMS: het kan worden geïntegreerd in een informatiesysteem zonder enige wijziging aan de clientdatabase, met uitzondering van de toevoeging van één enkele technische tabel. Die heeft als enig doel om de toepassing in staat te stellen om eenvoudig de historiek van een record in de clientdatabase op te vragen met behulp van zijn bedrijfsidentificatie of anomalie-identificatie.

Met het oog op deze rijke interne structuur biedt ATMS niettemin eenvoudige technische interfaces, waarmee de toepassing bijvoorbeeld anomalieën die in het systeem binnenkomen kan registreren en het resultaat van de verwerking van een anomalie door een agent kan ophalen.

Communiceren met het ATMS

In het kader van het prototype werden de communicatie-interfaces met het ATMS geïmplementeerd in de vorm van opgeslagen procedures. In de praktijk zouden deze procedures, in een grootschalig project, de vorm aannemen van REST API endpoints aan de kant van ATMS maar ook van die van de client (figuur 7).

Figuur 7. Overzicht op hoog niveau van de architectuur van een informatiesysteem dat ATMS integreert

Aan clientkant heeft de toepassing toegang tot functionaliteiten zoals:

• Het genereren, vanuit de clientdatabase, van een beschrijving van de structuur in de vorm van een JSON-bericht dat leesbaar is door het ATMS.
• En de creatie van JSON-berichten waarmee in een tweede stadium de registratie van een anomalie mogelijk is met de betrokken gegevens in het ATMS.

Aan ATMS-kant heeft de interface een dubbele functie:

• De uitwisseling van anomalieën en metadata: de interface leest de binnenkomende berichten en voedt de gepaste tabellen van het ATMS, ofwel inzake definitiedomein ofwel inzake beheer van de anomalieën en transacties, afhankelijk van het geval. Hiermee kan het resultaat van de verwerking van een anomalie door een agent opgevraagd worden.
• De verwerking van anomalieën: de interface stelt functies beschikbaar die kunnen worden aangeroepen door een frontend ontworpen voor business agents die anomalieën verwerken (corrigeren, valideren, enz.).

Backtracking en ROI

Op basis van de monitoring van de anomalieën en transacties kan een ‘backtracking’ gedaan worden om de oorzaak van prioritaire anomalieën voor de business te vinden en aan de bron aan te pakken zodat ze later niet meer voorkomen.

Figuur 8. Monitoring van de verwerking van anomalieën

Figuur 9. Backtracking op basis van monitoring: de oorzaak van de belangrijkste anomalieën in het proces vinden en ze aan de bron corrigeren opdat deze anomalieën niet meer voorkomen

De twee volgende figuren geven weer: 

• de ROI van een ATMS gekoppeld aan een backtracking die het aantal anomalieën vermindert en de kwaliteit van de gegevens verbetert. 
• een beslissingsboom waarmee je kan weten of een ATMS nodig is om de kwaliteit van een informatiesysteem te verbeteren. 

Het ATMS dat we net beschreven werd geïmplementeerd bij Smals door een samenwerking tussen de teams Onderzoek en Databases. Dit prototype implementeert de database van het ATMS volledig alsook de functionaliteiten om JSON-berichten te genereren en verwerken binnen twee PostgreSQL-databases (client en ATMS). Eender welk RDMBS dat de verwerking van gegevens in JSON-formaat ondersteunt zou echter geschikt kunnen zijn.

Het prototype van het ATMS werd getest in het kader van een informatiesysteem dat gesimuleerd werd door een toepassing in Python en een clientdatabase die bestaat uit alle open data van de KBO. Vier realistische gebruiksscenario’s werden ingevoerd:

• Correctie van een eenvoudige gegevensanomalie.
• Correctie van een anomalie van twee incompatibele registraties, een al aanwezig in de clientdatabase en de andere die het informatiesysteem probeert binnen te raken.
• Validatie van anomalieën in batch: verspreiding van de validatie van een anomalie naar een reeks andere, gelijkaardige anomalieën aangeduid door een agent.
• Meerdere monitoringviews van anomalieën en de historiek ervan, met het doel om ATMS-gebaseerde backtrackings te voeren.

Links met data quality tools van Smals zouden eveneens overwogen kunnen worden. Deze tools bieden, met hun profilingcapaciteiten, standaardisering van data (onder andere maar niet enkel signaletieken) en van matching, technische mogelijkheden om het menselijk beheer van anomalieën via een ATMS te ondersteunen.

Talrijke contacten werden opgenomen en zijn lopende met meerdere projectteams die het belang van het gebruik en de geleidelijke uitbreiding van ATMS inzien. 

Een meer professionele ontwikkeling volgde hierop en stelt de volgende functionaliteiten voor:

---

Deze post is een gezamenlijke bijdrage van Isabelle Boydens, Data Quality Expert bij Smals Research, Gani Hamiti, Data Quality Analyst bij Smals, Databases Team en Rudy Van Eeckhout, Databases R&D bij Smals, Databases Team. Dit artikel is geschreven onder hun eigen naam en weerspiegelt op geen enkele wijze de standpunten van Smals.