Data Management & Decision Support

Informatie in het hart van wet, beleid en uitvoering

Deze blog is een reactie op de oproep van Ron Roozendaal om mee te denken in de uitdaging waar wij allemaal voor staan. Het is een reactie die met name binnen het thema ´Digitale Overheid´ valt, maar zeker ook de ´Digitale Samenleving´ raakt. Het is een professioneel perspectief van de Chief Data Officer van het ministerie van justitie en Veiligheid. 

 

Kopiëren

We hebben binnen de overheid een probleem dat wordt gekenmerkt door een wanstaltige kopieerdrang, een bias t.a.v. logistieke oplossingen voor digitale uitdagingen. En in het merendeel van die kopieën zijn gegevens van burgers en bedrijven betrokken waarbij herstel- en correctieprocessen vaak niet worden erkend met alle gevolgen van dien voor burger en bedrijf. Al die kopieën hebben we helaas niet transparant (publiekelijk) inzichtelijk, we voeren geen administratie van deze gegevensstromen.

Daar komt bij dat de gegevens vanuit een applicatie/service context worden gehaald en worden hergebruikt in een andere context. Is die contextwijziging wel erkend, bekend en zijn de correcte transformaties uitgevoerd? Is de betekenis van het gegeven waarmee het ooit is verwerkt wel hetzelfde als de betekenis die de vrager veronderstelt? Tel daar eens bij op de vele datascience- en dataplatform omgevingen die gegevens verzamelen, integreren, verhaspelen en weer ter beschikking stellen; gaat dat wel goed als die betekenis zo ambigue is?

Het wanstaltig kopiëren is natuurlijk niet de oorzaak, het is een gevolg. Een gevolg van de wijze waarop wij digitaliseren binnen de Overheid. Ik zou nu Conway's Law kunnen citeren en zeggen dat dat eigenlijk ook geen oorzaak is, maar een gevolg. Namelijk een gevolg van de wijze waarop we de Overheid hebben georganiseerd, maar die laat ik voor nu even...

 

Silo's

Automatisering van de Overheid heeft geleid tot vele vele vele silo's van gegevens. Gegevens die worden gezien als een bijproduct van de applicatie/service waar de interactie en functionaliteit leidend is.  Elke silo heeft vaak een opportune niet ge-expliciteerde typering/definitie van haar gegevens in de context van wat die applicatie of service moet doen. Het kopen van applicaties heeft daar bepaald geen positieve bijdrage aan geleverd.

Als we dus willen doen aan hergebruik in operationele context of sturing, effectmetingen, beleid beïnvloedende analyses of verantwoording, wat vaak over applicaties, processen, organisaties, ministeries en soms zelfs landen heen gaat,  hebben we geen keus dan te kopiëren, ze uit de silo's te halen en te verfrummelen tot 'iets' wat mogelijk een antwoord geeft op de gestelde vraag of hypothese. Maar nog (veel) belangrijker dan sturing, effectmeting en verantwoording is de uitdaging waar wij voor staan als we op waarden willen werken; armoede, wonen, veiligheid, bescherming, klimaat, gezondheid etc.. In deze blogpost heb ik geprobeerd dat toe te lichten vanuit mijn verantwoordelijkheid als Chief Data Officer. Want alle genoemde waarden prikken dwars door de Overheid en de samenleving heen als het om gegevens gaat. Aangezien die gegevens gevangen zitten in de silo van een applicatie/service, moeten we ons verlagen tot kopiëren, kopiëren en nog eens kopiëren met alle risico's en ellende van dien.

Maar er zijn meer problemen als gevolg van die silo's. Als nu 10.000 mensen een recht op inzage (art 15 AVG) deden bij een willekeurige grote uitvoeringsorganisatie is dat het equivalent van een ddos-aanval. Vertaal dat ook even naar de dienstverleningsproblematiek; wij moeten de burger als mens willen zien, niet als belastingbetaler, student, patiënt, slachtoffer, gedetineerde, schuldenaar, vluchteling etc.. De burger centraal betekent wat mij betreft dat de burger bij de Overheid aanklopt en hij of zij wordt gezien in zijn integraliteit en hij dus ook ZIJN gegevens kan zien en corrigeren, ongeacht waar die gegevens ooit zijn verwerkt (!).  Met de silo's die we hebben is dat onmogelijk. 

We gaan nog even verder....

Zitten in al die kopieën attributen die niet ok zijn? Denk bv. aan herkomst of dubbele nationaliteit. Dat nu achterhalen is een massief, langdurig en unieke (niet herhaalbare) exercitie, dat moeten we toch simpel willen en kunnen beantwoorden? Maar denk ook aan de continuïteitsproblematiek. De impact op een wets- of beleidswijziging op al die silo's en kopieën is vaak niet te overzien (piep-systeem). Sterker nog; ik durf de niet-gestaafde hypothese wel aan dat de 'kopieer-en verfrummel' omgevingen binnen de overheid groter zijn (in kosten en menskracht) dan de omgevingen die moeten zorgen voor de ondersteuning van de kernprocessen. 

Maar genoeg zout in de wonde...

 

Now what?

Ik stel voor dat we grote(re) bestuurlijke attentie en daadkracht gaan zetten op drie belangrijke ontwikkelingen, laten we het de deltawerken van de Rijksbrede digitalisering noemen: 

1. Wendbare wetsuitvoering

De kamerbrief 'hoofdlijnen beleid voor digitalisering' geeft op pagina 10 bij 'Een sterke rechtstaat' al een hele duidelijke richting waar ik het hardgrondig mee eens ben: 

Naast de toekomstbestendigheid van de juridische kaders is het voor de democratische controle en controle door de rechter van belang dat wetgeving op een goede manier te vertalen is naar digitale code en regels in de uitvoering en andersom.

Zorg ervoor dat alle gegevens en regels die we digitaal gebruiken herleidbaar zijn naar wet- en beleid en waar we dat niet kunnen, mist er OF beleid OF we verwerken iets wat niet moet. Maak deze herleidbaarheid expliciet en stel de kennis als open data ter beschikking (transparant dus, ook een belangrijk onderdeel van de kamerbrief). Kunnen we dit? Ja, dat kunnen we; ik verwijs hierbij naar Wendbaar wetgeven van Mariette Lokin en Wetsanalyse van Ausems, Bullens, Lokin. Maar ik weet dat er binnen de Overheid vele organisaties en kennisexperts bezig zijn met dezelfde concerns en andere methodieken gebruiken (bv. gebruik van Knowledge graphs en LinkedData, maar zeker ook Calculemus-FLINT van Robert van Doesburg), allemaal prima. 

