Deze 12 digitaliseringsvraagstukken vergen politiek aandacht

Deze punten werken niet. Het haalt politieke wens en datadenken door elkaar. Veel bestuurders en ambtenaren worstelen domweg met de kloof tussen Visie (WAT) en Uitvoering (HOE). Die spanning kan leiden tot het nemen van overhaaste beslissingen. Dan staat daar ineens een Afdeling Data Science, maar wel met PowerBI ‘experts’ die werken zonder datakwaliteit eisen, maar met het verslavend gemak van drag-and-drop algoritmen. Het resultaat bestaat uit prachtige grafieken, waarvan onzeker is of zij ook feiten representeren. Het plaatje staat vervolgens wel in bestuurlijk dwingende documenten. Nog zo’n valkuil: het halen van de deadline van oplevering van een rapport stellen boven het kunnen valideren van de inhoud van dat rapport. Zoiets krijg je als een slecht geformuleerde opdracht op het bordje komt van onervaren adviseurs van goedkope adviesbureaus. Of een mantel contractant, die een verkregen opdracht zelf ook uitbesteedt. Een volgende organisatieonderdeel in de waardeketen wordt vervolgens beperkt door een autoritair, maar slecht rapport, maar moet dat die denklijn toch zien in te passen … De onontkoombare nadelen plagen vervolgens weer andere bestuurder, met ander mandaat.

Niet werken met Business Architectuur is als hardlopen met samengeknoopte veters.
Verfijnde multimediale concepten worden ‘omwille van leesbaarheid’ ‘platgeslagen’.
Het resultaat kan behoorlijk onzinnig worden. Zo is een eWallet niet te vergelijken met je Stocard app voor je grootgrutterpasjes en dateren sommige voorschriften nog uit 2012. Bijblijven vereist een voortdurend ontleren, als er meer kan dan men beseft.

Onze huidige Rijksoverheid dateert nog uit de tijd van centralisatie, standaardisatie en harmonisatie. Een denkwijze die je ook terugvindt in de ontstane data-architecturen. Datawarehouses, datafabrics en datalakes zijn stuk voor stuk gecentraliseerde architectuurmodellen, waar de data worden gecentraliseerd en beheerd door technische experts. De samenleving evolueert inmiddels verder. Zo is daar de opkomst van de Data Mesh, een gedecentraliseerd model. In dit model zijn de data, inclusief alle bijbehorende infrastructuur en beheer, het eigendom en de verantwoordelijkheid van individuele teams (ook wel ‘domeinen’) binnen hun eigen bedrijfsecosysteem. In een Data Mesh zijn het de Gebruikers zelf, die verantwoordelijk zijn voor het verzamelen, verwerken en beheren van hun eigen data. Zij hebben zelf de autonomie om beslissingen te nemen over hoe hun eigen data wordt beheerd. Bij grote macht hoort echter grote verantwoordelijkheid.

Door de gegevens binnen het Domein te bewaren, kan elke eindgebruiker die over de juiste inloggegevens beschikt, de gegevens ontgrendelen, doorzoeken en bij de Bron houden.
Er wordt niets meer naar een centrale locatie gekopieerd, waardoor het databeheer veel strakker kan worden georganiseerd. Precies door hen die de meeste ervaring en kennis van die gegevens hebben. Dit zou ook een schaalprobleem voor de overheid kunnen oplossen.
Hoe meer actoren behoefte hebben aan ‘jouw’ data, allemaal om hun eigen redenen en vanuit hun eigen gebruikscontext, hoe lastiger bottlenecks worden.

Door data daarom niet langer te beschouwen als het product van een individu of individuele organisatie, maar als een collectieve hulpbron, kunnen we data ontkoppelen van de infrastructuur. Infrastructuur die tegenwoordig uitstekend beheerd kan worden door automatisering. Het probleem is niet eens zozeer het datavolume, want ook de huidige gecentraliseerde data-architecturen en cloudproducten kunnen prima grote hoeveelheden batch- en stromende data aan. De winst zit in de manier waarop Data Mesh omgaat met de vier grootste uitdagingen van gecentraliseerde architecturen: Eigenaarschap, Datakwaliteit, Technische schaalproblemen en Problemen met de Organisatorische Schaalbaarheid.

· In een gecentraliseerde architectuur kan het eigenaarschap van gegevens en systemen vaak onduidelijk zijn, omdat alle informatie en verantwoordelijkheden gescheiden zijn over een centrale entiteit. Wat kan leiden tot verantwoordelijkheid vermijding en gebrek aan eigenaarschap. In een gedecentraliseerde architectuur is de verantwoordelijkheid voor gegevens juist granulair en duidelijk verdeeld onder de deelnemende entiteiten. Met als gevolg een veel sterker gevoel van data eigenaarschap en verantwoordelijkheid.

