Big Data wordt steeds vaker als krachtig instrument ingezet. Data- en informatiegedreven bedrijven krijgen een voorbeeldfunctie. Traditionele datawarehouses en Business Intelligence worden gecombineerd met Big Data & Analytics. Maar als Big Data technologie ook voor het ontsluiten van interne bronsystemen gebruikt wordt, worden ook nieuwe risico’s naar binnen gehaald. Hoe moet je testen in zo’n grote en dynamische omgeving? Kun je garanties geven als het moet gaan om volledige en juiste data?
Datawarehouses zijn gebouwd voor het ontsluiten, integreren en verrijken van data van interne systemen met gestructureerde data, meestal opgeslagen in relationele databases, met een duidelijk datamodel. Big Data omgevingen daarentegen kenmerken zich door de 3 V’s van Volume, Variety en Velocity waarbij de data wordt opgeslagen in Distributed File Systems. Deze zijn extreem goed in opslag van veel data, zonder dat er een datamodel is en zonder dat er direct betekenis kan of hoeft te worden gegeven aan de data. Voorbeelden zijn de datastromen van social media of sensordata die via het IoT wordt aangeleverd. Wel is er de (technische) garantie dat dataverlies niet of nauwelijks kan voorkomen vanwege het gedistribueerde replicatiemechanisme.
Vandaag de dag zien we steeds meer voorbeelden van organisaties die Big Data technologie inzetten voor het snel en flexibel ontsluiten van data uit de eigen systemen. De klant die de data afneemt, is zich dit vaak niet bewust en hij zal (onuitgesproken) vasthouden aan de verwachting dat alle data volledig en juist wordt doorgegeven en veilig wordt opgeslagen. Zijn deze verwachtingen nog terecht?
Big Data technologie heeft een oorsprong met enkele kenmerken die afwijken van BI-omgevingen:
- Het applicatie landschap is gebaseerd op een grote diversiteit van Open Source applicaties die nog volop in beweging zijn. Kijk maar eens naar de vulling van HortonWorks of Cloudera.
- Het platform is gegroeid op Open Source Intelligence omgevingen met data zonder betekenisgevend datamodel.
- Open Source Intelligence (OSINT) data is vaak beschikbaar zonder al te veel restricties op het gebied van security of privacy.
Een grote verandering zit in het anders gebruiken van de data. Waar het bij traditionele BI vaak gaat over managementrapportages, worden de nieuwe mogelijkheden meer ingezet op de primaire bedrijfsprocessen. Het Enterprise datawarehouse dat daarvoor nodig is, stelt hogere eisen aan datakwaliteitsaspecten als volledigheid en tijdigheid. Dit vertaalt zich door in de business-eis dat elk gegeven (near-)realtime opvraagbaar moet zijn.
Nu interne bronnen ontsloten worden op een Big Data platform leidt dit tot nieuwe risico’s. Enkele vragen die opkomen:
- Hoe wordt de volledigheid en de juistheid van de data gegarandeerd? Niet alleen tijdens opslag in het ‘data lake’, maar ook tijdens de bronontsluiting en het aanbieden aan afnemers?
- Welke security en privacy maatregelen worden genomen als de data op een relatief onvolwassen en open platform terecht komt?
- Wie controleert of de ontwikkelde modellen op de juiste manier gebruik maken van statistische kennis en wordt bijvoorbeeld rekening gehouden met het verschil tussen correlatie en causale verbanden?
Voor je het weet, beland je in een situatie waarbij vreemde conclusies worden gebaseerd op data die verre van compleet blijkt of op verkeerde aannames over causaliteit tussen gegevens. Een interessant voorbeeld staat in de Financial Times waar Google wordt genoemd die op basis van Big Data een griepepidemie kan voorspellen maar vervolgens ook de fout in gaat, of de problematiek bij het voorspellen van verkiezingsuitslagen op basis van onvolledige doelgroepgegevens. En wat te denken van situaties waarbij deze enorme schat aan gegevens niet goed afgeschermd blijkt te zijn, omdat meer is gekeken naar het faciliteren van gewenst gebruik dan naar het voorkomen van ongewenst gebruik.
McKinsey heeft in 2016 gerapporteerd dat in vijf jaar tijd nog geen 30% van de beloften van Big Data zijn waargemaakt. Slechts enkele organisaties zijn echt succesvol.
Risico’s en maatregelen
Het ongrijpbare van Big Data kan je als tester onzeker maken. Inmiddels groeit ook in de datawereld het besef dat kwaliteit geen automatisch gegeven is, ook al is de technologie aan de onderkant stabiel. Kwaliteit is een onderwerp dat van belang wordt als datastromen gegarandeerd moeten worden, maar ook past het binnen termen als Data Strategy (waartoe dient al mijn data en wat wil ik ermee gaan doen?) en Data Governance (hoe maak ik mijn omgeving compliant aan allerlei wet- en regelgeving).
Nieuwe maatregelen zijn nodig om voldoende kwaliteit te borgen. Sterker nog, dit zal cruciaal zijn om de data-bubbel niet voortijdig te laten knappen met teveel verkeerde voorbeelden, foutieve modellen of conclusies gebaseerd op onvolledige data.
Enkele handvatten worden hier toegelicht:
- Veracity
Big Data wordt gekenmerkt door de 3 V’s van Volume, Variety en Velocity. Maar een 4e V wordt onmisbaar. Deze V staat voor Veracity en is de mate van waarheidsgetrouwheid van de data. Zoals we traditioneel gewend zijn om een set van kwaliteitseigenschappen tegen een software applicatie te leggen (bijv. ISO 9126 of ISO 25010), zo kan op datastromen een set van kwaliteitseigenschappen worden gebruikt om de datakwaliteit vast te stellen. Dit kan zowel op bronniveau als in de Data omgeving worden toegepast. Meer informatie over datakwaliteitseigenschappen is bijvoorbeeld te vinden in het Data Management Body of Knowledge van DAMA international (DAMA DMBOK) (https://www.dama.org/content/body-knowledge ).
Sommige keuzes staan hierbij op gespannen voet. Gaan we voor Volledigheid (langzamer) of voor Tijdigheid (sneller, maar niet altijd gegarandeerd volledig)? In zo’n geval kan een Lambda architectuur uitkomst bieden, waarbij een snelle levering wordt aangevuld met een dagelijkse compleetheidscheck.
- Complementaire testlevels
In het traditionele testen is het goed gebruik dat er een opbouw is van testsoorten die complementair zijn aan elkaar. Veelal uitgelegd langs het V-model en grofweg in te delen in 3 niveaus, te weten Unit testen, Systeem testen en Acceptatie testen. Hiertussen zijn talloze varianten bedacht, maar voor nu volstaat deze gelaagdheid. Een goede teststrategie zorgt dat er geen onnodige herhaling van testen plaatsvindt, maar zorgt juist dat de testen complementair zijn en zo gezamenlijk het geheel vanuit verschillende invalshoeken wordt afgedekt.
Voor datastromen is een vergelijkbare complementaire gelaagdheid te onderkennen. Helaas zien we nogal eens tekorten hierbij in dataomgevingen en worden bijvoorbeeld alleen technische controles met checksums en minus-query’s uitgevoerd.
Een goede teststrategie op datastromen onderkent minimaal:
- De technische laag (vergelijk Unittest) waarin gegevensstromen worden gecontroleerd op basis van aantallen record, checksums van bestanden, hashes etc. Primaire focus is volledigheid.
- De functionele laag (vergelijk Systeemtest) waarin de data primair wordt gecontroleerd op juistheid. Hier wordt onder andere gecontroleerd of de data niet corrupt raakt tijdens de verwerking. Blijft de integriteit bewaard en worden entiteittypes goed verwerkt? Testen op dit niveau vergt meer kennis van de data, bijvoorbeeld met behulp van een informatie analist.
- De informatie laag (vergelijk Acceptatietest) waarin uiteindelijk stakeholders van bronnen en afnemers bepalen of de informatie gebaseerd op de geleverde en verwerkte data correct en bruikbaar is. Dit kan bijvoorbeeld door een end-2-end integratietest uit te voeren, waarbij de data-voorziening als een blackbox wordt gezien.
Deze indeling sluit ook mooi aan bij de lijn data – informatie – intelligence. Een rol van Data Steward is goed bruikbaar om van bron tot gehele keten met inhoudelijke kennis toe te zien op juiste ontsluiting en aanbod van de data.
- Vigilance and resilience
Maar ook een goede datateststrategie is geen garantie dat in productie het geheel goed zal draaien. De V’s van Volume en Variety brengen een onzekerheid mee die elke test slecht een beperkte waarde geeft. De data zal altijd een mate van onvoorspelbaarheid hebben, die niet op voorhand te testen valt. Daarom is een volwassen monitoringsysteem op de datastromen in productie van cruciaal belang. Het systeem moet afwijkingen meten en beoordelen. Uiteraard moet ook een dergelijk monitoringsysteem ontwikkeld en getest worden.
Bij ongedefinieerde datastromen kan ook een stuk Machine Learning worden toegepast, die zelf dynamisch meegroeit met het beoordelen van afwijkingen van het ‘normale’ gedrag van datastromen.
In kwaliteitstermen kan een dergelijk monitoringsysteem worden beschreven in termen van:
- Vigilance – bewust van en alert op afwijkende patronen gecombineerd met handelingsgereedheid;
- Resilience – voorbereid op incidenten en beschikbare capaciteit om direct handelend op te treden.
- Agile en DevOps
Het onverwachtse van Big Data, in combinatie met een groot aantal Open Source tools dat nog volwassen moet worden, vraagt om een Agile aanpak van betrokken.
De vereiste mate van resilience zoals hiervoor genoemd, maakt deze omgevingen uitermate geschikt voor een organisatie die is ingericht voor DevOps, om zo op een snelle manier de afnemers optimaal te kunnen bedienen.
Hoe vernieuwend het allemaal ook mag zijn en hoe ‘disruptive’ het ook mag voelen. Als er iets mis gaat, zal nog steeds de aloude vraag worden gesteld: “Maar waarom is dat niet getest?”. Met dit verhaal wil ik richting geven om te komen tot een volwassen antwoord. Maar ook op dit specifieke aandachtsgebied is verdere groei noodzakelijk, om te voorkomen dat de data-bubbel uiteenspat. De aanwezigheid van een nieuwe rol als Data-steward kan bijdragen aan de invulling van bovenstaande punten.