Dit goed doorvoeren, geen concessies doen, betekent bovendien een upstream aanpak van de problemen met de kwaliteit van data, meer by design, bij de bron, direct goed krijgen. Dit i.t.t. de vaak gerealiseerde downstream aanpak van de kwaliteit van data; de data is niet goed en we gaan proberen deze benedenstrooms te corrigeren (terwijl de bron fout blijft). 

Vaak wordt gezegd dat we taal moeten harmoniseren of standaardiseren, nee, dat is niet zo. We hebben onze taal, verwoord in wet- en beleid met al haar nuances en interpretaties. Het is zaak dat we de data (wat altijd een reflectie MOET zijn van  wet- en/of beleid) expliciet herleidbaar krijgen naar wet- en beleid. 

Punt is; we kunnen dit, maar we moeten daarbij wel enorm gaan investeren in opleidingen en mensen, het vakmanschap moet weer in het licht worden gezet. En dan doel ik o.a. op kennis-, informatie, data- en regelmodellering. Een vak wat we enorm hebben veronachtzaamd. Een vak wat verloren is gegaan in de tragiek van het technologisch fetisjisme.

Ook organisatorisch moeten we een moeilijke stap maken, multidisciplinaire teams zijn cruciaal; de wetschrijver, beleidsmedewerker, domeinexperts, kennismodelleur, informatieanalist en engineer moeten intensief samenwerken en vroegtijdig feedback geven. En ja, met een overheid waar beleid en uitvoering zijn gescheiden is dit enorm moeilijk. Misschien is dit nog wel de grootste uitdaging, nu loopt feedback van de uitvoering vaak over de rug van de burger, dat wil helemaal niemand. 

En voor de duidelijkheid; een uitvoeringstoets is niet wat ik bedoel. Nee, gedurende realisatie een constante en dus georganiseerde feedback tussen alle genoemde rollen waarbij - als we dit doorvoeren - uitvoeringstoetsen of wijzigingen op wet- en beleid vele malen eenvoudiger en realistischer te realiseren zijn. 

En voor de duidelijkheid; dit gaat een enorme impact hebben op de wijze waarop we IV doen...

2. Common/Public Ground

Zoals gezegd, we moeten af van de applicatie/service/technologie gecentreerde architectuur waar data en regels zitten opgesloten in de context van een silo en we ons dus wezenloos moeten kopiëren, met alle genoemde gevolgen van dien. We moeten data en regels gaan scheiden van processen, ofwel; we moeten de definitie van gegevens scheiden van het gebruik van gegevens - de scheiding van KNOW en FLOW. 

Gegevens zoveel mogelijk laten staan daar waar het gecreëerd wordt (en er verantwoordelijkheid voor is). Populair geformuleerd; we gaan van ontsluiten naar aansluiten. Dat betekent dus dat we naar een kenniscentrische (populair ook wel datacentrische) architectuur moeten. En nee, dat betekent niet dat we data centraal verzamelen, sterker nog de toekomst is federatie, idealiter zelfs tot en met de burger zelf die haar eigen data in zijn eigen kluis/wallet heeft. Echter, dit kan alleen als er een 'taal' wordt gesproken tussen de vele federatieve datasets die met elkaar kunnen 'praten'. En die taal hebben we; zie (1), de wet- en het beleid.

Voor architecten onder ons; dus een federatieve verwerking/opslag, maar een centrale regie/governance op metadata.

Wat ik hier eigenlijk bedoel en waar bijvoorbeeld de Data Governance Act ook op hamert, is dat we in stapjes moeten gaan naar een interoperabiliteitsraamwerk tussen overheden en ook private partijen waarbinnen gegevens makkelijk, transparant, herleidbaar en rechtmatig (by default) kunnen worden gebruikt. Dat laatste wil ik graag benadrukken; elke gegevensvraag van wie dan ook moet by design binnen wettelijke kaders vallen. Maar er zijn ook grijstinten, dilemma's waar waarden en grondrechten gewogen moeten worden. Dan is het belangrijk dat processen goed zijn doorlopen (denk bijvoorbeeld aan een ethische commissie waar universiteiten en NGO's zitting hebben), afwegingen transparant zijn geformuleerd en - mits mogelijk - publiekelijk zijn gedeeld. 

En voor de duidelijkheid; dit gaat een enorme impact hebben op de wijze waarop we IV doen...

3. Regie op Gegevens

De burger in regie op haar gegevens, zullen we dit nu echt gaan doen? Dat betekent dat de burger niet alleen inzage krijgt in haar gegevens en met wie en waarom haar gegevens worden gedeeld, maar deze ook kan corrigeren (met inachtneming van wettelijke randvoorwaarden) en kan delen met bijvoorbeeld private partijen. In dit verlengde zit natuurlijk ook dat besluiten van de Overheid jegens een burger altijd vergezeld  gaan van een toelichting t.a.v. de gegevens die zijn gebruikt en de regels (algoritmen) die zijn toegepast. En ook hier natuurlijk enorme uitdagingen (denk bijvoorbeeld aan inclusie van burgers die minder digitaal geletterd zijn), maar hebben we keus? 

En voor de duidelijkheid; dit gaat een enorme impact hebben op de wijze waarop we IV doen...

 

Een organisatorische vaardigheid, het begint bij de vakmensen

Alles wat ik hier zeg is niet nieuw. We hebben binnen en buiten de Overheid heel veel mensen die weten hoe dit gerealiseerd kan worden. Daarmee wil ik niet impliceren dat het eenvoudig zou zijn, nee bepaald niet, het is vreselijk ingewikkeld en het gaat ook echt wel even duren. Maar dit is geen zero-sum benadering, elk stapje wat gemaakt wordt is vooruitgang, maar consistentie is nodig is randvoorwaardelijk!

De tijd van bottom-up, experimentjes en leuke innovatieve pilots zijn voorbij. Wat hier ontwikkeld moet worden is een organisatorische vaardigheid¹, dat koop je niet in, dat huur je niet in en daar maak je geen programma van. Dat moet je zelf met bloed, zweet, tranen en heel veel vertrouwen realiseren. En dit laatste is vooral een oproep aan de bestuurders; we hebben heel dringend jullie vertrouwen, daadkracht en rechte rug nodig!!  