· In een gecentraliseerde setup kamp je ook met veel meer mogelijkheden voor datacorruptie en dataverlies, omdat alle gegevens door één centrale entiteit worden beheerd. In een gedecentraliseerde setup is de datakwaliteit doorgaans hoger, omdat de gegevens worden beheerd en vooral bewaakt door meerdere entiteiten.
Hetgeen leidt tot redundantie en betere betrouwbaarheid en integriteit van de gegevens. Zo biedt het Trust & Governance framework iShare.eu voortdurende controle op eventuele veranderingen in de het landschap van data vraag en -aanbod.

· Gecentraliseerde systemen hebben de neiging om technische problemen te ondervinden naarmate ze groter worden, omdat ze steeds meer gegevens moeten verwerken en opslaan. Wat kan leiden tot prestatieproblemen en downtime. Gedecentraliseerde systemen daarentegen zijn beter bestand tegen schaalproblemen, omdat ze de verwerkings- en opslagtaken eenvoudig over meerdere nodes verdelen.
Pay-as-you-grow resulteert in verbeterde prestaties en minder downtime.

· In een gecentraliseerd systeem kan de groei van de organisatie belemmerd worden door het onvermogen van het systeem om snel en efficiënt op te schalen naar nieuwe gebruikers of functies. Terwijl de organisatie in een gedecentraliseerd systeem juist makkelijker groeien, omdat steeds nieuwe nodes kunnen worden toegevoegd zonder dat dit invloed heeft op de prestaties van het systeem als geheel.

Samengevat: de traditionele overheidsCULTUUR (mandaat/budget) zit zichzelf behoorlijk in de weg in de ambitie naar een informatiegestuurde, multi-domein geschikte overheidsSTRUCTUUR.

Door de verantwoordelijkheid voor de data niet langer te centraliseren maar juist te decentraliseren, naar individuen die het dichtst bij de data zijn, creëer je fijnmazige onderhoudbaarheid en flexibiliteit. Dit lost ook meteen de eindeloze discussie op over wie nu feitelijk de ‘eigenaar’ is van de datasets.
Vandaag draaien de meeste brondata op domein specifieke systemen van derden (zoals Microsoft Dynamics, SAP, Oracle etc.) die technisch ‘ergens in de motorruimte’ van een Shared Service Center of bij een derde zijn geplaatst. De daadwerkelijke data-gebruiker snapt hier weinig van. Omgekeerd zijn de technische experts in de machinekamer meestal onbekend met het daadwerkelijke gebruik van de data in hun systemen. Die twee perspectieven op data beïnvloeden elkaar echter wel. Als je bijvoorbeeld data uit een bepaald systeem extraheert en verrijkt met data uit een ander systeem, wil dat niet zeggen dat je die verrijkte data ook zomaar weer kunt binnenhalen in het oorspronkelijke systeem. Probeer thuis maar eens de ene excell sheet met de andere te combineren. Kan een aardig zooitje worden. Beide partijen ontberen dus begrip van de context waarin de data zijn gegenereerd en wat de gevolgen van iemands handelen daarbij kan zijn. Een tabel, veldnaam of bestand is niet altijd vergelijkbaar met de ander, wat betekent dat dagdagelijks gebruik snel kan resulteren in risico’s. Denk aan datalekken, afnemende datakwaliteit en onjuiste analyses. Daar wordt geen Bestuurder blij van! In plaats dus van de data naar de gebruiker te brengen, zou het ideaal zijn als wij de Data Gebruiker uit zouden kunnen dagen om verifieerbaar aan te kunnen geven waarom hij/zij bij die data wil en wat hij/zij met die data zou mogen doen en hoe lang? Als je weet wie iemand is en wat die iemand dan mag, dan zou je die werkwijze kunnen automatiseren. Je zou hun identiteit en autorisatie kunnen afzetten tegen hun rol in het Data Ecosysteem als Data Eigenaar, Data Leverancier of Data Gebruiker. Als dat lukt kan elke Gebruiker deze dataset raadplegen via een duidelijke API.

Data zouden niet enkel een bijproduct moeten zijn dat beheerd wordt door anderen.
Data zouden jouw eigen creatie moeten zijn, een data product dat je zelf op een marktplaats aanbiedt: een helder, zelfstandig inzetbaar gegevensbestand met een specifieke, begrensde toegevoegde waarde. Elk dataproduct wordt bedacht, ontwikkeld en onderhouden door een gespecialiseerd productteam. Elk dataproduct functioneert autonoom en wordt beheerd zonder enige afhankelijkheid van andere dataproducten. Het is ontworpen om een specifiek, begrensd probleem aan te pakken en is op een zodanige manier geconstrueerd dat het voor iedereen duidelijk is wat het doel ervan is. Zo ontstaat er een bruikbare grondstof die vanuit verschillende invalshoeken ingezet kan worden. Op de markt voor Data Producten bevinden zich (potentiële) gebruikers die moeten aantonen dat zij aan jouw criteria kunnen voldoen om toegang te krijgen tot jouw data (toegang op basis van verifieerbare claims en beleid). Een dataproduct is nog wel iets anders dan ‘data als product’.

