Laat ik beginnen met het schetsen van een scenario dat menigeen bekend zal voorkomen. Een jonge organisatie, is ter ondersteuning van haar bedrijfsprocessen ooit begonnen met het bouwen van een eigen operationeel systeem. Dit systeem is samen met de organisatie meegegroeid. Wat ooit klein en overzichtelijk begon, is in de loop der tijd uitgegroeid tot een groot en complex systeem tjokvol met kennis die vitaal is voor het functioneren van de organisatie. In de loop der tijd hebben er verscheidene ontwikkelaars aan gewerkt. Deze zijn gekomen en gegaan met in hun hoofd belangrijke kennis over hoe het systeem werkt en hoe het met data omspringt. Er is nooit veel gedaan aan kennisborging. De focus heeft altijd vooral gelegen op het snel inspelen op nieuwe ontwikkelingen en het zo goed mogelijk bedienen van klanten. Zo nu en dan was daarvoor een snelle praktische (lees quick en dirty) oplossing nodig. Het systeem is keer op keer verder uitgebreid om aan de veranderende eisen van de business te kunnen voldoen. Gevolg is dat inmiddels niemand meer het overzicht heeft van hoe het systeem in elkaar zit. Dit maakt het maken van aanpassingen steeds lastiger.

Ook is het niet al te best gesteld met de datakwaliteit. Dit alles komt pijnlijk duidelijk naar voren nu men managementinformatie wil gaan onttrekken aan de data in het systeem. Hoe kan dit ontstaan? Een verklaring zou kunnen zijn dat in het begin toen de organisatie nog klein en overzichtelijk was er nog geen behoefte was aan een dichtgetimmerd systeem dat data integriteit  afdwong. Data ging toen nog niet door vele handen zoals nu en er was overzicht. Het was belangrijker dat het systeem flexibel en open was zodat snel kon worden ingespeeld op de behoeften van de klant.

Inmiddels is de organisatie gegroeid en komt men erachter hoe afhankelijk men eigenlijk is geworden van dit systeem. Jarenlange ervaringen met klanten en de markt liggen er op een of andere manier in vastgelegd. De organisatie beseft dat er iets moet gebeuren. Maar wat? Hieronder volgen enkele tips die helpen grip te krijgen op deze situatie.

Tip: Weet wat je hebt

Allereerst moeten we weten wat we hebben. Het aanleggen van een data dictionary is een goede eerste stap. Ga op tabel en veldniveau beschrijven wat de functie ervan is. Deze informatie zal her en der uit de organisatie bij elkaar moeten worden geschraapt en op een centrale plek, de data dictionary worden vastgelegd.

Tip: Stel definities op

Kijk naar de business en identificeer de concepten (entiteiten) waar het om draait. Beschrijf vervolgens exact hoe deze concepten mappen met data in het systeem. Voorbeeld: Een actief abonnement bestaat uit een record in de tabel tbl_abonnement waarvan het veld einddatum leeg is. Dit record is via het veld relatie_id gekoppeld aan een record in de tabel tbl_relatie dat weer aan een record uit de tabel tbl_adres gekoppeld is via het veld relatie_id. Doe dit voor alle concepten.

Tip: Maak zaken telbaar.

Nu we definities hebben opgesteld van de belangrijkste concepten kunnen we als volgende stap de regels opstellen over welke dataitems wel en welke niet samen mogen gaan. Deze regels (ik noem ze ook wel declaratieve business rules) stellen we op in termen van de eerder genoemde conceptdefinities.  Vertaal deze regels naar concrete controle query’s die tellen hoe vaak (en welke) er verboden data combinaties in de database voorkomen. We hebben nu een manier om ‘vervuiling’ te meten.  Wellicht hebben we nu ook een aanknopingspunt op basis waarvan kan worden berekend hoeveel omzet er gemoeid is met deze vervuiling. Dit kan dan weer gebruikt worden voor het onderbouwen van een business case voor het verbeteren van de datakwaliteit.

Vervolgens moeten er stappen worden genomen om de datakwaliteit te verbeteren. Enkele tips:

Tip: Start een verbetercyclus

Een “big bang” aanpak waarin alle datakwaliteitsissues ineens worden opgelost is doorgaans geen haalbare optie. Dit is zeker het geval als het systeem nog volop in gebruik is. Het is dan beter kleine stapjes vooruit te maken. Start daarom een cyclus waarin de eerder genoemde controlequery’s bijvoorbeeld maandelijks worden uitgevoerd om zo doorlopend zicht op de stand van zaken te houden. Bedenk daarnaast verbeteracties die er op gericht zijn het bestaande aantal foute dataitems omlaag te brengen. Deze verbeteracties kunnen eveneens periodiek worden uitgevoerd worden.  Als de tijd verstrijkt, is het heel goed mogelijk dat we door voortschrijdend inzicht onze set controlequery’s of verbeteracties nog verder kunnen uitbreiden. Verwerk deze ook in de verbetercyclus.

 Tip: Maak de organisatie bewust