Laten we eens beginnen met twee dingen:

1. Een kenniscentrum te maken, de schaarse expertise gaan bundelen, waar mensen kunnen worden opgeleid, maar ook vakkennis kunnen verkrijgen en advies kunnen vragen. Bij voorkeur i.s.m. universiteiten en HBO instellingen. Want één ding is kristalhelder; we hebben mensen nodig, veel mensen en ook vooral jonge mensen. 
2. DOEN, daarvan leren, het delen en continue verbeteren. Als er ergens een nieuw stuk wetgeving/beleid gerealiseerd moet worden of een bestaand systeem moet vernieuwd worden, begin dan eens niet met een aanbesteding of met een keuze voor hippe technologie. Nee, begin eens met heel goed specificeren, pak Wetsanalyse erbij en begin met een precieze, digitaliseerbare, herleidbare en door domeinexperts gevalideerde specificatie. Je zal verrast zijn wat er allemaal aan ambiguïteit naar boven komt wat vroegtijdig getackeld kan worden (i.p.v. gedurende realisatie of zelfs na in-productiename).

De gedeelde noemer in alles wat je kan doen om te starten is altijd het digitaal vakmanschap en samenwerking. Ook daar geeft de kamerbrief aandacht aan, leve het vakmanschap! Maar boter bij de vis; hijs onze vakmensen weer terug op het schild, ga vertrouwen (!) en ga maximaal  ondersteunen.

Voor diegenen die meer willen horen/zien van bovenstaand verhaal, hier een link naar een webinar waar ik bovenstaande probeer toe te lichten.

¹A firm’s ability to perform repeatedly a productive task which relates [..] to a firm’s capacity for creating value [..] Most organizational capabilities require integrating the specialist knowledge bases of a number of individuals.- Bron: Organization Science, Vol.7, No. 4, July-August 1996

Waardegedreven werken, een mijmering over datagedreven werken

De zorgproductie, het aantal afgestudeerde studenten of de vonnisproductie van onze Rechters. We hebben als samenleving een overheid gecreëerd waarbij de financiering door de productie wordt bepaald. Het woord van Frederick Winslow Taylor is nog steeds leidend, efficiency is de heilige graal, aangestuwd in de jaren 80 door het neoliberalisme van Friedrich Hayek en zijn politieke volgers Ronald Reagan en Margaret Thatcher. De markt is efficiënt, concurrentie als zelfhelend mechanisme die een prijs bepaalt die de waarde van een goed of dienst zuiver vertegenwoordigt.

Efficiëntie, kwantiteit, productie. Vaak helaas gepaard gaand met wantrouwen en een korte termijn visie.....

Als de beloning op de productie ligt, ga je meer willen produceren; meer verrichtingen, meer afgestudeerden, meer vonnissen. Het is een vorm van operante conditionering, het 'systeem' zoekt de beloning of we dat nu willen of niet. En die beloning heet 'financiering'. Het is niet voor niks dat het Ministerie van Financiën gezien wordt als het belangrijkste ministerie van onze Rijksoverheid, de boekhouder bepaalt en zit aan elke tafel. 

Maar is dat wat we willen?  We willen toch gezonde mensen, opgeleide studenten en mensen die worden geholpen met hun schulden en niet voor het hekje van de Rechter komen? Van output naar outcome, of beter geformuleerd; van productie naar waarden.

Preventie, kwaliteit, duurzaamheid. Vaak gepaard gaand met een hoge mate van transparantie, vertrouwen en een lange termijn visie.

Ziekenhuizen worden gezondheidscentra, waar preventie centraal staat. Docenten toetsen de stof om te verbeteren, niet om te verantwoorden. En vroegsignalering en schuldhulpverlening zorgen ervoor dat mensen niet voor het hekje van de Rechter komen. In alle haarvaten van onze maatschappij wordt deze behoefte gevoeld en soms uitgeschreeuwd. We weten het allemaal, maar we roeien tegen een systeem in wat daar (nog) niet op is ingericht, alsof we een vierkantje in een driehoekje willen duwen. 

Misschien lijkt het nu alsof ik kwaliteit tegenover efficiëntie zet, dat is een misvatting. Een focus op kwaliteit, preventie en duurzaamheid leidt uiteindelijk altijd tot meer efficiënte en ja, zelfs goedkopere systemen.

Datagedreven werken?

Nu zit ik in een vak waar datagedreven werken is omarmd door de overheid in brede zin, overal is er veel energie om data op verantwoorde wijze te hergebruiken ten dienste van burger en maatschappij. Programma's, datalabs, opleidingen en vele use cases en experimenten laten zien wat de potentiële waarde is voor de burger. En daar zit een probleem; de grote waarde van datagedreven werken staat recht evenredig in relatie tot het sturen op waarden i.p.v. productie. Juist preventie en kwaliteit vraagt om het combineren van gegevens over applicaties, processen en taakonderdelen heen waarbij het belang van de burger altijd centraal moet staan, sterker nog, de burger zoveel mogelijk aan het stuur staat van zijn of haar gegevens! 

Denk bijvoorbeeld aan vroegsignalering t.a.v. schuldhulpverlening. De overheid heeft allerlei gegevens tot haar beschikking om early warnings (en dus hulp) te geven aan burgers die in de problemen dreigen te komen. Maar dit soort initiatieven daadwerkelijk uit de experimentele fase halen en operationaliseren is vaak niet mogelijk onder het huidige gesternte van productie draaien en financiering krijgen. 

En ja, ik besef terdege dat we daarmee ook op een zeer delicate balans terechtkomen t.a.v. waarborgen omtrent het gebruik van gegevens en persoonlijke vrijheden! Dat is bepaald geen eenvoudige opgave en vereist de nodige maatschappelijke discussie. Waarden als publieke transparantie en vertrouwen in de overheid zijn daarbij randvoorwaardelijk en ja, daar hebben we nog heel veel werk te verrichten. Maar stappen worden gemaakt, zoals bijvoorbeeld het programma Regie op Gegevens.

En wat is het doel van datagedreven werken dan wel? Behalve altijd een aantoonbaar effect t.b.v. burger en maatschappij? Zie bijgaande tekening van mijn zeer gewaardeerde collega, Marco Wobben, die vat het wel samen. 

