Iedereen kent het wel, gegevenskwaliteit, of eigenlijk: het gebrek aan gegevenskwaliteit. Je doet een mailing de deur uit en enkele dagen later puilt je brievenbus uit met onbezorgbare post. Mensen zijn verhuisd, uit dienst of overleden. Een hele tak van industrie heeft zich hieromheen ontwikkeld. Ons 'eigen' Human Inference uit Arnhem heeft zich in die markt prima geweerd en is internationaal gereputeerd voor het 'schonen' van relatiebestanden.
Het valt op dat de oplossing zich vooral concentreert op symptoombestrijding: de verkeerde data wordt opgespoord en hersteld… Het lijkt erop dat we het probleem hebben aanvaard als een voldongen feit. Ik kom geen analyses tegen van het ontstaan van het probleem. Ik zal zelf een poging wagen.
Laat ik eerst gegevenskwaliteit definiëren. Gegevens zijn een representatie van een 'verschijnsel' in ons wereldbeeld: de naam en het adres van een klant, het loopbaanverloop van een medewerker, de kenmerken van een product. Gegevenskwaliteit is de mate waarin die gegevens overeenkomen met ons beeld van dat 'verschijnsel'. 'Kloppen de gegevens'? Vanuit dit uitgangspunt rijst dan de vraag waardoor gegevens kunnen afwijken van dat 'verschijnsel'? Met andere woorden: wat zijn de mogelijke oorzaken van gebrek aan gegevenskwaliteit?
Allereerst is er de tijd: gegevens verouderen en kunnen daardoor onjuist worden. Verhuizen, sterven, vervangen van een product, faillissement, verkopen van bezit, allemaal aanleidingen waardoor gegevens verouderen. Maar ook niet verouderde gegevens kunnen onjuist zijn: bij het invoeren kunnen (spel)fouten worden gemaakt of gegevens kunnen uit hun context zijn geplaatst en daardoor een verkeerde betekenis krijgen (bijvoorbeeld een post(bus)adres dat is aangemerkt als (bezoek)adres). Er zijn ongetwijfeld nog wel andere redenen. Er is echter één centrale oorzaak: de informatie wordt gekopieerd. Bij dat kopiëren kan het fout gaan omdat daar vaak menselijk handelen bij betrokken is (spelfouten en contextuele fouten) en na het kopiëren verouderen de gegevens.
Stel daarom het radicale standpunt: 'gegevens worden niet gekopieerd'. Ieder gegeven ontstaat een keer en heeft dus een bron en een eigenaar. Als iemand dat gegeven wil gebruiken neemt hij contact op met de eigenaar ervan. Er wordt bepaald in welke context het gegeven wordt gebruikt en of 't het juiste gegeven is. In plaats van het gegeven te kopiëren wordt een verwijzing naar het gegeven opgenomen. Elk gegeven komt nog maar 1 keer voor en als het wijzigt wordt het op 1 plaats gewijzigd. Iedereen die het gegeven nodig heeft haalt het op, op het moment dat het nodig is. Weg gegevenskwaliteitsprobleem.
Waarom gebeurt dat dan niet? Volgens mij heeft het een historische, een technologische en een informatiekundige oorzaak.
Historisch gezien was informatie gebonden aan een drager: in principe aan het papier waarop het was gedrukt of geschreven, of aan een persoon. Als informatie (min of meer gelijktijdig) op meerdere plaatsen werd gebruikt móest het worden gekopieerd. Zo'n patroon slijt zich diep in, ook in onze hersenen. Na dat inslijten vergt het heel veel creativiteit om daar weer van los te komen.
Technologisch gezien is het pas recent mogelijk om verspreide informatie snel op te halen. Voorafgaand aan het (performante) internet was het technologisch onmogelijk alle gegevens 'just in time' op te halen. Zelfs nu is het de vraag of een, op het 'niet kopiëren' gebaseerde toepassing, voldoende snel is.
Tot slot, informatiekundig gezien is er een tendens naar standaardisatie in plaats van erkenning van (betekenis)variëteit. Door de historische en technologische beperkingen is het nauwelijks voorstelbaar dat het loslaten van de wens tot uniformering tot een bruikbaar informatiemodel kan leiden. Ontwikkelingen als de CCTS van UN/CEFACT tonen aan dat het geloof in uniformering nog altijd hoogtij viert.
Kan het wel? Je zou natuurlijk ook kunnen vragen: waarom kan het niet? Zoals gezegd, het vergt creativiteit om het bestaande uitgangspunt los te laten. Wellicht dat een voorbeeld helpt.
Het voorbeeld.
Cruciaal in het concept is informatie-eigendom. Het gaat er vanuit dat alle informatie bij de bron wordt beheerd, of door de bron in beheer wordt gegeven. In het geval een gedeelde bron (van wie is de transactie tussen 2 partijen?) moet er 'iets' worden geregeld. De eerste complicatie waar ik nu gemakshalve overheen stap. Dus: elk gegeven heeft een bron en een eigenaar.
Laten we een gedachte-experiment uitvoeren rond 'mijn gegevens' bij de krant. De uitgever wil mijn naam en adres.
Ik ben een doorsnee Nederlander en heb maar 1 adres: ik maak geen onderscheid naar post of bezoek adres. Iedereen die mij wil bereiken kan dat doen op de Kneuterdijk 7 in Twello. De postcode? Die mag je zelf opzoeken ;-)
In het gedachte-experiment hanteer ik het radicale standpunt: 'informatie wordt niet gekopieerd'. In de plaats daarvan wordt een verwijzing naar de informatiebron opgenomen. Zo'n verwijzing noemt Pieter Wisse in [1] een informatiewijzer.
Aan iedereen die mijn adres vraagt geef ik de ingang van de informatiewijzer naar mijn adres.
De afnemer krijgt een ingang in de informatiewijzer toegewezen hetgeen wordt doorgeschakeld naar het gewenste gegevenselement. Vanaf dat moment wordt de informatie achter de informatiewijzer gebruikt. Het wordt niet gekopieerd, het wordt alleen gebruikt. En na gebruik mag het weer worden vergeten.
Als ik verhuis wijzig ik mijn adres (met een ingangsdatum!) achter de informatiewijzer en iedereen die met mij in contact wil treden krijgt vanaf de verhuisdatum de beschikking over mijn nieuwe adres.
De 'adreswijziging' is hiermee voor de buitenwereld volledig transparant geworden.
Op enig moment echter vat ik het plan op om 3 weken op Terschelling op vakantie te gaan. Daarbij wil ik graag mijn krantje blijven ontvangen. Echter, ik wil niet achtervolgd worden met alle rekeningen en andere referenties naar de minder plezierige kanten van het leven.
Merk op dat ik hiermee een verfijning van de context aanbreng: daar waar ik in eerste instantie mijn adressen op 1 hoop gooide breng ik een onderscheid aan. Naast het gebruikelijke 'woonadres' (het vaste adres waar ik doorgaans slaap) komt nu ook het 'verblijfsadres' (het wisselende adres waar ik gedurende kortere tijd verblijf). De context 'wonen' wordt pas expliciet door de toevoeging van de context 'verblijf'.
De informatiewijzer is zo ingericht dat ik (als leverancier van de informatie) inzicht heb in wie gebruik maakt van die informatie. Bovendien ben ik in staat de afnemer van context te laten wisselen (in bovenstaand voorbeeld blijven alle afnemers van mijn adres aangesloten op mijn woonadres en alleen de krant komt uit bij mijn verblijfsadres).
Dus configureer ik in mijn informatiewijzer een nieuwe adrescontext: ik maak onderscheid naar woon- en verblijfsadres. Alle bestaande afnemers merken niets van de toegevoegde context. Alleen de krant koppel ik aan het verblijfsadres; gedurende de periode dat ik op Terschelling ben wijzig ik het verblijfsadres in het adres van het hotel op Terschelling en voor het overige blijft het gewoon mijn woonadres.
In het geval van de krant maakt het de uitgever niets uit waar ik mijn krant bezorgd wil krijgen, zolang ik de factuur maar betaal. In dat geval zal hij dus zonder meer toestaan dat ik de context, waaruit hij de informatie betrekt, wijzig. Dat is vanzelfsprekend niet altijd zo eenvoudig. De afnemer heeft belang bij de informatie die hij afneemt en zal bepaalde garanties ten aanzien van de afgenomen informatie verlangen. Het begrip SLA krijg hiermee een nieuwe dimensie (zie [2], punten 11 en 12).
Er is nog een 'complicatie' die ik niet onbenoemd wil laten. Mijn adres is niet van mij maar (waarschijnlijk) van de gemeente. De gemeente zal als informatie-eigenaar een informatiewijzer beschikbaar moeten stellen waar mijn straatnaam achter schuil gaat. Zolang de gemeente de informatie niet als informatiewijzer ontsluit kan ik de keten van verwijzingen natuurlijk bij mij laten eindigen. Op die wijze kun je naar een 'kopieloze' informatie-infrastructuur toegroeien: Keulen en Aken zijn ook niet op één dag gebouwd.
De epiloog.
Het voorbeeld toont aan dat er nog het nodige geregeld moet worden om tot een werkbaar model te komen (zie [3]). Ik noem er een paar:
gedeelde verantwoordelijkheid van bronnen moet worden aangepakt;
identificatie, authenticatie en autorisatie moet worden ingericht; het moet dat over veel verschillende bronnen (en daardoor op een gestandaardiseerde manier) worden ingevuld;
de informatiewijzer infrastructuur moet worden ingericht; dit is uitgebreide en complexe infrastructuur, waarbij de in dit voorbeeld genoemde mogelijkheid om te kunnen zien wie van mijn adres gebruik maakt en de optie om gebruikers 'om te hangen' maar het topje van de ijsberg vormen; op het niveau van de informatiewijzer moet (internationaal!) worden gestandaardiseerd;
de stapeling van informatiewijzers moet werken (de verwijzing naar mijn adres verwijst zelf weer naar de gemeente); het is daarbij de vraag hoe hoog 'de stapel' aan verwijzingen wordt in een reële situatie; iedere schakel betekent een run-time opvraging, hetgeen qua doorlooptijd uit de kluiten kan wassen.
Het voorbeeld toont echter ook aan dat er voldoende aanknopingspunten zijn om het uit te proberen.
Referenties:
[1] Wisse, P.E., INFORMATIEVERKEER IN PUBLIEK DOMEIN, Schetsboek over architectuur en ontwikkelpaden voor de elektronische overheid, Programma architectuur elektronische overheid, 2004
Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present
balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not
permitted. Readers are requested to notify
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.
