In een vorige post ‘Eerst leren kruipen, dan leren stappen en uiteindelijk leren lopen’ had ik het onder meer over het verschil tussen data en informatie.

Daarop kreeg ik een reactie dat mijn verhaal aldaar wel erg basaal is voor de elite aan datamodelleerders (datamodelleurs in Nederland) die bijdragen leveren aan het Data Model Collective. En dat is ook zo. De website van het Data Model Collective is echter toegankelijk voor iedereen, niet enkel voor de elite aan datamodelleerders.

Bovendien reken ik mezelf niet tot de elite aan datamodelleerders waarvan sprake in de reactie en spreek ik eerder voor de modale datamodelleerder.

Daarenboven zou het wel eens kunnen dat de elite aan datamodelleerders mijn boodschap niet 100% begrepen heeft of 100% op waarde ingeschat heeft. Iets wat ik begrijp aangezien ik vertrek vanop het werkveld dat ver verwijderd is van de elite.

En nu ‘to the point’:

Bij datamodellering zie je vaak dat losse waarden (data) worden opgeslagen in plaats van de volledige betekenis (informatie). Veelvoorkomende voorbeelden zijn temperaturen zonder eenheid, datums zonder tijdzone of context, telefoonnummers zonder landcode, aantallen zonder meeteenheid, tekstvelden die meerdere concepten bevatten en statusvelden zonder betekenis of context. En dit zijn slechts enkele voorbeelden.

Dergelijke datamodellen missen semantiek, omdat ze niet opgewaardeerd zijn tot informatiemodellen. Dat gemis aan semantiek dient dan opgevangen te worden in één of andere vorm van applicatiecode, wat eigenlijk not done is als het al mogelijk is. Uiteindelijk dienen we te streven naar informatiemodellen en onszelf te promoveren van datamodelleerder to informatiemodelleerder.

Klassieke voorbeelden van Data versus Informatie

• Temperatuur of gewicht: Alleen een getal opslaan zonder eenheid (Celsius/Fahrenheit of kilo/pond) maakt de waarde onbruikbaar in een uitgebreidere context.
  
  Overigens geldt dit voor alle fysische eenheden zoals ook lengte en afstand, oppervlakte, volume, snelheid, versnelling, kracht, arbeid, vermogen, energieverbruik en nog veel meer.

• Datum en tijd: Alleen een datum zoals 21-10-2026 opslaan zonder te weten of dit een aanmaakdatum, vervaldatum of geboortedatum is, en zonder tijdzone.
• Telefoonnummer: Alleen een reeks cijfers zoals 0612345678 opslaan zonder landcode (+32 of +31) of aanduiding of het om mobiel, werk of privé gaat.
• Persoonsnaam: Een enkel tekstveld ‘Naam’ gebruiken in plaats van de tekstvelden ‘Voornaam’, ‘Familienaam Voorvoegsel’ en ‘Familienaam’, waardoor formele e-mails of sortering onmogelijk worden.
• Organisatienaam: Een enkel tekstveld ‘Naam’ gebruiken in plaats van de tekstvelden ‘Organisatienaam’ en ‘Rechtsvorm (NV, BV, …), waardoor formele e-mails of sortering onmogelijk worden.
• Adres: Een vrij tekstveld voor een ‘Adres’ in plaats van losse tekstvelden voor ‘Straat’, ‘Huisnummer’, ‘Busnummer’, ‘Postcode’, ‘Woonplaats’ en ‘Land’.
• Aantallen: Alleen een cijfer opslaan zonder meeteenheid (stuks, kilogram, liter, …).
• Korting of marge: Alleen een cijfer opslaan zonder specificatie of het om een percentage of een vast geldbedrag gaat.
• Bestelstatus: Een getal of losse tekst (2 of ‘deels geleverd’) opslaan in plaats van een gekoppelde referentietabel met de betekenis, overgangsregels en datum van de statuswijziging.
• …

Tijdens mijn 40-jarige carrière als datamodelleerder ben ik ontelbare keren geconfronteerd met dergelijke fouten tegen het modelleren van data in plaats van het modelleren van informatie.

Het is een van de meest hardnekkige oorzaken van ‘technische schuld’ en datakwaliteitsproblemen in IT-systemen.

Ontwikkelaars en analisten modelleren vaak snel voor de huidige use-case (“we verkopen nu toch alleen in euro’s”), waardoor ze vergeten dat een systeem later moet groeien of gekoppeld moet worden. Dit wordt eveneens ingegeven door agile software development, waar sprint per sprint enkel gebouwd wordt wat momenteel nodig is.

Waarom dit in de praktijk zo vaak misgaat

• De “Nu- en Hier-Focus”: Bij de start van een project is de scope vaak lokaal. Pas jaren later, bij internationale uitbreiding, ontdekt men dat het hele systeem omgebouwd moet worden omdat de valuta en/of landcode ontbreekt.
• Database-gemak en -luiheid: Het gaat sneller om één tekstveld Adres te maken dan zes aparte tekstvelden. Pas bij de koppeling met een postbezorger loopt het mis.
• Onzichtbare aannames: Ontwikkelaars die in dezelfde tijdzone of regio zitten als de gebruikers, gaan er onbewust van uit dat iedereen dezelfde standaarden gebruikt.

Gevolgen in de praktijk

• Kostbare en tijdrovende migraties: Het achteraf splitsen van een veld ‘Naam’ naar ‘Voornaam’, ‘Familienaam Voorvoegsel’ en ‘Familienaam’ kost vaak tienduizenden euro’s of meer aan handmatige opschoning en complexe scripts. Bovendien wordt er bij die migraties veel tijd verloren die beter besteed zou kunnen worden aan het implementeren van nieuwe functionaliteiten.
• Fouten en zelfs fatale fouten: Het bekendste internationale voorbeeld is de Mars Climate Orbiter (1999) van de NASA. Deze sonde ging verloren omdat het ene softwareteam met Amerikaanse eenheden (inches/pounds) rekende en het andere met metrische eenheden (centimeters/kilo’s), zonder dat de eenheid in de data was vastgelegd.
• Rapportage-ellende: Systemen die data aggregeren (zoals Data Warehouses) lopen volledig vast als ze 10 (euro) en 10 (dollar) of 10 (procent) met elkaar moeten vergelijken.

Ik veronderstel dat de elite aan datamodelleerders die bijdragen leveren op dit Data Model Collective bestaat uit professoren, lesgevers op hogescholen, data architecten en andere specialisten in datamodellering.

Mijn vraag aan die elite is dan ook ervoor te zorgen dat het verschil tussen datamodellering en informatiemodellering op de werkvloer ongedaan gemaakt wordt. Enkel informatiemodellering is daarbij goed genoeg.

Dat zou ook Paul Van Vliet ‘leuke dingen voor de mensen’ genoemd hebben…