Het sleutelbospatroon voor het ‘BSN’ probleem

Probleemstelling: Allerlei persoonsidentificerende sleutels (bv. BSN) en kenmerken staan in vele digitale administraties, kopieën, excels, datawarehouses, ‘datalakes’ of een andere <hipsternaam> voor een moeras aan data. Ze lenen zich daarbij ook makkelijk om even met elkaar te combineren. Dit is een zeer ongecontroleerd proces dat kan leiden tot problemen in het kader van de rechtmatigheid en levert aanzienlijke privacy- en beveiligingsrisico’s op.

Gezien de reacties die er zoal waren op deze blog, met name uit de hoek van identity access management, mocht de bovenstaande probleemstelling daar niet helder genoeg in zijn, deze blog gaat niet over identificatie en toegankelijkheid.

Deze blog gaat over de ongecontroleerde proliferatie van dit soort nummers en persoonskenmerken in de vele digitale administraties van publieke- en private partijen (dus alles wat er gebeurd nadat identiteit is vastgesteld en toegang is verleend). Het is dat ook een onderwerp wat zich met name positioneert in de vakgebieden van #datagovernance #datamanagement en #data-architectuur.

Een draadje (zoals ik deze op twitter poste) over het zogenaamde 'sleutelbos' patroon waarmee ik de risico’s van het probleem probeer te mitigeren.

1. Maak een sleutelbos met als scope alle processen waar burger en bedrijf communiceren met de NL overheid¹;
   
2. De sleutel van de sleutelbos MAG NEVER, buiten de sleutelbos, gebruikt of gecommuniceerd worden (anders creëren we stiekem een nieuwe BSN);
3. Betekenisvolle sleutels als BSN, RSIN, LEI, EORI, BECON of whatever id's, hangen aan deze sleutelbos, het gebruik daarvan in het maatschappelijke staat los van de probleemstelling (!), sterker nog, ik ga ervan uit dat ze intensief gebruikt blijven worden. Voor de datanerds onder ons; we degraderen deze sleutels dus tot attributen, niet meer tot sleutels in de digitale administraties;
4. Deze sleutels/attributen staan maar op 1 plek bij de overheid, in die sleutelbos, NERGENS anders;
5. Alle vormen van digitale administraties slaan een eigen gegenereerd betekenisloos nummer op, die wordt geregistreerd in de sleutelbos. Zelfs als iemand dus onverhoopt (met of zonder kwalijke intent) toch toegang krijgt, is er niks aan de hand. We beschermen hiermee dus ook de medewerkers van de organisatie in het creëren van een omgeving waarin je veilig kan werken. Hoe dit werkt:
   1. Een burger komt met zijn BSN waar dan ook ‘binnen’
   2. Er vind direct een check plaats met de sleutelbos, “heb je voor mijn administratie al een gegenereerd nummer voor dit persoon?”
   3. Als ja, geef dat nummer terug
   4. Als nee, aangeroepen/proces maakt eigen betekenisloos nummer aan
   5. En zorgt dat dit nummer netjes in de Sleutelbos wordt gehangen
6. Dit eigen administratiespecificieke gegenereerde nummertje wordt altijd met houdbaarheidsdatum in de sleutelbos gezet;
7. Zolang dit administratiespecifieke gegenereerde nummertje in de sleutelbos staat, hebben we een vorm van pseudonimisering (AVG art.4 lid 5);
8. Als de houdbaarheidsdatum is overschreden, weggooien uit de sleutelbos = (vorm van) anonimiseren;
9. Iedereen die ook maar iets van persoonsgegevens wil moet langs deze sleutelbos, ook partijen die lekker digitale administraties willen combineren kunnen dat niet zonder deze sleutelbos, wat een prachtige basis voor een informatieverwerkingsregister. En maak dit register lekker openbaar, Regie op Gegevens. Wat zou het mooi zijn als ik (burger) kan zien wie wat waarom met mijn persoonsgegevens doet;
10. Iedereen die dus iets wil moet de grondslag & doelbinding hebben (kun je dan netjes regelen), heb je dat niet? Opzouten.....

En dan nog een paar ‘puntjes’:

• Wie beheerd de sleutelbos is een 'ding', ik zeg een stichting buiten de overheid (zitten haken en ogen aan), @RvIG, iets voor jullie?
• De persoonskenmerken worden natuurlijk elders beheerd/geadministreerd en is vanzelfsprekend netjes gescheiden van de sleutelbos en ja, ook dat doen we op 1 plek
• Identificaties als BSN en persoonskenmerken staat dus NIET in enige vorm van digitale administratie
• Wat mooi zou het zijn als de Autoriteit Persoonsgevens dit patroon certificeert, zou betekenen dat elke digitale administratie die hier aan voldoet, al veel vinkjes heeft  
• Wil je nieuw #BSN? Wat niet nodig zou moeten zijn, maar als het moet? Easy, nieuw BSN aan de sleutelbos hangen, oude netjes enddaten
• En ja, dit is openhart chirurgie in de datahuishouding van de overheid en semi-overheden, maar de patiënt is ook aardig ziek
• En ja, dit staat nog los van principes als #dataminimalisatie en #proportionaliteit - we moeten ons constant afvragen waarom we in hemelsnaam altijd maar identificerende persoonskenmerken nodig hebben en moeten registreren, is dat echt nodig?
• Dat laatste kan binnen de (semi)-overheid ALLEEN maar zijn afgeleid van wet- en/of beleid, wat herleidbaar, transparant en geëxpliciteerd moet zijn #wendbarewetsuitvoering
• Dit is niks anders dan #commonground i.c.m #privacybydesign (oftewel; we zijn helemaal hip bezig). Ook in Estland zie je dat vormen van deze patronen worden gebruikt
• Patroon is bepaald niet nieuw of rocketscience, ook dat pretendeer ik niet, dit soort patronen zijn oud als de nacht, met name op het vakgebied van masterdata management zijn ze bekend.

En voordat mensen komen met perfecte tobe-oplossingen van groene weiden, blauwe luchten en spelende kindertjes. Denk vooral ook mee in de transitie, we komen niet zo snel af van de huidige werkwijze. Bovenstaande doet een poging dat mee te nemen. 

