In deze serie van blogs sta ik stil bij de nog steeds geldige informatiekundige constructieprincipes die garant staan voor betere “informatiebouwwerken”. Ze zijn soms, in de vaart van de voortschrijdende technologie, een beetje vergeten. Met als gevolg soms wankele of slecht onderhoudbare en uitbreidbare “informatiebouwwerken”. Deze keer over de noodzaak van het enkelvoudig vastleggen van stamgegevens en de uitdagingen die dit oplevert ten aanzien van gebruik. Is kopiëren een probleem?
Verschillende soorten gegevens
Gegevens zijn er in verschillende soorten als je ze beziet vanuit de informatiehuishouding van een organisatie.
Stamgegevens (of masterdata) zijn de kerngegevens over personen, adressen, producten, artikelen en alle andere objecten waar een organisatie steeds opnieuw gegevens van gebruikt bij het vastleggen van processen of transacties. Stamgegevens wijzigen zelden en vormen de vaste gegevens van een object (als stamgegevens wel wijzigen – iemand wijzigt bijvoorbeeld zijn achternaam of de kleur van een voertuig wijzigt – is het van belang om ook de relatie tussen de oude en nieuwe stamgegevens te bewaren zodat duidelijk is dat het nog over hetzelfde object gaat! Maar het voert te ver om dit aspect van stamgegevensbeheer hier nu uit te werken).
Stamgegevens kan een organisatie zelf beheren (intern) of van een andere organisatie of externe bron betrekken; we spreken dan van referentiele gegevens; stamgegevens die buiten de eigen organisatie worden beheerd en onderhouden. Denk bijvoorbeeld aan een lijst met landencodes. Maar ook de basisregistratie personen (BRP) bevat, bezien vanuit een afnemer, de referentiele gegevens van een persoon voor die afnemer. En de BRP zelf gebruikt weer de BAG om adressen als extern stamgegeven aan een persoon te koppelen. Hier ontstaan ook de problemen als iemands woonadres als een stamgegeven wordt beschouwd. Strikt genomen is het dat niet want het kan wijzigen. De vastlegging van het woonadres van een persoon is een transactiegegeven. De basisregistraties bevatten dus ook transactiegegevens![1]
Alle vastgelegde transacties, zoals orders, leveringen, facturen, of levensgebeurtenissen bevatten transactiegegevens. Deze zijn een momentopname van een gebeurtenis of rechtsfeit en beschrijven specifiek die gebeurtenis als gestolde werkelijkheid. Ze zijn opgebouwd uit de combinatie van stamgegevens/referentiele gegevens en gegevens die de transactie beschrijven. Bijvoorbeeld als iemand gehuwd is, verhuisd is of een diploma heeft behaald.
De beschrijving van de hele gegevensverzameling zelf noemen we metagegevens. Dit is een belangrijk onderdeel van de “administratie” van gegevens.
Tenslotte kan vanuit de registratie van de transactiegegevens een analyse worden gedaan om te komen tot nieuwe gegevens; analysegegevens (trends, verbanden etc). Bijvoorbeeld het feit dat een klant dit jaar tien bestellingen heeft gedaan of dat de omzet in een periode met 10% is gestegen.
Gegevens als geregistreerde afspiegeling van de werkelijkheid
In een registratie vormen gegevens een afbeelding van een gebeurtenis in de werkelijkheid. Het doel van de registratie bepaalt wat we van de werkelijkheid willen vastleggen. Verschillende organisaties (of afdelingen binnen een organisatie) kunnen van hetzelfde object verschillende gegevens registreren. Wel kunnen ze afspreken dat dezelfde set stamgegevens van het object wordt gebruikt. Ziedaar een toepassing van de basisregistraties als het om de geregistreerde objecten gaat; personen, bedrijven, voertuigen, adressen. De stamgegevens in de basisregistraties vormen referentiele gegevens voor de transacties van een dienstverlener (dat de basisregistraties ook transactiegegevens bevatten laat ik hier verder buiten beschouwing maar verdient een aparte discussie. Je wil die soorten gegevens eigenlijk niet vermengen).
Het belang van enkelvoudige registratie zit in de wens dat van één object maar op één plek de stamgegevens worden bijgehouden zodat dit aspect van de werkelijkheid hetzelfde is voor alle afnemers (intern en extern) en de afnemer ook weet dat het over hetzelfde object gaat. Afnemers mogen de stamgegevens of referentiele gegevens niet wijzigen, alleen gebruiken, en noodzakelijke aanpassingen mogen alleen worden doorgevoerd door de bronhouder of beheerder van de stamgegevens. Verkeerde gegevens moeten worden gemeld aan de bronhouder zodat de actualiteit voor alle afnemers op peil blijft.
Stamgegevens dupliceren of niet?
In de praktijk roept enkelvoudige registratie een paar vragen op. Mag je referentiele gegevens in je eigen informatiehuishouding vastleggen als kopie? Is er dan nog sprake van enkelvoudige vastlegging? En als ik de gegevens zelf niet registreer kan ik dan vertrouwen op de kwaliteit en beschikbaarheid van de bron?
Het uitgangspunt is dat stamgegevens actueel moeten zijn als je ze gebruikt bij een transactie voor een juiste weergave van de werkelijkheid. Als je ze zelf beheert heb je die actualiteit zelf in de hand. Maar wat als je ze bij een ander betrekt?
Niet dupliceren maar verwijzen!
Een bekend oud NORA-architectuurprincipe luidde “Enkelvoudige vastlegging meervoudig gebruik”. Dit is inmiddels vervangen door “Informeer bij de bron”. Hieraan is door de NORA de implicatie verbonden dat je beter kunt verwijzen naar die brongegevens in plaats van een kopie uit die bron vast te leggen in je eigen administratie.
Dat klinkt logisch maar naar mijn mening moet je in veel gevallen wèl een kopie maken van de stamgegevens. De stamgegevens vraag je op een tijdmoment op om ze te registreren als onderdeel van een transactie. Dan moeten ze actueel zijn en daarna niet meer wijzigen. Zou je een verwijzing gebruiken die altijd naar het actuele gegeven verwijst dan kom je in de problemen als later de stamgegevens wijzigen want dan wijzigt ook je transactie en klopt deze niet meer met de werkelijkheid van toen. Denk aan mensen die hun achternaam wijzigen, een auto die wordt overgespoten etc.
Gebruik maken van een verwijzing naar de bron in plaats van lokaal vastleggen stelt zeer hoge eisen aan de bronhouder die de historie van een gegeven in de verwijzing moet meenemen en deze tot in lengte van dagen moet kunnen leveren met een beschikbaarheid die de afnemer vraagt.
Het betekent ook dat de eigenaar van de transactiegegevens niet een eigenstandige registratie kan voeren en voortdurend afhankelijk is van de bronregistratie. Hoe kun je dan de verantwoordelijkheid nemen voor de eigen informatiehuishouding?
Stamgegevens moet je kopiëren als ze onderdeel worden van transactiegegevens!
Niet verwijzen maar dupliceren!
Als stamgegevens actueel moeten zijn is het af te raden om een eigen kopie te gebruiken die eerder is “opgehaald”. Voor transacties geldt voor stamgegevens altijd het principe van “informeer bij de bron(houder)”. Je moet op dat moment synchroniseren met de registratie waarin de stamgegevens vastliggen. Maar er kan reden zijn om een eigen “kopie” van de stamgegevens bij te houden. Het gebruik van externe stamgegevens creëert namelijk een afhankelijkheid. Dit kan ongewenst zijn vanwege de gevraagde hoge performance of beschikbaarheid van een systeem vanuit het bedrijfsproces.
Het is dan zaak om de eigen kopie synchroon te houden met de bron. Dat kan technisch op vele manieren en de eisen aan de actualiteit bepalen dan meestal welke manier de beste is. Bijvoorbeeld een push door de bronhouder van gewijzigde gegevens zodra die worden geregistreerd naar de kopie. Of een periodieke synchronisatie met een frequentie die voldoende is voor de actualiteit die het proces vraagt (eenmaal per 24 uur bijvoorbeeld).
Tenslotte moeten bronhouder en afnemers sluitende organisatorische en juridische afspraken maken om elkaars registratie te gebruiken en te vertrouwen op de gegevenskwaliteit (in geval van de basisregistraties zelfs vastgelegd in wetten en twaalf eisen). Dit kost soms meer inspanning dan het zelf registreren van stamdata. In het uiterste geval zal een organisatie toch kiezen voor eigen registratie als de kwaliteit en beschikbaarheid van de referentiele gegevens onvoldoende is voor het eigen proces.
Conclusie
Stamgegevens op één plek registreren en beheren als uitgangspunt staat buiten kijf (mits ze de vereiste kwaliteit hebben). Maar mag je stamgegevens dupliceren? Het hangt ervan af! De informatiekundige moet zich bewust zijn van de eisen die het proces stelt aan de actualiteit van een intern of extern stamgegeven en op basis daarvan zijn ontwerpkeuze maken. Naast actualiteit spelen ook performance (tijdigheid), beschikbaarheid en legitimiteit (verantwoordelijkheid) een rol. En de kosten en baten. Eén centrale ICT-voorziening die voor alle afnemers voldoet, is een architecturale utopie en in de praktijk niet mogelijk.
[1] Merk op dat in het stelsel van basisregistraties het gebruikte begrip “authentiek gegeven” niet in deze indeling voor komt. Dit is gedefinieerd als een gegeven dat in een basisregistratie is opgenomen en dat bij wettelijk voorschrift als authentiek is aangemerkt. Het kan zowel een stamgegeven, een referentieel gegeven als een transactiegegeven zijn! Referentiele gegevens die uit een bron buiten het stelsel komen (zoals postcodes) worden in de basisregistraties een “niet-authentiek gegeven” genoemd.
Andere blogs uit deze serie:
De 1ste blog, over betekenisloze identiteitsaanduiding, lees je hier.
De 2de blog gaat over het principe van ontkoppelpunten in het ontwerp en lees je hier.
De 3de blog gaat over eenduidige en consistente taal: link.
De 4de blog gaat over verantwoordelijkheidsverdeling en functiescheiding: link.
De 5de blog gaat over dat de verantwoordelijkheid voor besluiten zo laag mogelijk in de organisatie moet liggen: link.
De 6de blog gaat over aantonen “wie je bent” loskoppelen van “wat je mag”: link.
De 8de blog gaat over data en metadata scheiden in opslag en verwerking: link.