Hoe voorkomen we de data apocalyps?

Het principe van Correct by Construction

Via een post op Twitter kwam ik een paar weken geleden terecht bij het artikel The Coming Software Apocalypse. Kort samengevat: de problemen die we met software proberen op te lossen worden steeds complexer en overstijgen het vermogen van mensen om dit nog te begrijpen: “we are attempting to build systems that are beyond our ability to intellectually manage.”. De hoeveelheid regels code neemt vormen aan die niet meer door een mens is te overzien, van 30 mio regels in een Airbus tot meer dan 100 mio regels in een moderne auto. Maar niet alleen omvang en complexiteit vormen een steeds grotere beperking, ook de manier waarop wordt ontwikkeld kent tekortkomingen: “The serious problems that have happened with software have to do with requirements, not coding errors.”. Dit is terug te voeren op hoe doorgaans requirements worden vastgelegd: in geschreven tekst en plaatjes. Uit deze beschrijvingen moet een ontwikkelaar afleiden wat te coderen.

Hier valt een analogie te trekken met het voortbrengen van gegevens en het managen van data. Gegevenslandschappen en dataverzamelingen worden groter, complexer en meer verweven met elkaar. En de totstandkoming van deze data gebeurt op een vergelijkbare manier: op basis van informele specificaties zoals UML-modellen of een tekstuele opsomming van vast te leggen attributen. Als dit soort specificaties al überhaupt worden opgesteld…. Schema on read toch?

De vraag is natuurlijk: is dit erg? De consequentie van deze ‘sloppy’ manier van werken is meer rework, grotere kans op fouten en uiteindelijk disfunctioneren van software. Voor bepaalde toepassingen is het evident dat dit soort risico’s maximaal gemitigeerd moeten worden, bijvoorbeeld bij kerncentrales, vliegtuigen, wapensystemen of medische apparatuur. De code moet anders gezegd correct by construction zijn. Dit principe voorziet in het opstellen van formele requirements die logisch te verifiëren zijn op omissies en tegenstellingen. Op basis hiervan wordt software ontwikkeld die feilloos doet wat gespecificeerd is (niets meer en niet minder). Voor de genoemde voorbeelden onvermijdelijk lijkt me maar voor minder kritische toepassingen (bijvoorbeeld een webshop of reserveringssysteem) geen must have. Maar is het probleem niet toch groter dan het op het eerste gezicht lijkt? Als je een product als een wasmachine of CV-ketel koopt, verwacht je dat het werkt zoals is geadverteerd en beschreven. Software brengt steeds meer hetzelfde verwachtingspatroon met zich mee; alleen de realiteit is dat het soms compleet onverwacht gedrag kan vertonen[i].

Ook hier is een parallel met de voortbrenging van data te maken. Bepaalde softwaretoepassingen brengen zelf veel en verschillende soorten data voort (e.g. CRM, ERP, ZIS). Voor zover het principe van correct by construction (CbyC) voor dit soort applicaties geldt (voor onderdelen van een ZIS lijkt me dat niet irreëel), zou dat voor de onderliggende data ook moeten gelden. Maar daarnaast zijn er ook specifieke criteria te formuleren wanneer CbyC van toepassing zou kunnen of zelfs moeten zijn. Uit de eerdergenoemde voorbeelden blijkt duidelijk dat het om toepassingen gaat met een systematisch, permanent karakter. Kortom, om voortbrenging in Kwadrant I en II[ii]. Bovendien is duidelijk dat het om toepassingen gaat met strenge non-functional requirements (NFR’s). Welke NFR’s voor de voortbrenging van data zouden een CbyC aanpak rechtvaardigen? Ik kom op het volgende rijtje:

• Traceerbaarheid: betreft de mogelijkheid om de historie, oorsprong en verwerking van data te verifiëren op basis van specifiek hiervoor geregistreerde meta-informatie.
• Beschikbaarheid, integriteit en/of vertrouwelijkheid van gegevens(waarden).
• Compliance met specifieke wet- & regelgeving. Hieronder valt ook compliance met de Algemene Verordening Gegevensbescherming (AVG / GDPR).
• Interoperatibiliteit van gegevens op zowel semantisch- als technisch niveau.