De wijze waarop je dit implementeert is een tweede vraagstuk, denk dat we vele opties en briljante ideeën en technologieën hebben. Zaak is dat we het voor nu nog even uit de technologiesfeer houden, omdat dit anders snel als technologieprobleem wordt geframed (zijn bestuurders dol op), DAT IS HET NIET. 

Zullen we dit nu eens echt gaan uitwerken en DOEN!?

Beetje klaar mee dat ik dit soort initiatieven of ideeën wel zie, maar het gebeurd veel te lokaal (elke uitvoeringsorganisatie een eigen sleutelbos gaat niet werken²), of het wordt volledig technisch aangevlogen (lets do blockchain blabla) en de doorzettingsmacht en kracht is om te huilen.

¹ De scope overstijgt dus de individuele uitvoeringsorganisatie, er valt zelfs nog een boom op te hangen om dit voor de BV Nederland te doen, waar ook private bedrijven op aansluiten

² Een sleutelbos van sleutelbossen maken is op zich een ok patroon, maar ik zou dat willen voorbehouden voor bv. het Europese niveau of andere supranationale samenwerkingsverbanden, de ECB doet zoiets met RIAD, wat een soort Europees KVK is, over de uitvoering laat ik me even niet uit.....oh shit, nu doe ik het toch

 

Wendbaar wetgeven; en nu de data.......

Komende vrijdag 22 november 2019 geef ik een presentatie voor de Expertisegroep Regelbeheer, dit is een kennisuitwisselingsverband tussen Belastingdienst, SVB, DUO, IND en Rijkswaterstaat op het gebied van bedrijfsregelbeheer. Onderstaand een abstract van de sessie die ik aldaar
ga geven. 

Voor een meer generieke achtergrond verwijs ik graag naar een vorige blog (engels)

Data is helaas, in de wereld van nu, vaak een bijproduct van een applicatie of een te ondersteunen proces. Belangen die de applicatie of het proces overstijgen worden onder het tapijt geveegd en 'opgelost' in kunstmatige en gebrekkige opwerkingen zoals datawarehouses, datalakes of andere (vaak informele) kopieermechanismen. Deze 'dataschuld' zorgt voor enorme uitdagingen t.a.v. wendbaarheid van wetsveranderingen op het digitale landschap, actualiteit en kwaliteit in dienstverlening naar burger en bedrijf en risico's t.a.v. ongecoördineerde verspreiding van data. We moeten data & logica scheiden van proces & applicatie. Dit wordt ook wel de scheiding tussen 'know' en 'flow' genoemd. Op het gebied van logica, en deze netjes afleiden uit de wet- regelgeving, heeft de Belastingdienst reeds ruime ervaring. Het is tijd dat nu ook het grote 'databeest'  zich hierop aansluit.

Daartoe heeft de Belastingdienst een Verticale Datadefinitie Architectuur  vastgesteld waarbij elke vorm van vastlegging is afgeleid uit wet- en regelgeving en los staat van proces- of
applicatiebelangen. Waarmee de impact van wetswijzigingen transparant wordt en - vice versa - de data altijd terug kan worden herleid tot wet- en regelgeving. Kennis-, informatie en datamodelleren is het vakmanschap dat (weer) nieuw leven in moet worden geblazen. Denk aan cognitatie, feitmodelleren, natuurlijke taal, regelspraak, logisch modelleren, anchor-style modellering, modeltransformaties en ordentelijke  'separation of concerns'. En nee, dit is allesbehalve een IV of IT taak, dit is per definitie een innige samenwerking tussen wetschrijver, wetsanalist. modelleur en engineer. Dat deze datadefinitie architectuur een paradigmaverschuiving is in de wijze waarop informatiesystemen tot stand komen, begint langzaam door te dringen. De grote uitdaging zit hem dan ook in de transitie, de fundamenteel andere manier van denken, werken en opleiden en hoe e.e.a. realistisch kan kantelen in de uitvoering.  

Data en regels horen bij elkaar, ze zijn als het ware 'brothers in arms'. Gezamenlijk definiëren zij een kennisdomein die gescheiden moet zijn van uitvoering.  De nieuwe Referentiearchitectuur Gegevenshuishouding van de Belastingdienst is gebaseerd op drie ontwikkelingen; (1) Wendbaar wetgeven, (2) Common Ground en (3) Regie op Gegevens. Een van de belangrijkste strategische thema's, de Verticale Datadefinitie Architectuur, wordt in deze sessie toegelicht.

Data, an inconvenient truth?

Last wednesday I attended TDWI in Munchen, did my rinse and repeat talk on the dataquadrants. Frankly, I am a bit done with these conferences. We have managed to create a whole industry that is fighting symptoms instead of the disease.

What do I mean? Let me generalize a bit, lets assume we have an average public organization, consisting of dozens or even hundreds of administrative systems that need to execute laws as our democracy has ordaned, combined with a huge influx of data coming in from other entities, public and private.

Lets face it, these systems have nearly all been developed with either an application or a process centric perspective; it needed to support some functional requirement or a business process. Nothing wrong with that, true?

Well, almost.....

The data of these systems have become a byproduct, a slave of the application/process. In architectural terms; in designing the data-part of administrative systems the concerns of the application/process trumps other concerns big time.

So, all the concerns that require a perspective (for our datanerds; a different reality/context) that superseded the application/process suddenly became very hard to execute. Even a different perspective of the data within the boundaries of the applicaties/process are a challenge. How did we decide to remedy that?

Lets extract the data, copy it, integrate it (often not possible btw), execute some logic (multiply the same logic over and over again), copy it again and send it somewhere (where it gets copied again and the whole shebang starts again).......oh, and lets do that a 1000 times.....oh, crap, do we need to maintain this logistic nightmare? Oh crap, the data does not really represent the actual administrative truth does it? Oh crap, the data is now proliferated (ungoverned) all over the place. Oh crap, we need to implement a change, what is the downstream impact? Oh crap, did the data-consumption-need of strategic initiatives like datascience, artificial intelligence and machine learning even deepened this logistic nightmare? Ah wait, we can buy technology and hire loads of consultants to help manage this horror.

Our data has fallen victom to the bias we have towards logistic solution designs often based in a technological fetish. If we have a dataproblem; lets copy, integrate, transform and disseminate and buy some nifty technology that can help us with that. It has become a conditioning.......

