Constructieprincipes voor de informatiekundige (1): betekenisloze identiteitsaanduiding
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”. Als eerste sta ik stil bij de voordelen om een identiteitsaanduiding betekenisloos te houden.
Informatieobjecten in een administratie wil je uniek kunnen identificeren. Zo kun je ernaar verwijzen en kenmerken van dat object koppelen aan één en hetzelfde “ding” of “recht”. Denk bijvoorbeeld aan objecten als “klant”, “voertuig”, “organisatie”, “bankrekening”, “telefoonnummer”, maar ook aan documenten als “eigendomsbewijs”, “paspoort” en “rijbewijs”. Dus krijgen ze een unieke identiteitsaanduiding. Waarom is het zo belangrijk om de identiteit betekenisloos te houden?
Bij de invoering van het SEPA betalingsverkeer was het noodzakelijk om rekeningnummers uniek te maken over landen en banken heen. Bij 1 rekeningnummer moest maar 1 rekening horen. Met als doel om het betalingsverkeer te vereenvoudigen tussen landen. De gekozen codering – een landcode, een bankcode en een nummer- bevatte uiteindelijk betekenis. Daarmee was het doel van unieke nummers wel bereikt maar was een andere mogelijkheid overboord gezet; namelijk portabiliteit van je rekeningnummer! Als we ooit zouden willen bereiken dat je (net als bij mobiele telefonie) je rekeningnummer kunt meenemen naar een andere bank dan is deze codering ongeschikt. Immers de bankcode zit erin verwerkt. Dit voor de consument nadelige gevolg was (bewust of onbewust) vergeten maar het is frappant dat hierover nooit een fatsoenlijke discussie is gevoerd vanuit informatiekundig oogpunt en belangen van de consument.
Een ander voorbeeld is het privé emailadres als unieke aanduiding van een “postbus” of identiteit. De extensie na de @ is nu vaak een verwijzing naar de provider en de aanduiding ervoor kan iets prijsgeven over de persoon. Dat kan bewust zijn voor herkenbaarheid maar met dat emailadres kun je niet zomaar naar een andere leverancier stappen. Terwijl het wel vaak een identiteitsaanduiding is van jou als persoon die je overal op het web gebruikt. Als morgen Google of Microsoft stopt met zijn emailservice hebben veel mensen een probleem, of er komen in elk geval heel veel doorzendinstructies. Als je weet dat de extensie achter de @ een koppeling is naar het internetadres van de emailserver dan zou je ook kunnen streven naar een emailextensie waarbij die koppeling aanpasbaar is zonder de extensie te veranderen (zoals bij een eigen domein extensie).
Het kan natuurlijk voordelen hebben om betekenis en informatie in een identiteit te stoppen maar in de regel kun je die informatie ook op een andere wijze koppelen aan het object. Een verkeerde keuze van de codering kan dus voor andere toepassingen grote gevolgen hebben of beperkingen met zich meebrengen. Daar moet je je in elk geval van bewust zijn als je voor de keuze staat. Zeker als er persoonsgegevens in een code sluipen. Stel je voor dat destijds was gekozen om mijn BSN te coderen als NLADAM27121966-1234. Dan zouden mijn nationaliteit, geboorteplaats en geboortedatum al bekend zijn met louter mijn BSN. Terwijl het wel een unieke code is als je ervan uit gaat dat er niet meer dan 9999 kinderen op één dag in Amsterdam worden geboren. Dan had het BSN lang niet zo breed toegepast kunnen worden als nu, vanuit oogpunt van privacy.
Wanneer het doel unieke identificatie is, zonder jezelf te beperken in het (toekomstig) gebruik van die identiteitsaanduiding, is het constructieprincipe voor de code daarom dat deze betekenisloos moet zijn.
Lees hier de andere informatiekundige principes:
- Betekenisloze identiteitsaanduiding, lees hier.
- Ontkoppelpunten voor complexiteitsreductie en flexibiliteit, maximale onafhankelijkheid van delen, lees hier.
- Consistentie van taal, lees hier.
- Duidelijke verantwoordelijkheidsverdeling en functiescheiding voor de administratie, lees hier.
- Beslissingsbevoegdheid voor de uitvoering zo laag mogelijk beleggen, lees hier.
- Autorisatie loskoppelen van identificatie/authenticatie, lees hier.
- Enkelvoudige vastlegging van stamdata, lees hier.
- Data en metadata scheiden in opslag en verwerking, lees hier.
- Standaardpatronen toepassen zonder afwijkingen, lees hier.
- Applicatiefunctie en dataopslag scheiden, lees hier.
- Apparaat onafhankelijk ontwikkelen, lees hier.
Gerelateerde insights