Een dataproduct is als een gerecht bereid door een kok. De ruwe ingrediënten zijn vergelijkbaar met de onbewerkte data, vol potentie maar nog niet klaar voor consumptie. De kok, of datawetenschapper, neemt deze ingrediënten en combineert ze op deskundige wijze, voegt specerijen toe in de vorm van algoritmen, en creëert iets volledig nieuws – het gerecht of het dataproduct. De menukaart is zoals de gebruikersinterface, de manier waarop het product wordt gepresenteerd aan de eindgebruiker. Tenslotte, het geserveerde gerecht is het eindproduct, een gereed en bruikbaar dataproduct dat voor de klant waarde oplevert.
Het dataproduct is een duidelijk gedefinieerd object, waarvoor iemand verantwoordelijk is. Het wordt niet beschouwd als een onbedoeld neveneffect van een ander proces. Het wordt echt bewust beschikbaar gesteld aan andere dataproviders/nodes en gebruikers. Om dat te kunnen, houdt een dataproduct rekening met de specifieke architectuur die nodig is voor het toegankelijk en bruikbaar maken van die betreffende dataset. Wat impliceert dat een dataproduct mogelijk bestaat uit subproducten, elk met een unieke functie. Zo kan een Persoonsdataproduct onderdelen bevatten voor transactionele, demografische en gedragsdata, die elk weer onder het beheer van een specifiek, gemandateerd team kunnen vallen. Super fijnmazig dus.

Daardoor wordt het nu ook mogelijk om data producten verfijnd aan te bieden onder data contracten; juridisch bindende overeenkomsten tussen data domeinen, met daarin alles wat de techneut moet weten om zijn werk te kunnen doen en alles wat de Gebruiker moet weten om te weten wat hij/zij/het (apparaat) met de data mag en kan. Het datacontract is een uitgebreid document dat essentiële metadata, data schema’s, datatransformatie-informatie en toegangsregels omvat. Daarnaast biedt het contract alle noodzakelijke informatie voor het lokaliseren, benaderen en bewerken van gegevens in databases, standaardbestandsformaten, evenementen stromen of als grafiek. Zeg maar de bereidingsinstructies op de sticker op de achterkant van het shrink wrapped ingrediënt van de kok, inclusief allergie waarschuwing, houdbaarheid, E-nummers en plaats van herkomst van het ingrediënt.

Dankzij geavanceerde automatisering kunnen infrastructuur elementen zoals opslag, rekenkracht en toegangscontrole efficiënter worden beheerd. Hierdoor is ons Domeinteam minder afhankelijk van IT. In plaats van IT-beperkingen die bij traditionele architecturen voorkwamen, stelt moderne technologie ons in staat om zich volledig te concentreren op de business, gedreven door hun dataset. Het feit dat elk Domein Team verantwoordelijk zou kunnen worden voor het eigen Data Product, wil niet zeggen dat ze ook allemaal nog hun eigen technische staf zouden moeten hebben. De ‘plumbing’ , de techniek, kan vandaag de dag worden afgehandeld door een (hybride) cloud dienst, dat alles kan leveren wat het Domein Team nodig heeft om de data lifecycle van bouwen, testen, beveiligen, uitrollen, onderhouden en delen met de Data Consument of een Data Leverancier af te handelen ‘as-a-Service’. Met behulp van gestandaardiseerde API’s, scripts, Policy Decision en Enforcement Points, is het prima mogelijk om de infrastructuur, inclusief verouderde systemen, efficiënt te beheren. Dit resulteert in een gestandaardiseerde, herhaalbare methode voor het bouwen, beveiligen, vinden, verbinden en uitlezen van data producten.

Samengevat: iedereen kan koken. De manier waarop we voedsel verkrijgen is veranderd, van zelfverbouwen tot kant-en-klaar thuisbezorgde kookpakketten. In de jaren ’80 kwam de kruidenier nog aan huis, nu bestellen we maaltijdpakketten online en doen robots de verpakking. Vergelijkbare ketenomkering zien we ook in de wereld van data producten en sovereine clouds.

Data Governance kan daardoor gecentraliseerd worden afgedwongen over organisatorische stovepipes (de Scheiding van Machten heeft ook zijn waarde) , maar met behoud van Data Soevereiniteit per stovepipe: datacentrische samenwerking is echt mogelijk. Hoewel niet alle regels universeel te maken zijn, vanwege specifieke contextuele wetgeving, kan elk Domein dit wel duidelijk specificeren voor de eigen datasets. Binnen de IT-governance wordt bepaald dat Gebruikers authenticatie nodig hebben, maar de Domein Teams specificeren tot welke Data Producten zo’n geverifieerde Gebruiker vervolgens toegang heeft en welke acties met de data toegestaan zijn en onder welke operationele en juridische voorwaarden. Die real-time afgedwongen worden. Het is alsof het maaltijdpakket dolgraag wilt schreeuwen “Pas op, gluten alert!” en de kok (de Domeineigenaar), beslist welke ingrediënten welke mond zullen bereiken. De toekomst behoort aan ‘Gefedereerde Data Governance’: centraal overzicht gecombineerd met domeinspecifieke soevereiniteit. Vrijheid in Gebondenheid.