The problem we face is deadly; organizations are sick and instead of treating the illness we keep on fighting the symptoms and the symptoms of the symptoms. This is a yin and yang problem, not fighting the illness will make the patient sicker and sicker and will require evermore expensive medicins while the patient is of course degrading and can not perform her responsibilities anymore.

And the industry, software, technology, research institutes, system integrators, big consultancy firms  are not helping either. An analogy can be made with the farmaceutical industry. They have huge marketing budgets that push the medicines for the symptoms, offering a quick fix (“we can help”), getting the patient hooked and then raise the prices. Even worse, they invent medicines for the symtoms of their medicines. Prevention campaigns do not have a chance.

Unfortunately, our higher education decided to ride the waves of opportunism as well, all the courses regarding rigor and relevance in the science of data and knowledge engineering are slowly making way for teaching tech-related ‘fun’ stuff. 

The illness has to be cut out from the body, it will hurt and it will require, above all, executive discipline to resist the quick fix and the marketing pressure from the industry:
1. Data-at-rest; separate the “Know” and the “Flow” in data, design/model your domain in terms of data and rules first and separate that from the actual execution (function, application, process). The boundaries of these domains in government should be defined by the laws it needs to execute.

2. Data-at-flow; stop copying data unless you have a technical reason for it. More popular; from extract to connect. As an heuristic; copies can be thrown away without hurting processes.

My take away; addressing the fundamental issues in data requires us to move away from the symptoms like datawarehouses, datalakes or any other (often drenched in) technology-centric solution. Lets shift our attention towards the time and place a data-“fact” is born, our administrative sources, there lays our challenge. 

I am not proposing something new or innovative. ‘ Common Ground’, a strategic initiative in the Netherlands, research like ‘Agile Legislation’ (M.H.A.F Lokin) or ‘Regie op gegevens’  from the Dutch Government shows the broader support. 

[Dutch] Opzet van een datavoorzieningsfunctie ter ondersteuning van datagedreven toezicht

In september 2018 an article, written by yours truly, Wouter van Aerle and Frank Ouddeken, was published in 'Tijdschrift voor Toezicht'. The article is written in Dutch.

 

Inleiding

Toezichthouders hebben te maken met een steeds grotere stroom aan data. Dit vraagt om toenemende discipline in de verwerking ervan. Uit de principes van goed toezicht volgen niet-functionele eisen – als traceerbaarheid, uitwisselbaarheid en betrouwbaarheid – waaraan de gegevensverwerking moet voldoen. Voor het realiseren hiervan is een datavoorzieningsfunctie nodig, vergelijkbaar met andere bedrijfsfuncties als Finance en HR. Binnen DNB is het datakwadrantenmodel gebruikt om deze realisatie vorm te geven. Het model is een begripsvormend kader, dat de gegevensverwerking vanuit twee perspectieven beschouwt: de aanbod- en vraagzijde van gegevens en een opportunistische versus een systematische manier van werken. Op basis van het model zijn keuzes gemaakt ten aanzien van de technische voortbrenging van data, inrichting van de organisatie, besturing en benodigde kennis en competenties.

Download September2019_TijdschriftvoorToezicht_DamhofAerleOuddeken

It is all about the people (10th Peter Drucker Forum)

Last week I attended the 10th Peter Drucker Forum in Vienna, it was the second time I attended this forum and I consider it ‘food for the soul’. This year the theme was ‘The Human Dimension’. The greatest thinkers on management, leadership and organisation came together and discuss the state of things.

And in my humble opinion, we are in dire straits.

Let’s face it, organisations are killing people or - as described by Gary Hamel - organisations have become in-human by design. Huge bureaucracies are ‘emotional deadzones’, creativity and innovation is impossible, ideas are often approached in a hostile manner, greed and testosteron have become main drivers.

Organisations are not a safe place to engage in a truly meaningful conversation about improving oneself, the organisation and society. Management and leadership are increasingly distancing themselves of the problems and challenges that we face, they put no skin in the game. Blaming if something goes wrong, celebrating their great leadership if something went right. Or, according to Mintzberg; “we got too much disconnected leadership in organisations”.

In government this is even worse. Government has been derailed for decades by bureaucratic mindsets, powerbased scoundrels and the very defintion of silos. Talent management in government is a joke until they fix its culture, leadership habits and processes (Dan Pontefract). 

Government is broken and we need to fix it.

It is a challenge to change this, but I believe we can. And this message was heard during the two days as well. Just start with acknowledging this great injustice to humans, the devastating effect it has on productivity, quality of service, the ability to innovate and the ability of organisations to be socially responsible (dear organisation, answer this question; in terms of purpose, why do you exist except for making more money?).

We can change, but it all starts with leadership being selfless, mindful and compassionate (Rasmus Hougaard). Listen!, be curious, ask questions (Hal Gregersen), facilitate decision-making (resist making decisions yourself) in small teams of people, reward initiative and competency. Power is not given to you by hierarchy, but its given to you if you take initiative (Xavier Huilard).

Or to put it more succinctly; just start giving a shit.

Reflection of oneself is vital in all of this. Don’t just act selfless, be it. Don’t just act social responsible, proof it. Don’t just act compassionate, let me feel it.

And I am writing this plea not only for management or leaders, I am also writing it to myself and others as well, because I truly belief that we are all leaders. 

“Have some skin in the game”, stop rewarding yourself 500 times (or more) the average wage. Stop accumulating obscene amounts of wealth and underpaying your employees (Jeff Bezos, looking at you). Stop striving for global monopolies and crushing human rights and values in the process (Amazon, Google, Facebook, Uber, ....). Stop grabbing, start giving. Oh my, this is starting to sound like a sermon now.

I was impressed by Paul Polman, CEO of Unilever. What a passionate man, I felt his anger, driven by purpose, the common good and acknowledging that his company can change something for the better. Not only talking about it, but acting on it! Unilever has lost a great leader (after 10 years he will retire as CEO of Unilever), I really hope Paul remains to be on the stage. We need people like him.

Stop talking, start walking........Humans first.

Datascience; more bang for the buck

'I made some Python code that really rocks, Ronald'

'It extracts data from various sources, validates it, does some cleansing, codes xxx business rules, lots of integration of course, executes some kind of predictive model, outputs the data and visualizes it'.

And then the magical words are uttered; lets deploy it to production……

Alas,, the magic of datascience ends abruptly, IT is probably being blamed for not being agile and architects are scorned for being too restrictive and even killing innovation in the process.