Door het resultaat van de verbetercyclus te delen met de organisatie, kan gewerkt worden hogere mate van kwaliteitsbewustzijn onder de medewerkers. Betrek medewerkers uit verschillende plekken in de organisatie bij het verbeterproject. Maak bij zoveel mogelijk medewerkers inzichtelijk dat de ondernomen acties ook daadwerkelijk hun vruchten afwerpen. Maak bijvoorbeeld een datakwaliteitsmonitor die door iedereen te bekijken is.

Om te voorkomen dat we blijven dweilen met de kraan open, moeten er maatregelen genomen worden om te voorkomen dat hetzelfde probleem in de toekomst weer ontstaat. Enkele tips:

Tip: Ruim op

Velden die in onbruik zijn geraakt moeten worden verwijderd uit het systeem. Weersta de neiging om ‘voor de zekerheid’ oude datastructuren te behouden want ‘wie weet wat er dan omvalt’.

Tip: Los zaken structureel op

Idealen zijn prachtig maar als we naar de werkelijkheid kijken is het soms nodig snel te schakelen. Bijvoorbeeld om een nieuw product eerder dan de concurrent in de markt te zetten. Soms beweegt de markt sneller dan een ontwikkelteam kan bijhouden. In dit soort gevallen wordt vaak gekozen voor een quick en dirty oplossing. Mocht dit nodig zijn, neem dan nadien altijd de tijd om deze snelle oplossing om te zetten in een degelijke structurele oplossing.

Tip: Bewaak business rules geautomatiseerd.

Vervuiling ontstaat vaak doordat data integriteit en declaratieve business rules niet centraal of zelfs in het geheel niet worden afgedwongen. Moderne relationele database systemen bieden uitstekende mogelijkheden om dit te faciliteren in de vorm van referential en uniqueness constraints en triggers. Door hier optimaal gebruik van te maken zijn veel problemen te voorkomen. Deze manier van datakwaliteit afdwingen kan ook in stapjes worden uitgebreid. Dit kan gelijk opgaan met de eerder genoemde verbetercyclus. Telkens wanneer uit de periodieke controles blijkt dat een business rule geen enkele schending meer oplevert, kan op databaseniveau het geautomatiseerd afdwingen van deze regel in werking worden gesteld. De corresponderende controlequery kan vanaf dat moment worden verwijderd uit de verbetercyclus. Het komt voor, bij complexe triggers, dat dit een te zware wissel trekt op de transactiesnelheid van het systeem. In dat geval moet een andere oplossing gezocht worden. Bijvoorbeeld door achteraf te blijven controleren zoals we al deden of door wijzigingen aan te brengen in de invoerschermen.

Tip: Geef iedere gebruiker precies voldoende rechten

Een systeem waarin iedereen alle data naar hartelust kan wijzigen leidt bijna automatisch tot datavervuiling. Bekijk wie wat moet kunnen in het systeem om zijn rol in de organisatie naar behoren te kunnen vervullen. Als het systeem dit ondersteunt, ken dan iedere gebruiker precies die rechten toe die strikt noodzakelijk zijn. Als het systeem geen deugdelijk autorisatiemechanisme heeft, ligt hier de schone taak voor het ontwikkelteam om dit alsnog mogelijk te maken.

Tip: Vermijd hard coded keuzelijsten

In de meeste gebruikersschermen zijn ze wel te vinden: keuzelijsten die de gebruiker helpen met het invoeren van een valide waarde in een veld. De gebruiker kiest dan uit een lijst met veelzeggende omschrijvingen maar in werkelijkheid voert hij een code in. Reuze handig maar zorg er wel voor dat de items die in deze keuzelijsten getoond worden niet hard coded in de sourcecode voor gebruikersschermen staan. Deze waarden kunnen beter uit de database worden gehaald. Behalve dat dit voordelen met zich mee brengt met betrekking tot de onderhoudbaarheid wordt ook de kennis over welke beschrijving bij welke code hoort geborgd. Bovendien wordt het zo mogelijk door middel van een referential key te bewaken dat er enkel valide codes worden ingevoerd in de transactietabellen.

Tip: Kies het juiste datatype

Definieer het type van ieder database veld zo streng mogelijk. Dus als een veld een datum moet gaan bevatten, geef het dan een datumtype in plaats van bijvoorbeeld een teksttype, als het een geheel getal moet bevatten, geef het dan een numeriek datatype zonder decimalen.

Tot slot

Over het algemeen is het opschonen van een vervuilde database geen simpele opgave. Hiervoor is in de eerste plaats een lange adem nodig. Het opstellen van een data dictionary en business rules zijn een belangrijke eerste stap. De vervolgstap kan zijn dat het bestaande systeem verbeterd wordt. Het kan natuurlijk zijn dat het huidige systeem zodanig slecht in elkaar zit dat er wordt overwogen om over te stappen naar een nieuw systeem. De opgedane kennis over hoe de data werkelijk in elkaar steekt en hoe hij hoort in elkaar te steken zal in dat geval belangrijke input zijn voor een migratietraject naar dat nieuwe systeem.  Aan datamigratietrajecten heb ik al eens eerder een post gewijd. Kijk hier voor meer.