So what? Dit soort eisen zijn toch niet nieuw? Klopt. Het verschil is wel dat wanneer een feilloze naleving van dergelijke eisen nodig is, het CbyC-principe meer van toepassing wordt. De vervolgvraag is dan ook wanneer de norm voor deze eisen zo hoog wordt gesteld. Interessant in dit licht is om te volgen hoe streng de GDPR-eisen straks in de praktijk werkelijk gaan zijn. Verder speelt een steeds hoger verwachtingspatroon van data-consumenten hier een belangrijke rol. Nog steeds lukt het gevestigde bedrijven niet om iets simpels als een adreswijziging door te voeren zoals ik zelf onlangs persoonlijk heb ervaren met een grote verzekeraar. Ik zie niet in hoe dit soort praktijken nog lang te handhaven zijn (de afhandeling van een bijbehorende verzekeringskwestie was minstens zo dramatisch waarbij de oorzaak aantoonbaar was terug te voeren op slechte datakwaliteit. Exit verzekeraar dus).

Deze verkenning van het correct by construction-principe laat overigens ook een relatieve beperking van het privacy-by-design principe zien. Privacy, of liever – compliancy met privacywetgeving – wordt pas bereikt wanneer het design is omgezet in werkende software én dat bewezen kan worden dat de werking 100% en feilloos voldoet aan de eisen die in het design zijn vastgelegd.

Hoe kan CbyC worden geïmplementeerd voor gegevens? In essentie draait het om een formele methodiek van werken die de kans op fouten minimaliseert. Formeel werken staat niet haaks op incrementele ontwikkeling of het toepassen van Agile-principes[iii]. Het betekent wel het vermijden van ambiguïteit, verifieerbare specificaties & code en gedisciplineerd werken. Kernelementen zijn:

• Formele specificaties en precieze formuleringen van requirements: bij het voortbrengen van gegevens is het datamodel een sleutel artifact. Maar het ene model is het andere niet. Conceptuele schetsen, UML-modellen of business glossaries zijn effectief voor de begripsvorming maar onvoldoende precies. Een logisch datamodel (LDM) of Feitgebaseerd Model (FOM) voldoet wel aan dit soort eisen. Voorzover requirements niet in het model tot uitdrukking kunnen worden gebracht, is het zaak deze requirements zo precies en bondig mogelijk te formuleren. Het opstellen van zinstructuren volgens RuleSpeak® is hier mogelijk een oplossing voor.
• Model driven development (MDD): hoewel formele methoden ook zonder kunnen worden toegepast, lenen formele methoden zich bij uitstek voor model driven development, juist omdat specificaties formeel worden gespecificeerd. Ook in het licht van steeds groter en complexer wordende gegevensverzamelingen, wordt het steeds moeilijker om handmatig of semi-geautomatiseerd te ontwikkelen. De datamodelleur wordt hiermee de ontwikkelaar.
• Het hanteren van een engineering benadering: hoewel dit deels door de voorgaande twee punten wordt afgedekt noem ik het hier toch apart. Het ontwikkelen van systemen vereist gewoon een gedegen aanpak waarin zaken als ontwerp, testen, OTAP-voortbrenging, documenteren, rollback-mogelijkheden etc. vanzelfsprekend zijn. Keer op keer is verleiding groot om – gedreven door nieuwe technologieën of modieuze methoden – dit soort elementaire eigenschappen overboord te gooien. In de begintijd van het internet dachten we dat iedere middelbare scholier met een cursus Dreamweaver een website kon bouwen. Totdat we erachter kwamen dat een website bouwen ook gewoon een vorm van ontwikkeling is waarvoor nog steeds dezelfde software engineering principes gelden.

Overdreven, overbodig of bittere noodzaak? Gezien de data-puinhopen die we in de praktijk nog steeds eerst moeten opruimen voordat we er zinnige dingen mee kunnen doen[iv], is een beetje meer Correctness by Construction geen overbodige luxe lijkt me. “It isn’t magic, just good engineering.”

[i] Hall, A., & Chapman, R. (2002). Correctness by construction: Developing a commercial secure system. IEEE software, 19(1), 18-25

[ii] Zie voor een uitleg van kwadrantenmodel: http://prudenza.typepad.com/dwh/2013/08/4-quadrant-model-for-data-deployment.html

[iii] Amy, P. (2013). Correctness by Construction, https://www.us-cert.gov/bsi/articles/knowledge/sdlc-process/correctness-by-construction

[iv] Vincent, J. (2017). The biggest headache in machine learning? Cleaning dirty data off the spreadsheets, https://www.theverge.com/2017/11/1/16589246/machine-learning-data-science-dirty-data-kaggle-survey-2017