Datascience has got a problem, it fails to operationalize its brilliant models and it therefor fails to deliver value to the business. There I said it, I know, pretty polarizing, but I encounter it on a daily basis now. Datascience needs to grow up....

It’s all about: (1) the required quality of services and (2) separating concerns.  Both seem to be not that important in datascience. It should though!

Let me clarify;

Quality of services

Two use cases;

(a) deploying a riscmodel at scale (lets say 500K transactions per day) that evaluates a transaction (from a customer) in realtime based on contra-information and determining in the process the level of supervision needed. Oh and by the way; one has to take into account ‘equality of right’ since the organization is a publicly owned organization.

(b) doing a one-time analysis on various sources, using advanced machine learning and where the output is used for a one-time policy influencing decision.

The quality of services between (a) and (b) are like night and day. (a) needs to be run at scale, realitime (direct feedback), using contra-information, the provenance is hugely important, it is subject based, so there are privacy concerns, it’s an automated decision (there is heavy legal shit here), equality of rights (metadata like; what model did we use on what transaction, what data did we evaluate,…) and many more.

(b) is a one-off….its output influences new policy or contributes to some insight. Your quality of services might be that the model is versioned, properly annotated and that the dataset is somehow archived properly to ensure repeatability. 

My point is that, whenever you start on an analytic journey, establish the quality of services that you require on forehand as much as possible. And for that to happen you need to have a clear explicit statement on how the required informationproduct contributes to the bottom line. So yes, a proper portfolio management process, a risk based impact assessment (!) and deployment patterns (architecture!) that are designed in advance!

With regard to datascience it is vital to make a conscious choice, before you start, of the required quality of services. If these services are high, you might wanna work together closely with system engineers, datamodelling experts, rule experts, legal experts, etc.. Only then, you might be able to deploy stuff and generate the value the field of datascience promises us.

 

Separation of concerns

For those who do not know what ‘separation of concerns’ means, start with Wikipedia or google Edsger Dijkstra, one of the greatest (Dutch) computer scientist…..

Anything IT related is suffering from the ‘overloading concerns’ issue. Some examples;

• XBRL is a great standard, but suffers from overloading; integrity, validation, structure, meaning and presentation concerns are all bundled into one technical exchange format.
• Datavault is a great technical modeling paradigm, but it does not capture logical, linguistic or semantic concerns, and yet the data modelling community still tries
• Archimate is a great modeling notation in the Enterprise Architecture arena, why is it overloaded with process concerns? BPMN is such a better choice.

And of course we see it in code and we have seen it for ages in all programming languages; human tendency to solve all challenges/problems with the tool they are dominantly familiar/trained with. Datascience is no different. Failing to separate concerns lies at  the root of many software related problems like maintainability, transparancy, changeability, performance, scaleability and many many more. 

Like the example I started with in this blog;

A brilliant Python script where a staggering number of concerns have all been dealt with. This might not be a problem when the required quality of services is not that high. But when the required quality of service are high it becomes painfully clear that ‘deploying’ this code to production is a fantasy.

Extraction, validation, cleansing and integration concerns might be better dealt with by making use of tools and techniques in the information (modeling) arena.

Business rules might be better of designed (for example) by means of Rulespeak and subsequently making them more transparent for legal people and domain experts (which is btw – especially in AI – a huge concern!).

Visualization and presentation might be better of by using  tools that are already purchased by your organization, be it Tableau, SAS Visual Analytics, Qlik, Tibco or whatever.

 

Finally

Dear datascientist, stop blaming IT, architects or whoever that your brilliant code is not being deployed in production. Instead, reflect on your own role and your own part in the total supply chain of stuff that need to happen to actually get things working in production at the quality of services that are required.

Dear organization, stop blaming datascientists for not delivering on the value which was promised. Start organizing, consciously, the operationalization of datascience. It is not a walk in the park, it is an assignment that requires an extremely broad skillset, an holistic view, cooperation and of course attention to human behavior/nature.

And the majority of these challenges fall with management!

Starting a datascience team or department without organizing the operationalisation is a waste of resources. 

Operationalization of datascience IS NOT a technical problem!

For my dataquadrant fans; it is all about transitioning from quadrant IV to II.

 

 

 

 

Musings about Gartner Data & Analytics in London

The last three days I was visiting the Gartner conference in London.

It has been a mixed experience. In terms of data strategy, organization and culture I can honestly say that some sessions were really inspiring. I caught myself re-thinking my own convictions and extending my scope to areas that matter as well, and that is always a good thing. I liked the keynote with the four central themes; Diversity, Trust, Complexity and (data) Literacy. These themes  abstract – as it should – from technology and introduce explicitly the human factor and aspects of uncertainty. In data, I think Gartner kinda nailed it with these themes. I recognized them all in my daily work as a Data Architect.

The second keynote of David Rowan – founding editor-in-chief of WIRED - was simply brilliant and scary at the same time. His central theme was that we stand on the tippingpoint of finally having the ethical discussion. What an excellent timing, considering the facebook privacy scandal.

I also enjoyed sessions of Alan Duncan about the Chief Data Officer and Nick Heudecker. The latter analyst I followed for some time now and he certainly didn’t let me down. Excellent, down to earth sessions on blockchain and datalakes.

What I also liked were the datascience platform vendors, really cool stuff that let you leverage open source interpreted languages (R, Python), solves a great deal of governance pain (e.g. versioning, deployment, collaboration, protection, etc..), give you options as to where the processing is done, abstract (drag-and-drop interfaces) – if you desire – from the code, etc..

Gartner is also very aware of the operationalization issue with datascience. In their terms, going from mode 2 to mode 1. In our terms, going from
quadrant III/IV to quadrant I/II (see figure). In my opinion this is the holy grail in data, leveraging datascience brilliance for the whole organization and serving the bottom line.

To be honest, this holy grail is not solved, not by Gartner and not by me. On twitter some excellent discussions unfolded in this regard. 

But now the not-so-good stuff. In terms of data architecture, Gartner is stuck.  They confine data very narrow, as in data-for-analytics. And therein lies a fundamental problem. We have to move on and view the data holistically, from conception to retention where data is used for many use cases, not only analytics and subject to many constraints (like privacy, transparancy, etc..). Furthermore, lots (the majority) of problems (meaning, (time) consistency, validation, integration, transparency, etc..) in data are created upstream, but Gartner seems to have given up and decided that we need to deal with the problems downstream. A first example would be their logical datawarehouse concept. Now, I have to be honest, I do not like this concept, at all. I think it is deeply flawed. Why?

First, think of this logical datawarehouse as a beautiful patio, green grass, nice swimming pool, birds are singing. Underground however, right beneath the surface, the ground is highly contaminated. Would you want your children to play in this patio?

Second, Gartner seems to be stuck in metanarratives like a datalake, datawarehouse and even a datahub. The latter one is completely vague to me, it sounds like a datalake-warehouse-wannabe. These metanarratives are still very much technological bound, ambiguously defined and calling them logical is just a façade. Lets abstract from these technical bounded concepts and talk about an organisational capability to systematically ingest, create, connect, validate, integrate and disseminate data taking into account contextual aspects like transparancy, protection, consistency, etc..

Third, Gartner seems to be oblivious of vertical data architecture. This is the architecture of data in rest, as opposed to the horizontal data architecture, where data is in flow. Gartner seems to be hugely biased towards flow/logistics, getting data from a to b. A vertical data architecture would  start (depending on the concerns you want to address) with natural language, translating it to ontologies, fact based models and finally truly logical models that drive the technical models (often automated), persist data only once and virtualize the logical domain model.  Such an architecture would result in logical consistent data, not a logical data warehouse!

Fourth, the logical datawarehouse concept seems to be very much associated to datavirtualisation technology, which makes it a lot less logical.    

A second, after the fact solution, Gartner seems to be very fond of, are Masterdata Management (MDM) solutions. In my view MDM is a legacy problem and stems from a lack of holistic (vertical) data-architecture. A solid vertical data architecture solves many masterdata problems at its core and prevents the constant remediating of symptoms.

A third after the fact solution is this infatuation with the availability of data. Lets get all the data!! Why? Because we (technically) can….There seems to be no conscious decision between availability and consistency. Two concerns that lie at the heart of data and where business needs to weigh in, not the technology.  Furthermore, with GDPR coming, it deeply violates the data minimalisation principle. 

Getting to the root of things; it is like modern medicine. We keep on curing the symptoms with nasty side effects, but we never engage in prevention. It is vital in my opinion that an holistic data-strategy and -architecture is adopted! It is like the brilliant closing keynote of Tuesday regarding sleep deprivation by Professor Matt Walker. If you sleep enough you will age healthier, the scientific research is overwhelming. If you don’t, your chances of getting sick, cancer, heart diseases or psychological disorders are increasing fast! We are now hooked to hugely expensive medicines that cure or alleviate only the symptoms…..

Why not try to sleep a bit longer…..

 

 

Data architecture in a digital world; empowering the data driven enterprise

Several months ago, Daan Rijsenbrij approached me (Ronald Damhof) and Martijn Evers to assist him in researching data architecture as it manifests itself in organisations. 

Daan: "In the Netherlands an international research is performed about data architecture. The purpose of this research is to investigate the maturity in the thinking about & working with data in modern enterprises. You can download a survey from drop box: https://lnkd.in/ghVCqSx The survey consists of a short intro, a scoring list and a list with 12 open questions. Answer only those items that are relevant according to you in your situation. Please return the filled in survey to Daan as an attachment to an email: [email protected]." 

The survey is written by me and Martijn and reviewed by a dozen or so fellow data architects. The intro of the survey is copied 1:1 in the next section. We would like to urge architects - affiliated with data architecture - to do the survey, return it to Daan and help us in advancing data architecture.

Nowadays, one frequently hears senior executives, management consultants or strategists proclaim the phrase: “Data is an asset.” While not necessarily incorrect, it is usually a hollow phrase because it is often misunderstood and seldom operationalized. With data comes the need and responsibility to manage it in a dedicated and professional manner, both from a liability point-of-view as well as to create the necessary conditions to truly leverage its potential to add value.

Data is not an asset like financial capital, which can be spent. Nor is it like human capital, which walks out of the door when it sees a better opportunity. Data asset are different: they are uniquely yours, closely tied to your business language and processes, full of nuance, always defined in a specific context and it provides the ability to generate new data (assets).

Data is also unique in that it depreciates in a nonphysical and often undetectable way, losing its meaning, accuracy and/or relevance as time goes by. Every organization can use its data in its own way to differentiate itself. When data is consumed in your organization, it will not be depleted nor will it expire (like a patent). No other type of asset has these particular characteristics.

Data defines other assets. For example, it reveals your financial state, it holds a reliable record of your employees or customer behavior. Arguably, data is the ultimate proprietary asset. And unlike technology, it cannot be commoditized. Data uniquely defines the state and meaning of an organization and its intrinsic value, which cannot be transferred to another organisation.

While all other assets are managed consciously by entire departments with ample resources to do so, data is often considered a by-product of information systems, something often perceived as technological. Or as Frank Buytendijk of Gartner put it: “Most companies manage their parking-lot better than their data.”

In all the hype and buzz surrounding #BigData #InternetOfThings #Datascience #MachineLearning #Digitization and the like, technology is perceived as a primary differentiator. Well, it's not.

While technology is essential for any business, it is usually of lesser importance in terms of competitive advantage. Technological innovations may give a company a competitive advantage, but the effect is only temporary. Sooner or later, innovations will be copied by competitors. Technology tends to become commoditized over time.

Ignoring the hype that surrounds new data-related technology, the common (success) factor is always data that is relevant, reliable, consistent and timely. Investments that neglect data quality requirements are doomed to fail.

The technological evolution continues to accelerate, yet ultimately it’s not about the technology. “IT does not matter”. What does matter is architecture. We need to understand the data, how it’s used, and to build a supporting data infrastructure. This requires fundamental thinking, not buying. It requires a holistic approach, not a siloed approach. You cannot buy your way out of the data misery you are in - it takes blood, sweat and tears. Or in other words: stamina, discipline, trust and courage, especially by senior management.

How well an organization is able and willing to incorporate this approach ultimately determines how well it can leverage its data assets for the benefit of its customers and operational excellence. It is this approach that we need to focus our energy on, instead of indiscriminately following the latest fad, promise or glossy brochure, with an unfounded belief that this new technology will solve our data issues.

There is no quick fix!

It is imperative to realize that data is a foundational element that drives and leverages innovation, business transformations, acquisitions and other organizational-critical events; data architecture is the guardian of this foundation.